Skip to main content
The behavior SDK’s privacy posture is the difference between “this thing is invasive” and “this thing is acceptable to ship”. This page is the audit-grade reference: every claim mapped to source.

​
What is collected

SurfaceCapturedNot captured
Scrolldirection, velocity, acceleration, jitterwhat was scrolled
Taptiming, count, pressure (when available)what was tapped (no view ids, no labels)
Swipedirection, timingcontent swiped
Typinginter-key intervals, burst length, cadencekeystrokes, IME state, text content, language
App switchtiming of foreground changeapp names, package ids (collected internally for session bookkeeping but not emitted in events)
Notificationtiming, InterruptionAction (ignored / opened / answered / dismissed)notification title, body, app source, user response content
Calltiming, InterruptionActioncaller id, contact name, audio
ClipboardClipboardAction (copy / paste / cut), ClipboardContext (text-field / system)clipboard contents
Motion50 Hz triaxial accelerometer (m/s²) when emitRawMotionSamples or enableMotionLite enabledgyro / magnetometer / GPS / barometer / camera / mic

​
What is never captured

The following classes are not collected by any code path:
  • Text content (typed, displayed, or in clipboard).
  • Audio (mic).
  • Images (camera, screenshots).
  • Location (GPS, network location, geofencing).
  • Contacts.
  • Calendar entries.
  • Browser history.
  • Network requests originating from the app (the SDK does not call out to the network at all — see “Outbound traffic” below).

​
Outbound traffic

The SDK itself makes no outbound network calls. There is no HTTP client in the synheart-behavior source. Cloud delivery, when desired, happens through synheart-core → the Synheart runtime’s ingest connector, which:
  • Gates on Behavior and cloudUpload consent.
  • Hashes subject_id; the raw value never leaves the device.
  • Signs requests with the device’s hardware key (see Synheart Auth).
The SDK alone does not transmit any data anywhere.

​
Platform permissions

PermissionRequired forScope
Notification listener (Android)notification events with InterruptionActionThe SDK uses NotificationListenerService which observes notification posts. It records timing + action only; the listener never reads notification text.
Phone state / call log (Android)call eventsTiming and ignored/answered enum only; no caller id stored or emitted.
Accelerometer (sensor)Motion-lite + raw motion samplesStandard sensor access; no special platform prompt on iOS/Android.
Accessibility service (NOT used)—The SDK does not request Accessibility on Android. Some apps use Accessibility for keystroke logging; this SDK does not.
HealthKit (iOS)(none)Behavior SDK does not touch HealthKit; that’s synheart-wear’s domain.
SynheartBehavior.checkNotificationPermission() / requestNotificationPermission() and the call-permission equivalents are Android-only; iOS does not have a comparable user-facing permission for these surfaces, and the SDK collects only what iOS exposes through public APIs.

​
Adversary model

AdversaryConcernMitigation
Malicious app on same deviceReading SDK-collected data via shared storageThe SDK does not write events to disk. Aggregates flow only through in-memory streams to the host app.
Compromised host processHost can read everything in its address spaceOut of scope: the SDK runs inside the host. Trust boundary is at the OS, not within the process.
Network adversaryIntercept telemetryThe SDK makes no network calls. When the host forwards events through the Synheart runtime, transport is TLS + device-signed proof.
Server-side observerReconstruct user identity from behavioral patternssubject_id is hashed; no app names or content reach the cloud. Mitigations are at the cloud-policy layer.
Curious developerUse the SDK in ways the user didn’t expectConsent gates at three layers: SDK config (consentBehavior), runtime (Behavior consent), and platform OS permission grants.

​
Implementation invariants

When auditing the SDK against this threat model, the following are non-negotiable code invariants:
  1. No string captured from input fields. BehaviorEventType.typing events carry only timing fields in their metrics map.
  2. No clipboard contents. ClipboardAction and ClipboardContext enums encode the action/location, not the payload.
  3. No notification body or title. InterruptionAction enum is the only notification-derived field on events.
  4. No outbound HTTP from the SDK. No HTTP clients imported in any of the four SDK packages.
  5. No background data persistence by the SDK. Events flow through streams; aggregates are computed in-memory and surface as BehaviorSessionSummary. Hosts decide whether to persist.
If any of these change, this page is a release blocker until the threat model is updated. 
Host config:    BehaviorConfig.consentBehavior   (boolean)
       ↓
SDK runtime:    On startSession, the SDK checks consent
       ↓
Core SDK gate:  ConsentModule.has_consent(behavior)
       ↓
Runtime gate:   ConsentType::Behavior  (Synheart runtime)
       ↓
Cloud gate:     ConsentType::CloudUpload  (separate)
All four gates must allow for behavioral data to leave the device. Any one closes the loop.

​
Logging policy

The SDK logs at info / warn levels in production. Logs include:
  • Session lifecycle (session_start, session_end, durations).
  • Permission state changes.
  • Inference latency (motion-lite).
The SDK does not log:
  • Event-level payloads (no event-by-event logs).
  • User identifiers (raw userId / deviceId are never written to logs unless the host injects them).
  • Motion sample bytes.
  • Inference inputs.