Privacy Policy

Last updated: August 24, 2026 · Applies to the NotiSync Android app (net.extrawdw.apps.notisync), iOS app (net.extrawdw.apps.NotiSync), desktop daemon and command-line tools, relay services, and this website.

1. Who we are

NotiSync ("NotiSync", "we", "us") is developed and operated by Extrawdw. It connects devices you explicitly trust to mirror notifications and, when enabled, provide Screen Sharing, remote command monitoring, OpenPGP commit approval, and SSH-agent signing. This policy explains what the Android, iOS, and desktop software, our relay services, and this website process and why.

If you have any questions, contact us at privacy@extrawdw.net.

2. How NotiSync is built (and why it matters for privacy)

NotiSync follows a "clients are authoritative, the server is a courier" design. Your devices decide which peers to trust and encrypt private feature payloads for those peers before transmission. The relay forwards ciphertext and coordinates push or WebSocket delivery, but it cannot decrypt the private payload.

On iOS, the app and its Notification Service Extension decrypt NotiSync notifications locally before showing them. Screen Sharing first attempts a direct local connection; if you choose the broker relay, the screen stream remains end-to-end encrypted while the broker handles the connection and visible frame metadata described in Section 4.

When the optional iPhone bridge is enabled in the Android app, your Android device acts as the bridge: it pairs with your iPhone over Bluetooth, receives ANCS notification attributes from iOS, and then either shows those notifications locally or sends selected ones through the same end-to-end-encrypted NotiSync pipeline. The native iOS app is not required on that iPhone for ANCS mirroring; install it when you also want the iPhone or iPad to receive mirrored NotiSync notifications, sync dismissals, or manage filters.

3. Information the app processes

a. Notification content

On Android, NotiSync reads notifications posted on your device using notification-listener access, which you grant explicitly. This can include the app name/package, title and text, channel or conversation names, sender names, message history, action buttons and reply fields, call/media/progress state, and attached icons or images.

If you enable the iPhone bridge, your Android device can pair with your iPhone over Bluetooth ANCS and receive iOS notification attributes. This can include the iOS app bundle ID and display name, notification title, subtitle, message text, notification date, category, and event state such as added or removed.

On iOS, NotiSync receives messages sent by your trusted devices. Those messages may contain the source app, app label/package or iOS bundle ID, title, body, subtitle, channel or conversation details, sender names, device-origin details, action definitions, and private assets such as icons, avatars, or images. The iOS app does not read unrelated notifications already on your iPhone or iPad.

Notification details are encrypted on the source device and decrypted only on trusted destination devices. Inline replies, action selections, taps, and dismissals are also sent end-to-end encrypted to the source device, which performs the requested action when supported.

b. Your app selections

You choose which installed Android apps are mirrored. To show you a list, the app reads the labels and icons of apps on your device. Your selections and settings are stored locally on your device. When an enabled app posts a mirrored notification, the source app name/package is included only inside the end-to-end-encrypted notification body.

For the iPhone bridge, iOS does not provide a full app list in advance. NotiSync records iPhone apps as they post notifications over ANCS, then lets you turn mirroring on for the iPhone apps you choose. The discovered iOS bundle IDs, display names, last-seen times, and your per-app choices are stored locally on your Android device.

On iOS, NotiSync stores your display/filter choices for trusted source devices, apps, and Android notification channels. These choices are stored locally and may be sent end-to-end encrypted to the trusted source device so that it can stop or resume sending matching notifications to your iOS device. The relay server cannot read these filter rules.

c. iPhone app icons and Apple lookup

To show recognizable icons for iOS-origin notifications, NotiSync may fetch public app artwork from Apple's App Store / iTunes Lookup API and artwork CDN. The lookup uses the iOS app's bundle ID, and it does not send notification titles, messages, senders, or images to Apple. The returned public icon artwork is cached locally on your device.

For Android-origin notifications displayed on iOS, NotiSync may fetch the encrypted private launcher icon or image asset from the relay server, decrypt it locally, verify its hash, and cache it locally. Some common icons are bundled with the app or drawn as generic placeholders.

d. Device identity and pairing data

Each installation has a cryptographic identity. We use:

• A device name you choose (e.g. "My Phone"), shared only with devices you pair with.
• A client ID, derived from your device's public key, used to address messages to the right device.
• Public keys and a safety number exchanged during pairing so your devices can verify and trust each other.

