Security and data boundaries

Data boundary

The SDK is designed not to read personal application content for bandwidth sharing. Application developers are still responsible for their own telemetry, reward records, contact data, consent messaging, and platform privacy disclosures.

Values that may ship in the application

Application integration API key issued to the app owner.
Public consent page and revoke URLs.
Consent version.
RS256 public verification key.
SDK package and native binaries.

The application API key identifies the integration. Treat it as sensitive operational data and avoid logs, but do not confuse it with private backend signing material.

Values that must never ship or appear in logs

Consent signing private key.
Runtime bearer or connection tokens.
Private backend access credentials.
Complete consent receipts.
Full internal service responses.
Secrets placed in callback errors or support attachments.

Native artifact integrity

Use wrapper and native files from the same release. Preserve private package-manager authentication outside source control. Do not replace official wrapper declarations with hand-written JNI, P/Invoke, Swift, or ffi-napi bindings.

Do not bypass the SDK-owned consent window on Android, iOS, WPF, or Electron. Accepted state is scoped to application key, device identity, consent version, and current verification rules.

Renderer and UI boundaries

Electron must keep SDK ownership and native imports in the main process. Expose only minimal state through a validated preload/IPC boundary. Native callbacks on C hosts must be marshalled before touching UI frameworks or managed runtimes.

Reporting a security issue

Do not include production customer data, credentials, receipts, or tokens. Use the support guide to prepare a sanitized report and identify it as a security issue.