Data Flow & Privacy Map

1. Executive Summary

This Data Flow & Privacy Map covers the Bluesky social application — a React Native / Expo mobile application built on the AT Protocol (atproto), a decentralized social networking protocol. The assessment covers 131 screens across iOS and Android platforms, examining data collection, on-device storage, server-side transmission, third-party sharing, and deletion mechanisms.

Overall Privacy Posture Rating: Moderate

The application demonstrates strong privacy-by-design principles in several areas — notably its use of expo-secure-store / Keychain for authentication tokens, its moderation-aware content rendering, and its explicit user controls for notification preferences, content language, and activity privacy. However, several medium-to-high risk gaps were identified, primarily around on-device storage practices, analytics data collection, and the scope of device permissions.

Data Categories Identified:

• Personal Data (on-device): Authentication tokens (Keychain/SecureStore), session account data (AsyncStorage-backed persisted storage), search history (per-account DID key), profile history (per-account DID key), notification preferences, language preferences, appearance settings, feed preferences
• Personal Data (server-side): Profile information (display name, handle, avatar, banner, bio), posts, direct messages, follower/following graph, likes, reposts, notification settings, activity subscriptions, app passwords, starter packs, lists
• Sensitive Data: Date of birth (collected during signup, used for age gating), email address (for account verification and 2FA), phone number (collected during contact import flow), device contacts (uploaded during Find Contacts flow)
• Special Category Data: Biometric data — not processed by the app directly; OS-level biometric APIs (Face ID, Touch ID) are used for device unlock only, not for app-level biometric identification

Top 3 Highest-Risk Privacy Concerns:

1. Device Contacts Upload (High Risk): The Find Contacts flow (/find-contacts-flow) uploads device phone contacts to Bluesky's servers for matching against registered accounts. This involves third-party PII (contacts who have not consented to the app's data processing) and requires explicit GDPR Article 6 legal basis analysis and potentially Article 9 assessment if contacts include health-related data.

2. Analytics SDK Data Collection (High Risk): The application uses a custom analytics abstraction (useAnalytics / ax.metric) that collects user behavior data including profile DIDs, post URIs, search queries, feed interactions, and navigation patterns. The underlying analytics provider is not identifiable from the codebase alone, preventing assessment of data transfer mechanisms, retention periods, and DPA status.

3. Persisted Storage Backup Exposure (Medium Risk): The application uses a persisted storage layer (likely AsyncStorage-backed) for session account data, search history, and preferences. This data is included in iOS iCloud backups and Android Google Drive auto-backups by default, potentially exposing session tokens and browsing history if a device backup is restored to a different device or accessed by a third party.

Assessment Limitations: This assessment is based on documentation-based analysis of 131 screens. It does not include live data flow tracing, device forensics, network traffic inspection, or server-side database inspection. All findings should be verified against the live application before regulatory submission.

2. Methodology & Scope

Regulatory Framework

• GDPR (EU): Articles 5, 6, 7, 9, 13, 14, 17, 25, 30, 32, 35
• CCPA/CPRA (California): Consumer rights mapping, sensitive personal information categories
• Google Play Privacy Policy requirements: Data safety section declarations
• Apple App Store Privacy Nutrition Labels: App Privacy section declarations

Privacy Standard

• ISO/IEC 27701:2019: Privacy Information Management System — privacy controls and processing inventory

Risk Framework

• NIST Privacy Framework v1.0: Identify, Govern, Control, Communicate, Protect functions

Mobile Storage Standard

• OWASP MASVS-STOR: On-device data storage security and privacy controls

Scope

All 131 screens provided in the documentation were assessed, covering:

• Server-side data flows (AT Protocol API interactions)
• On-device storage mechanisms
• Device permission data collection
• Third-party SDK integrations
• Analytics and crash reporting

Mobile-Specific Scope Additions

• On-device storage mechanisms: AsyncStorage (via persisted storage abstraction), MMKV (via react-native-mmkv in SharedPrefs native module), SecureStore/Keychain (via expo-secure-store)
• Device permission data collection: Camera, Photo Library, Contacts
• Biometric data handling: OS-level only (no app-level biometric template storage)
• Backup/restore behavior: iCloud (iOS), Google Drive auto-backup (Android)

Limitations

Based on technical documentation review, not live data flow tracing, database inspection, or device forensics. The specific storage keys, encryption configurations, and retention periods for the persisted storage layer are not fully visible from screen documentation alone.