NotiSync identity and transport private keys are generated and kept locally. Android uses Android Keystore and encrypted app-private storage; iOS uses the Secure Enclave or Keychain where available. Desktop private key material is stored in owner-only local files, but NotiSync does not itself encrypt those files at rest, so operating-system account security and disk encryption matter. Only public keys and derived identifiers are shared for pairing and routing.

If you use the iPhone bridge, Android's Bluetooth and Companion Device pairing systems handle the local association with your iPhone. NotiSync may keep the paired iPhone's display name and a hashed, internal origin identifier so bridged iPhone notifications can be grouped and dismissed correctly. That iPhone origin information is not sent to the relay server in readable form.

On iOS, QR pairing uses the camera only while the scanner is open. You can also paste or open a pairing link. Pairing material contains public keys, your chosen device name, and verification information; it does not contain private keys. If you start Experience Mode, your pairing link is sent to the relay server so a demo peer can be connected.

e. Push delivery tokens and routing

To wake your devices when a notification arrives, NotiSync uses platform push services: Firebase Cloud Messaging (FCM) on Android and Apple Push Notification service (APNs) on iOS. This requires a push token issued by Google or Apple for your device, which is relayed through our server as a signed "route claim" so messages can be delivered.

To route a message, the service necessarily sees delivery metadata such as sender and destination client IDs, message IDs and types, route identifiers, APNs or FCM route tokens, urgency, timing, ciphertext size, and random private-asset IDs. It does not see private payload fields such as notification text, Run output, commit payloads, SSH sign data, screen pixels, or asset decryption keys.

f. Advanced features

Screen Sharing. A shared Android device captures and hardware-encodes its screen through the Shizuku integration. Trusted Android, iPhone, iPad, and supported desktop viewers can receive the video and send control input. Session requests contain identifiers, connection candidates, capabilities, codec and quality choices, and short-lived keying material. These requests are end-to-end encrypted. Direct connections use your local network; broker-relayed video and control remain end-to-end encrypted. NotiSync does not record the session, request microphone access, or transmit device audio.

Run. When you invoke the desktop nsrun tool, it sends a trusted Android device the command arguments, absolute working directory, terminal output, prompts, progress, timestamps, exit status, failures, and any generated summary. Responses and signals sent back to the running computer are encrypted in the same way. The desktop also writes private local Run logs. If you explicitly configure and invoke nsrun --llm, selected command context is sent to the OpenAI-compatible endpoint you configured; details appear in Section 6.

Seal. A Seal request sends a trusted Android device the byte-exact Git commit payload, its hash, requested OpenPGP key ID, working directory, and requester/device context. NotiSync does not send the repository's file contents or diff unless they are themselves present in the commit message or headers. After you approve, OpenKeychain signs the payload and returns a detached signature. NotiSync does not receive the OpenPGP private key.

SSH Agent. The desktop agent receives an end-to-end-encrypted inventory of public SSH keys and sends a selected trusted Android device the data to sign, requested algorithm, selected public key, and available process and SSH-destination context such as executable, working directory, host, username, and host-key fingerprint. Android returns only the signature. Private keys remain on Android unless you explicitly create an exportable key and authorize exporting or sending a copy. Non-exportable Android Keystore keys cannot be exported.

g. Local history, configuration, and diagnostics

Depending on platform and features used, NotiSync stores trust and pairing state, keys, routes and delivery state, filters, notification display maps, iOS inbox and activity history, Run history and raw desktop logs, Seal review results, SSH keys/public-key inventory, remembered approvals, known hosts, and SSH audit records. These records stay local unless this policy says they are sent to a trusted peer or service.

The apps and desktop tools also show or write operational diagnostics such as client/key identifiers, transport and route state, capabilities, request outcomes, errors, and key-rotation state. Desktop service logs can include message IDs, short client IDs, local app identifiers, and delivery outcomes, but are not automatically uploaded to us.

h. Website visits

This website is a static GitHub Pages site. It sets no tracking cookies and includes no advertising or analytics scripts. GitHub Pages, Cloudflare, and other network providers may process standard request information such as IP address, user agent, requested URL, and request time. The homepage requests the Material Symbols font stylesheet and font files from Google Fonts, so Google receives standard web-request information when those resources load. Store providers receive information only if you follow their links.

i. Crash, performance, integrity, and operational diagnostics

The Android and iOS apps include Firebase Crashlytics and Firebase Performance Monitoring. They can process device/app identifiers, device model, OS and app versions, stack traces, app state near a crash, startup/rendering measurements, and normalized relay-request timing. NotiSync's custom diagnostic fields are designed not to include private feature content, source apps, senders, or trusted-device identifiers. We use this data for reliability, not advertising or profiling. Android provides an in-app switch to disable this collection; the current iOS app enables it by default.

