Skip to main content

25. Privacy-First Architecture

Status: Accepted Date: 2025-07-06

Context​

The AnyTracker application is designed to handle extremely sensitive personal data related to substance consumption and personal habits. The core value proposition of the application is user control and trust. A traditional client-server architecture, where user data is stored on a central server, would create a significant privacy risk and a high-value target for data breaches. Users would have to trust a third party with their most sensitive information.

Decision​

We will adopt a "privacy by default," local-first architecture. All user data will be stored exclusively on the user's own device. The backend will be stateless and will not persist any personal tracking data on the server. If any data needs to be transmitted for processing (e.g., for natural language understanding), it will be done over an end-to-end encrypted channel, and the server will not log or store the content of the request. The user is in complete control of their data at all times.

Consequences​

Positive:

  • Maximum Privacy & Security: User data never leaves their device, eliminating the risk of server-side data breaches and unauthorized access.
  • User Trust: This approach builds strong trust with users, as they have full ownership and control over their sensitive data.
  • No Server-Side Data Costs: Reduces server-side storage and database management costs to zero.
  • Offline Functionality: The application can function fully offline, as all data is stored locally.

Negative:

  • No Automatic Multi-Device Sync: This is the primary trade-off. Since data is not stored on a central server, it cannot be automatically synchronized across multiple devices.
  • Data Loss Risk: If the user loses their device or uninstalls the application, their data is permanently lost unless they have made their own manual backup.
  • Complex Feature Implementation: Features that typically rely on a central server, like collaborative tracking or web-based dashboards, are much more difficult to implement.

Mitigation:

  • Explicit Communication: Be transparent with users about this architectural choice and its consequences. Clearly state in the application's onboarding and documentation that data is local-only and will be lost if the app is deleted.
  • Manual Backup/Export: Implement robust, easy-to-use features for users to manually export and back up their data to a location of their choice (e.g., as a CSV or JSON file).
  • Future Peer-to-Peer Sync: For future multi-device sync, we will explore privacy-preserving peer-to-peer synchronization technologies rather than a centralized server model.