3. On-Device Storage Privacy Assessment

Storage Mechanism Inventory

(inferred from expo-secure-store and #/state/persisted usage patterns — verify against actual storage key enumeration and encryption configuration)

Biometric Data Handling

The application does not process biometric data at the application layer. Based on the screen documentation:

Key finding: GDPR Article 9 special category classification does not apply to this application's biometric handling, as the app uses OS-level APIs that return only a boolean authentication result. The app does not capture, store, or process biometric templates.

Secure Enclave and Keystore Usage

(inferred from expo-secure-store usage — verify against library version changelog)

expo-secure-store wraps iOS Keychain and Android Keystore automatically on supported devices:

• iOS: Uses Keychain Services with hardware-backed protection on devices with Secure Enclave (iPhone 5s and later). The specific kSecAttrAccessible access class used is not documented in the screen documentation.
• Android: Uses Android Keystore system (hardware-backed on Android 6+ devices with hardware security module).

[Not documented — WHO: iOS lead; WHAT: What kSecAttrAccessible access class is used for expo-secure-store items? Specifically, is kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly used to prevent Keychain items from surviving app uninstall?; WHERE: Insert in Section 3 — App Uninstall Data Cleanup table, iOS Keychain row]

App Uninstall Data Cleanup

Backup and Restore Consent

Critical finding: The persisted storage layer contains session account data (including stored account credentials for multi-account switching) and search/profile history. This data is included in device backups by default. If a user restores a backup to a new device, their session tokens and browsing history are restored — this may be appropriate for session continuity but represents a privacy risk if the backup is accessed by a third party or restored to an unauthorized device.

4. Device Permission Data Flows

Based on the screen documentation, the following device permissions are requested by the application:

PERM-001: Camera

Source Evidence: Feed screen (/src/view/com/feeds/feed) — Section 6 (User Interactions), Section 13 (Integration Points)

[Not documented — WHO: iOS lead; WHAT: What happens when camera permission is permanently denied — is the user shown a settings redirect prompt?; WHERE: Insert in PERM-001 table, Permanently Denied Behavior row]

PERM-002: Photo Library

Source Evidence: Feed screen (/src/view/com/feeds/feed) — Section 6, Section 13

Special assessment — EXIF metadata: Photos selected from the device library may contain EXIF metadata including GPS coordinates, device model, and timestamp. The documentation does not indicate whether EXIF data is stripped before upload. If GPS coordinates are included in uploaded photos, this constitutes precise location data processing under GDPR Article 4(1) and CCPA.

[Not documented — WHO: Backend lead; WHAT: Does the application strip EXIF metadata (including GPS coordinates) from photos before uploading to the AT Protocol blob storage?; WHERE: Insert in PERM-002 table, Data Destination row, and in DC-007 (Photo/Video Data) in the Data Category Inventory]

PERM-003: Contacts

Source Evidence: Find Contacts Flow (/find-contacts-flow) — Section 1, Section 5; Find Contacts Settings (/settings/find-contacts-settings) — Section 5

Special assessment — Third-party PII: Contacts data includes PII of third parties (the contacts themselves) who have not consented to the Bluesky application's data processing. Under GDPR, this requires a separate legal basis for processing third-party data. The legitimate interest basis may apply (helping users find friends), but a Legitimate Interest Assessment (LIA) should be conducted. Under CCPA, contacts data may constitute "sensitive personal information" if it includes precise geolocation or other sensitive categories.

[Not documented — WHO: Backend lead; WHAT: (1) Are device contacts uploaded in plaintext or as hashed values (e.g., SHA-256 of phone numbers)? (2) How long are uploaded contacts retained on Bluesky servers? (3) Are contacts deleted from Bluesky servers when the user removes their contact data via the "Remove all contacts" button?; WHERE: Insert in PERM-003 table, Data Destination row, and in PA-009 (Contact Import Processing) in the ROPA section]

5. Data Category Inventory

6. Records of Processing Activities (ROPA)

PA-001: User Authentication and Session Management

Source Evidence: Login Form (/login/login-form), Choose Account Form (/login/choose-account-form), Account Settings (/settings/account-settings)

PA-002: Profile Data Processing

PA-003: Direct Messaging

PA-004: Content Feed Processing

PA-005: Search and Discovery

PA-006: Notification Preference Management

PA-007: Account Creation (Signup)

PA-008: Analytics and Behavioral Tracking

PA-009: Contact Import and Matching

PA-010: Account Deletion

7. Screen-by-Screen Data Flows

Due to the large number of screens (131) in scope, this section presents representative high-risk and high-complexity screens in detail. Lower-risk screens with similar patterns are grouped by category.

7.1 Inbox (/messages/inbox)

Data Profile:

Data Collection Points:

Data Flows:

• Inbound: chat.bsky.convo.listConvos API call fetches pending chat requests with status: 'request'; conversation member profiles fetched from AT Protocol
• Processing: Conversations filtered by leftConvos list; hasUnreadConvos computed; moderation applied via moderateProfile()
• On-Device Persistence: None — all data in TanStack Query in-memory cache
• Outbound — Server: Accept (chat.bsky.convo.acceptConversation), reject/leave (chat.bsky.convo.leaveConvo), block (app.bsky.graph.block), mark as read (chat.bsky.convo.updateRead) mutations
• Outbound — Third Parties: ax.metric('chat:open', {logContext: 'ChatsList'}) analytics event on conversation open
• Display: Conversation member avatars, display names, handles, last message preview (truncated), unread count

Privacy Concerns:

DF-001: Analytics Event on Conversation Open

7.2 Find Contacts Flow (/find-contacts-flow)

Data Profile:

Data Collection Points:

Data Flows:

• Inbound: Device contacts read via expo-contacts; contact availability checked
• Processing: Contacts uploaded to Bluesky servers; server matches against registered accounts; matched profiles returned
• On-Device Persistence: None — contacts not stored on-device after upload
• Outbound — Server: Contact data uploaded to Bluesky contact matching service; follow records created via bulkWriteFollows
• Outbound — Third Parties: None documented beyond Bluesky servers
• Display: Matched Bluesky profiles with follow/dismiss options

Privacy Concerns:

DF-002: Third-Party PII in Contact Upload

DF-003: Contact Data Retention Unknown

7.3 Account Settings (/settings/account-settings)

Data Profile:

Privacy Concerns:

DF-004: Chat Data Export Contains Sent Messages Only

DF-005: iOS Keychain Persistence Post-Uninstall

7.4 Search Shell (/search/shell)

Data Profile:

Data Collection Points:

Privacy Concerns:

DF-006: Search History in Device Backup

DF-007: Analytics Events Include Profile DIDs and Search Queries

7.5 Conversation (/messages/conversation)

Data Profile:

Privacy Concerns:

DF-008: Age Assurance Gate for Messaging

7.6 Signup Flow (Multiple Screens)

Data Profile:

Privacy Concerns:

DF-009: hCaptcha Third-Party Data Processing

8. Data Flow Inventory

Master table of all identified data flows, sorted by risk level:

9. Third-Party Data Sharing

Critical finding — Unknown Analytics Provider: The application uses a custom analytics abstraction (useAnalytics() / ax.metric()) throughout all 131 screens. The underlying analytics provider is not identifiable from the codebase documentation. This is a significant gap:

• The legal basis for analytics data collection is unknown
• Whether a DPA is in place is unknown
• The geographic location of analytics data storage is unknown
• The data transfer mechanism (SCCs, adequacy decision, BCRs) is unknown
• The analytics data retention period is unknown

[Not documented — WHO: DPO and Engineering lead; WHAT: (1) What is the underlying analytics provider behind useAnalytics()? (2) Is a DPA in place with this provider? (3) What data transfer mechanism is used for cross-border transfers? (4) What is the data retention period? (5) Is user consent obtained for analytics collection?; WHERE: Insert in Section 9 (Third-Party Data Sharing) — Unknown Analytics Provider row, and in PA-008 (Analytics and Behavioral Tracking) in the ROPA section]

10. Data Retention & Deletion

Mobile-specific retention considerations:

1. iOS Keychain persistence post-uninstall: Authentication tokens stored via expo-secure-store may persist after app uninstall on iOS. This is a GDPR Art. 17 right-to-erasure concern. Users who uninstall the app expecting all data to be deleted may have authentication tokens remaining on their device.

2. AsyncStorage backup exposure: Search history, profile history, and session account data stored in persisted storage (AsyncStorage-backed) are included in iOS iCloud backups and Android Google Drive auto-backups by default. If a user restores a backup to a new device, this data is restored — assess whether this is appropriate for each data type.

3. App uninstall as deletion trigger: App uninstall clears AsyncStorage/MMKV data on both platforms. However, server-side data (posts, profile, messages, followers) requires an API-level deletion flow via the account deletion feature in Account Settings.

11. Privacy Risk Assessment

12. Remediation Recommendations

Phase 1: Immediate (0-7 days) — Critical Privacy Risks

• [PR-001] Identify analytics provider and establish legal basis: The unknown analytics provider behind useAnalytics() is the highest-priority gap. Identify the provider, verify DPA status, document legal basis, and assess whether user consent is required. — Effort: Medium (1-3 days for identification; legal review may take longer)

• [PR-002] Document legal basis for contact data processing: Conduct a Legitimate Interest Assessment (LIA) for the Find Contacts feature. Determine whether contacts are uploaded as plaintext or hashed. If plaintext, implement hashing immediately. — Effort: High (requires legal review and potentially engineering changes)

• [DF-005 / PR-003] Implement explicit Keychain deletion on logout: Verify the kSecAttrAccessible access class used by expo-secure-store. If not using kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, implement explicit deletion of all Keychain items on logout to prevent post-uninstall token persistence. — Effort: Low (1-2 days engineering)

Phase 2: Short-Term (1-4 weeks) — High-Risk Items

• [PR-004] Assess backup exclusion for sensitive storage keys: Evaluate whether search history (searchTermHistory, searchAccountHistory) and session account data should be excluded from device backups. Implement backup exclusion for sensitive keys if appropriate. — Effort: Medium (2-3 days engineering)

• [PR-005] Implement EXIF stripping before photo upload: Verify whether EXIF metadata (including GPS coordinates) is stripped from photos before upload to AT Protocol blob storage. If not, implement EXIF stripping. — Effort: Medium (2-3 days engineering)

• [PR-006] Document and verify contact data retention: Obtain documentation of contact data retention period from the backend team. Verify that "Remove all contacts" triggers complete deletion from all server systems including backups. Communicate retention period to users. — Effort: Low (documentation); Medium (verification)

• [DF-009] Establish DPA with hCaptcha: Verify that a Data Processing Agreement is in place with hCaptcha. Disclose hCaptcha data processing in the privacy notice. — Effort: Low (legal review)

Phase 3: Medium-Term (1-3 months) — Medium-Risk Items

• [PR-007 / PR-008] Establish DPAs with feed generator operators: Identify operators of third-party feed generators that receive feed feedback signals. Establish DPAs where required under GDPR Art. 28. — Effort: High (requires identification of all feed generator operators)

• [PR-009] Pseudonymize analytics data: Assess whether profile DIDs transmitted in analytics events can be pseudonymized (e.g., hashed) before transmission to reduce privacy risk. — Effort: Medium (engineering change to analytics abstraction layer)

• [DF-007] Review analytics data minimization: Review all ax.metric() calls across 131 screens to assess whether all transmitted data fields are necessary for the stated analytics purpose. Remove unnecessary fields. — Effort: High (requires review of all 131 screens)

Phase 4: Backlog — Low-Risk Items and Best Practice Improvements

• [PR-010] Assess GDPR Art. 20 data portability scope: Assess whether the current chat data export (sent messages only) satisfies GDPR Art. 20 data portability requirements. Consider including received messages in the export. — Effort: Medium

• [DF-008] Document age assurance mechanism: Document the specific age threshold and verification mechanism used by AgeRestrictedScreen for messaging access. Ensure this is disclosed in the privacy notice. — Effort: Low

• General: Complete ROPA entries: Fill in all [Not documented] fields in the ROPA section (PA-001 through PA-010) with actual retention periods, security measures, and transfer mechanisms obtained from the backend and legal teams. — Effort: Medium

13. Glossary

AT Protocol (atproto): The open, decentralized social networking protocol developed by Bluesky. Defines the API lexicons, data models, and federation mechanisms used by the Bluesky application. All API calls use AT Protocol XRPC methods.

APNs (Apple Push Notification Service): Apple's push notification delivery service for iOS devices. Device push tokens are transmitted to APNs for notification delivery.

AsyncStorage: A React Native key-value storage system that stores data as plain-text JSON on the device. Data is included in iOS iCloud backups and Android Google Drive auto-backups by default. Not encrypted.

BCR (Binding Corporate Rules): A data transfer mechanism under GDPR that allows multinational companies to transfer personal data within their corporate group across borders.

CCPA/CPRA: California Consumer Privacy Act / California Privacy Rights Act. California state privacy laws granting consumers rights over their personal data.

DID (Decentralized Identifier): A globally unique, persistent identifier for an AT Protocol user account (e.g., did:plc:abc123). Used as the canonical identity key throughout the application.

DPA (Data Processing Agreement): A contract required under GDPR Art. 28 between a data controller and a data processor, governing how the processor handles personal data on behalf of the controller.

DPIA (Data Protection Impact Assessment): A process required under GDPR Art. 35 for processing activities that are likely to result in high risk to individuals' rights and freedoms.

expo-secure-store: An Expo library that wraps iOS Keychain and Android Keystore for encrypted key-value storage. Used for storing authentication tokens.

FCM (Firebase Cloud Messaging): Google's push notification delivery service for Android devices.

GDPR (General Data Protection Regulation): EU regulation governing the processing of personal data of EU residents.

GAID (Google Advertising ID): A unique, user-resettable identifier for advertising on Android devices. Not documented as used in this application.

Handle: A human-readable username in the AT Protocol (e.g., alice.bsky.social). Handles can change; DIDs are permanent.

hCaptcha: A third-party CAPTCHA service used during signup to verify that users are human. Collects device fingerprint and behavioral data.

IDFA (Identifier for Advertisers): A unique, user-resettable identifier for advertising on iOS devices. Not documented as used in this application.

iCloud backup: Apple's cloud backup service for iOS devices. AsyncStorage data is included in iCloud backups by default.

ISO/IEC 27701:2019: International standard for Privacy Information Management Systems (PIMS), extending ISO/IEC 27001 with privacy-specific controls.

Keychain (iOS): Apple's secure credential storage system on iOS. Used by expo-secure-store to store authentication tokens. Keychain items may persist after app uninstall depending on the kSecAttrAccessible access class.

Keystore (Android): Android's hardware-backed key storage system. Used by expo-secure-store to store authentication tokens. Keystore items are cleared on app uninstall (Android 9+).

kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: An iOS Keychain access class that restricts items to the current device and requires a device passcode. Items with this class are cleared when the app is uninstalled.

LIA (Legitimate Interest Assessment): A three-part test required under GDPR when relying on legitimate interest as the legal basis for data processing: purpose test, necessity test, and balancing test.

MASVS-STOR: OWASP Mobile Application Security Verification Standard — Storage controls. Defines requirements for secure on-device data storage in mobile applications.

MMKV: A high-performance key-value storage library for mobile applications. Used in this application via the expo-bluesky-swiss-army native module (SharedPrefs) and potentially as the backing store for the persisted storage layer.

NIST Privacy Framework v1.0: A voluntary framework for managing privacy risk, organized around five functions: Identify, Govern, Control, Communicate, and Protect.

PDS (Personal Data Server): In the AT Protocol, the server that hosts a user's data repository. Users may self-host or use a third-party PDS.

PII (Personally Identifiable Information): Information that can be used to identify an individual, either directly or in combination with other data.

ROPA (Records of Processing Activities): A documentation requirement under GDPR Art. 30 for organizations to maintain records of their data processing activities.

SCC (Standard Contractual Clauses): Pre-approved contract clauses issued by the European Commission for transferring personal data from the EU to third countries.

SecureStore (Expo): Expo's wrapper around iOS Keychain and Android Keystore, providing encrypted key-value storage. See expo-secure-store.

Secure Enclave: Apple's dedicated security chip in iPhone 5s and later, used for hardware-backed cryptographic operations including Keychain key storage.

Special Category Data (GDPR Art. 9): Data requiring heightened protection: racial/ethnic origin, political opinions, religious beliefs, genetic data, biometric data (used for identification), health data, sex life/sexual orientation. Biometric data processed by OS-level APIs (Face ID, Touch ID) does not fall under this category for this application.

TanStack Query (React Query): A data-fetching and caching library used throughout the application. Data is stored in-memory with a default 5-minute garbage collection time. Not persisted to disk.

XRPC: The remote procedure call protocol used by AT Protocol for client-server communication. Queries (reads) use GET; procedures (writes) use POST.