The broker verifies app integrity and records operational events needed to prevent abuse and diagnose delivery. These can include app ID, shortened or hashed client identifiers, endpoint, message or relay identifiers, outcome/rejection reason, timing, traffic size, and connection IP information visible to the hosting stack. The broker does not put decrypted feature payloads in these events.

4. What the relay server can and cannot see

General private messages use per-recipient HPKE (X25519) with AES-256-GCM and signed device records. Screen relay control uses a session-authenticated encrypted channel and video uses end-to-end AES-GCM records. The server handles ciphertext and the metadata listed above, not the decrypted feature content.

5. Permissions the app requests, and why

Android

• Notification access (notification listener) — so NotiSync can read notifications on this device in order to mirror them. You grant this in Android settings and can revoke it at any time.
• Show notifications (POST_NOTIFICATIONS) — so mirrored notifications from your other devices can appear here, and so the app can alert you to device-trust requests.
• Internet, network state, local network, and nearby Wi-Fi — to connect to the relay, discover trusted peers, prefer direct local Screen Sharing, and send or receive encrypted traffic. Nearby Wi-Fi and Bluetooth scanning are declared as not used for location.
• Camera, via Google's code scanner (during QR pairing only) — scanning a pairing code launches Google Play services' on-device code scanner, which runs out of process and briefly uses the camera; NotiSync itself does not hold the Android camera permission. Camera frames are processed on your device and are not collected or transmitted.
• NFC (during tap-to-pair only) — while the pairing screen is open, NotiSync can present the current pairing link over NFC to a nearby device that taps it (for example, another Android phone, or an iPhone reading the tag). NFC is not used to read notification content.
• Bluetooth connect, advertise, and scan (iPhone bridge only) — so your Android device can advertise as a Bluetooth LE accessory, pair with your iPhone, and receive ANCS notifications when you enable the bridge. Bluetooth scan is declared as neverForLocation; NotiSync does not use Bluetooth scanning to derive location.
• Connected-device foreground service and companion-device presence (iPhone bridge only) — so the bridge can stay connected while enabled and can resume when your associated iPhone comes back into range. This relies on Android's companion-device background permissions (run in the background, use data in the background, and start the bridge's foreground service when your iPhone reappears).
• Run at startup / after app update (iPhone bridge only) — so NotiSync can resume the bridge after reboot or app update if you left it turned on.
• Biometric or device credential — to authorize sensitive SSH-key use, export, or transfer where required. NotiSync receives only the authentication result, not your biometric data.
• Shizuku access (Screen Sharing source only) — to capture and control the Android screen through a Shizuku service you separately install, start, and authorize. NotiSync does not receive root access or capture the microphone.
• Full-screen, vibration, and promoted/foreground notifications — to present mirrored calls and time-sensitive approval requests, and to keep user-visible Run, bridge, and Screen Sharing work active when Android requires it.

iOS

• Notifications and APNs — so mirrored notifications from trusted devices can appear on your iPhone or iPad, and so APNs can wake the app or Notification Service Extension to process encrypted NotiSync messages.
• Camera (during QR pairing only) — so you can scan another device's pairing code. Camera frames are processed on your device by the iOS scanner and are not collected or transmitted by us.
• Local network and Bonjour — to discover a screen source and establish a direct encrypted Screen Sharing connection on your local network.
• Background refresh / remote notification background mode — so iOS can give NotiSync limited background time to fetch encrypted relay messages, acknowledge handled messages, sync dismissals, and maintain keys/routes.
• Background media session / Picture in Picture — so a screen-viewing session can remain visible where iOS permits. NotiSync does not request microphone access or transmit device audio.
• App Group and Keychain access — so the main app and Notification Service Extension can share the minimum local state needed to decrypt and display NotiSync notifications while preserving private keys on the device.

6. Third-party services

NotiSync uses these services and optional integrations:

