Transparency Report — 2024 Q3

Download as Markdown Download as JSON Subscribe (Atom feed)

255 days incident-free at quarter end — 2024-09-30

Period: 2024-07-01 through 2024-09-30 (92 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 2024-09-30: 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` (v3.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` (v11.3.3)	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` (v4.1.3)	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_app_check` (v0.3.1+3)	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.6.0)	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` (v6.2.1)	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` (v6.1.2)	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` (v2.2.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` (v11.3.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.8+1)	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` (v13.0.1)	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.9.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.1.2)	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
`app_links` (v6.2.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

Changes since last report

Facebook Sign-In was removed (flutter_facebook_auth package pulled). Existing Saropa accounts linked to Facebook continued to work, but new sign-ins via Facebook were no longer offered. Users can sign in with Google or Apple, or create a Saropa account directly.
No other data-handling SDK additions or removals this quarter.

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.