Transparency Report — 2026 Q1

Download as Markdown Download as JSON Subscribe (Atom feed)

802 days incident-free at quarter end — 2026-03-31

Period: 2026-01-01 through 2026-03-31 (90 days)
Published: 2026-04-19 (backfilled)
Report scope: Complete quarter covered by this report.
License: CC0 1.0 Universal — reuse, quote, or mirror freely
Contact: transparency@saropa.com — monitored mailbox, auto-ack within 72h, substantive reply within 14 days

Disclosure scope

As of 2026-03-31: this report covers everything Saropa Pty Ltd is legally permitted to disclose. If a future report is constrained by legal process we cannot acknowledge (e.g. gag-order provisions attached to a government request), we will say so to the extent the law permits.

We deliberately do not publish a classic "warrant canary." The compelled-speech legal theory that canaries rely on has never been tested in court and is materially weaker in Australia, where Saropa Pty Ltd is registered. The scope statement above is a legally clean version: it makes no claim about gagged requests we cannot acknowledge, only that this report is complete within the limits the law sets.

Government data requests

Zero requests. No requests for user data were received from any government or law enforcement agency during this period.

Data breaches

Zero incidents. No incidents of unauthorized access, loss, or exposure of user data were identified during this period.

Account takedown requests

Zero takedown requests. No DMCA, court-order, or terms-violation takedown requests against user accounts or shared content were received during this period.

Analytics collection

Saropa does not publish aggregate user counts in transparency reports. Install counts, crash-report counts, analytics-event counts, and opt-in percentages all stay out of the report by deliberate policy. This is a permanent product decision, not a pending extraction.

The report documents what happened with user data — government requests, breaches, takedowns, and the SDKs that had access during the period. Aggregate install and engagement numbers are a different conversation (marketing / growth) and are not published here.

The companion JSON carries the analytics block as a policy marker (status: "not_published_by_policy") with every numeric subfield permanently null, so automated consumers recognize the exclusion rather than treat it as missing data.

Third-party SDK audit

Every SDK integrated in Saropa Contacts during this period that handles user data, attestation, or permissions. Reconstructed from the state of the app's pubspec.yaml at the last commit on or before the quarter end.

SDK	Purpose	Data seen	Trigger	Opt-out
`firebase_core` (v4.6.0)	Firebase app bootstrap	App install ID (app_instance_id) Basic device info	App start, if analytics infrastructure is enabled and the user is not COPPA-age	Offline Mode kill switch (from Q2 2026)
`firebase_analytics` (v12.2.0)	Screen + feature usage tracking	Event name Parameters Device model Pseudonymous install ID	User explicitly opts in via AnalyticsIntegrationEnabled (opt-in default from Q2 2026)	Analytics toggle Offline Mode (from Q2 2026)
`firebase_crashlytics` (v5.1.0)	Crash reports	Error message Stack trace Device model OS version Pseudonymous install ID	Captured on every install; uploaded when analytics opt-in AND online (from Q2 2026, previously uploaded whenever present)	Analytics opt-out (blocks upload from Q2 2026) Offline Mode
`firebase_messaging` (v16.1.3)	Push notifications	Device FCM token	User grants notification permission at OS prompt	Revoke notification permission in system settings
`firebase_app_check` (v0.4.2)	Anti-abuse attestation for Firebase requests	Device attestation token (no user data)	Automatic when the app makes Firebase API calls	Not user-facing — tied to Firebase SDK presence
`supabase_flutter` (v2.12.2)	Account, Saropa Connections, stats upload, Connection Discovery, E2EE contact sharing	Account email + display_name (when signed in) Contact stats as aggregate counts (opt-in) Contacts' display_name + email addresses via Connection Discovery (opt-in only) E2EE ciphertext for shared contact cards (servers cannot decrypt)	User signs in; individual cloud-feature toggles	Sign out Per-category toggles (Trust Dashboard from Q2 2026) Offline Mode
`google_sign_in` (v7.2.0)	Google account sign-in	Google OAuth token Profile email	User chooses 'Sign in with Google'	Do not sign in Disconnect via Settings
`sign_in_with_apple` (v7.0.1)	Apple account sign-in (iOS)	Apple OAuth token Hashed email or user-provided alias	User chooses 'Sign in with Apple'	Do not sign in Manage via Apple ID settings
`local_auth` (v3.0.0)	Biometric unlock for per-contact lock	Nothing — verification is handled by the OS; Saropa only receives a success/fail signal	User enables biometric lock on a contact	Disable biometric lock in the app OS biometric settings
`permission_handler` (v12.0.1)	OS permission prompts	Nothing — it mediates permission requests, does not collect data	App requests a permission	Deny permission in the system dialog Revoke in system settings
`flutter_contacts` (v1.1.9+2)	Device contacts access	Contacts the user explicitly selects for import are read from the device address book Never uploaded from this package	User grants contacts permission and chooses to import	Revoke contacts permission in system settings
`geolocator` (v14.0.2)	Device location (for real-time map features only)	Coordinates passed to the requesting map feature in real time	User interacts with a feature that needs location (and has granted the permission)	Deny location permission Revoke in system settings
`google_maps_flutter` (v2.17.0)	Embedded map rendering	The tile requests Google Maps makes to its own servers include the user's approximate viewport No Saropa account data is shared	User opens a map view	Avoid map views Offline Mode (from Q2 2026) suppresses live tile loading
`image_picker` (v1.2.1)	Photo / image selection	Images the user explicitly picks are loaded into the app Never uploaded by this package itself	User taps a 'choose photo' control	Deny photo library permission in system settings
`awesome_notifications` (v0.10.1)	Local + remote notifications (replaced flutter_local_notifications from Q3 2025)	Local notifications fire on-device Remote push (where used) relies on firebase_messaging's FCM token	App schedules a local reminder, or Firebase pushes a remote one	Disable notifications in system settings
`app_links` (v6.4.0)	Deep-link / URL-scheme handling	Inbound URL from the OS when a link with the app's scheme is opened	User taps a saropa:// or https://saropa.com/... link	Not applicable — only runs when a link is explicitly opened
`home_widget` (v0.8.1)	Home-screen widgets (Q4 2025 onward)	Contact names + event dates the user has chosen to pin to a widget Rendered on-device only	User adds a Saropa widget to their home screen	Remove the widget from the home screen

Changes since last report

No reportable changes in data handling this quarter. SDK version maintenance only.
Privacy-posture improvements in flight for Q2 2026 include the Privacy Labels section of the in-app Trust Dashboard, an Offline Mode kill switch, passive-mode Firebase Crashlytics with a post-crash opt-in prompt, and the flip of full analytics + crash uploads to opt-in by default. These will appear in the Q2 2026 report's 'Changes since last report' section.

How to contact us

If you believe this report is incomplete or incorrect — or if you have a researcher question about any SDK in the audit table — email transparency@saropa.com. The mailbox is monitored; we aim to acknowledge within 72 hours and give a substantive reply within 14 days. Corrections are published in a follow-up report rather than edited into this one, so the audit trail stays intact.