• Firebase Cloud Messaging (Google LLC) — used on Android to wake your devices and deliver small encrypted messages. Google processes your device's push token and message delivery metadata under Google's Privacy Policy. Message payloads handled through FCM are end-to-end encrypted.
• Apple Push Notification service (Apple Inc.) — used on iOS to wake NotiSync, deliver encrypted NotiSync pushes, and display notifications after local decryption by the app or Notification Service Extension. Apple processes APNs tokens and delivery metadata under Apple's Privacy Policy. NotiSync APNs payloads do not contain readable notification content.
• Firebase App Check, Play Integrity, Apple App Attest, and DeviceCheck — used to help the relay verify that requests come from a genuine app instance before it issues a short-lived broker token. Android uses Firebase App Check with Play Integrity; iOS uses App Attest or DeviceCheck, both through Firebase App Check. These services process app/device integrity signals, not notification content.
• Firebase Crashlytics and Firebase Performance Monitoring (Google LLC) — collect crash reports and app-performance/diagnostic data so we can find and fix stability and performance problems. They process diagnostic and device data, not notification content, and the data is not used for advertising. On Android, this collection can be turned off in the app's settings. Data is handled under Google's Privacy Policy.
• Google Play services / ML Kit code scanner (Google LLC) — provides the Android on-device QR code scanner used for pairing. Scanning happens on your device.
• Apple AVFoundation scanner — provides the iOS on-device QR scanner used for pairing. Scanning happens on your device.
• Apple App Store / iTunes Lookup API and artwork CDN (Apple Inc.) — used to fetch public app icons for iOS-origin notifications when the icon is not already bundled or cached. The request can include the iOS app bundle ID; notification content is not sent to Apple.
• Shizuku — an optional, separately installed Android service used locally to capture and control a screen you choose to share. Shizuku's own installation, authorization, and data handling are controlled by you and its developer.
• OpenKeychain — an optional, separately installed Android app used by Seal. NotiSync gives OpenKeychain the commit payload only after you approve signing; OpenKeychain manages the OpenPGP private key and returns the signature.
• Your configured OpenAI-compatible API — used only when you explicitly configure and invoke nsrun --llm. The request can contain the analysis phase, command arguments, working directory, recent terminal output, failure details, and a capped directory tree. By default, the tree excludes common private/build directories such as .git, .notisync, .gradle, build, and node_modules, and does not follow symlinks. Your endpoint's operator and policy govern that copy.
• GitHub Pages and Google Fonts — host the static website and supply its Material Symbols font. They receive standard web-request information, not NotiSync app content.
• Relay server hosting — our relay server (notisync-api.extrawdw.net) is operated by Extrawdw and reached over an encrypted connection through Cloudflare, which provides network and proxy services. To route, secure, and operate the service, the relay and Cloudflare process standard connection information such as IP address, request timing, and basic request metadata; this is separate from — and does not include — your end-to-end-encrypted notification content.

NotiSync does not include third-party advertising SDKs or Firebase Analytics, and none of the data it collects is used for advertising, ad targeting, or profiling.

7. Data retention

• Android and iOS: settings, trust state, keys, filters, app/icon caches, routes, and delivery/display state remain until replaced, cleared, reset, or removed with app data. The iOS activity log is capped at about 600 entries; its notification inbox remains until you clear it or app data is removed.
• Run: Android keeps completed Run history until you clear it, remove app data, or built-in age/count safeguards remove old rows. The desktop stores private per-run logs, normally pruned after 30 days or when configured storage limits are reached; both limits are configurable.
• Seal: the raw commit payload and encoded response are removed from NotiSync after the request reaches a terminal state. A bounded review record containing commit metadata, working directory, hash, outcome, and message can remain on Android for up to 10 years, capped at 10,000 records, unless you clear it sooner. OpenKeychain controls its own key and activity storage.
• SSH Agent: Android keeps SSH keys, public-key descriptors, known hosts, remembered approvals, and an encrypted audit history capped at 500 requests until you remove or reset them. Desktop public-key caches, authorization state, and a journal containing hashes and outcomes—not raw data-to-sign—remain until the local agent data is reset or deleted.
• Screen Sharing: NotiSync does not store a recording. Direct sessions end with the peer connection. Broker relay slots and buffered encrypted frames are held in memory only for the live, short-lived session and are removed when the session expires or disconnects.
• Desktop configuration and logs: trust state, keys, routes, configuration, local registrations, and operational logs remain in the desktop data directory until replaced, rotated, reset, or deleted according to local configuration and operating-system behavior.
• In platform key storage: private keys and broker tokens are stored locally in Android Keystore or iOS Keychain/Secure Enclave storage. iOS may preserve some Keychain items across reinstall according to Apple's platform behavior; these items remain device-bound and are not readable by us.
• On the relay server: encrypted messages awaiting delivery are retained up to 48 hours; encrypted private assets are retained up to 7 days. Route claims and push tokens remain until replaced, cleared, or invalidated. Key-epoch records remain as needed for safe key rotation. The broker keeps rolling integrity aggregates in memory for up to 7 days and up to 200 recent integrity events; a restart clears them. Cloudflare and hosting access/security logs follow their own operational retention settings.
• At Apple and Google: APNs, FCM, App Check, App Attest, DeviceCheck, Firebase Crashlytics, Firebase Performance Monitoring, and App Store / iTunes icon lookup requests are handled by those providers. We do not operate their systems or control their retention of request, push-delivery, integrity-check, or crash/performance data.
• Uninstalling the app removes the local app containers on that device. Because keys are device-bound and are not shared with us, removing or losing the keys for a device makes that device's stored encrypted content unrecoverable.

8. How your information is shared

We do not sell your personal information and we do not share it for advertising. Information is only ever transmitted to:

• your other trusted devices, end-to-end encrypted;
• Apple and Google for push delivery, integrity checks, public icon lookup, code scanning, and crash/performance diagnostics as described above;
• OpenKeychain or Shizuku when you invoke a feature that depends on the separately installed app;
• the OpenAI-compatible endpoint you configure, only when you invoke nsrun --llm; and
• the hosting and website providers listed in Section 6, to operate the relay and site.

We may disclose information if required by law. What we can produce is limited to information in our custody, such as encrypted payloads, public key material, routes, app-integrity state, and operational/delivery metadata; we cannot decrypt the private feature content.

9. Security

NotiSync is designed around strong, modern cryptography:

• Per-device NotiSync identity keys stored in the Android Keystore, hardware-backed (StrongBox or TEE) where available, and non-exportable.
• Per-device identity keys stored in the iOS Secure Enclave or Keychain where available, with app/extension access limited by iOS keychain access groups.
• End-to-end encryption of notification bodies and interactions, advanced-feature requests/results, private assets, trust/filter sync, and dismissals.
• Optional iPhone bridge over OS Bluetooth pairing and ANCS. Once your Android device receives iPhone notification attributes, any NotiSync mirroring uses the same end-to-end encryption as Android-origin notifications.
• Signed identity, membership, and routing records (ECDSA P-256) to prevent tampering and impersonation.
• Pairing by QR, NFC tap, or link carries signed public keys, so trust is established directly between your devices after you verify the safety number.
• Owner-only desktop files for local keys, tokens, and state. Because NotiSync does not separately encrypt desktop key files at rest, use operating-system disk encryption and protect your user account.

No system is perfectly secure, but the architecture is built so that a compromise of the relay server does not expose your private feature content.

10. Your choices and control

• Choose exactly which Android apps — and, through the iPhone bridge, which iPhone apps — are mirrored, and change this at any time.
• Enable or disable the iPhone bridge, forget the paired iPhone, and choose whether bridged iPhone notifications show only on the bridge phone or mirror to your other trusted devices.
• On iOS, choose which trusted source devices, apps, and Android notification channels should alert or be filtered for this iPhone or iPad.
• Remove a trusted device to stop sharing with it.
• Start Screen Sharing, Run, Seal, or SSH operations only when you choose; reject or end requests, clear available histories, and reset locally stored feature state.
• Use non-exportable SSH keys, or explicitly authorize any export/transfer of an exportable key.
• Do not configure or invoke nsrun --llm if you do not want command context sent to your chosen API endpoint.
• On Android, disable Firebase crash and performance collection in NotiSync settings.
• Revoke notification access, notification-posting permission, Bluetooth permissions, or companion-device permissions in Android settings.
• Revoke notification permission, camera permission, background refresh, or cellular/network access in iOS settings.
• Uninstall the app to remove its local app data from a device; platform key storage may follow the platform behavior described in Section 7.

11. Children

NotiSync is not directed to children and is not intended for use by anyone under the age of 13 (or the minimum age required in your country). We do not knowingly collect personal information from children.

12. International users

NotiSync can be used worldwide. Encrypted messages, delivery and diagnostic metadata, website requests, and optional third-party requests may be processed in countries where Google, Apple, Cloudflare, GitHub, or a provider you choose operates. Private NotiSync feature payloads remain end-to-end encrypted in transit through our relay, but content you deliberately send to OpenKeychain, Shizuku, or your configured OpenAI-compatible endpoint is processed by that selected integration under its own terms.

13. Changes to this policy

We may update this policy as the app evolves. When we make material changes, we will update the "Last updated" date above and, where appropriate, note the change in the app or on this site. Continued use of NotiSync after an update means you accept the revised policy.

14. Contact

Questions, concerns, or requests about your privacy? Email us at privacy@extrawdw.net.