When we set out to build Tap, we wanted to break the mold. Many of us, myself included, have worked on products that collect vast amounts of user data, store it in centralized databases, and track user behavior. This has become standard practice, but it doesn’t have to be.
At Tap, we started with a blank slate—a rare opportunity to rethink the fundamental principles of data collection and privacy. Our vision was clear:
- Minimize data collection from users—adopting a “Privacy by Design” and “Privacy by Default” approach.
- Ensure all personal data is encrypted, accessible only by intended recipients.
These principles sound straightforward, but implementing them was anything but simple. Here’s how we approached the challenge.
Reinventing the User Profile
Most apps require user profiles, typically created by collecting an email address and password. This immediately conflicts with our first principle of minimizing data collection and leans dangerously close to violating the second principle if that information isn’t securely encrypted.
Our solution?
- We generate a user profile automatically when the app is opened, without requiring user input.
- A random email is assigned to the account (for future functionality), and a highly secure password is created behind the scenes.
The result?
- No data from the user.
- A functioning account.
- Complete anonymity.
Securing Requests with Asymmetric Cryptography
The heart of Tap is enabling users to send secure data requests to organizations and receive their personal data in return. This process leverages asymmetric cryptography, which uses a pair of keys:
- A public key to encrypt data, shared openly.
- A private key to decrypt data, kept secret.
When a user sends a data request, it’s encrypted with the organization’s public key, ensuring only they can decrypt it. But this introduces a challenge:
- Most organizations lack expertise in key management.
- It’s impractical and insecure for every team member to handle encryption keys individually.
Our approach:
- Issue Keys for Organizations: We generate and store the keys for organizations, allowing them to manage data securely without requiring deep technical knowledge.
- Add Extra Protection: Organizations can optionally (and soon, mandatorily) set a shared team password, which encrypts their private keys. This ensures that even if we have the keys, we can’t access them.
When an organization decrypts a request, it happens locally in their browser, not on our servers. This provides an additional layer of security, even if our database were compromised.
Responding Securely
Handling responses is slightly simpler:
- Users generate their keys on their devices, and we never have access to the private keys.
- Organizations encrypt responses client-side before sending them back, ensuring no unencrypted data touches our servers.
Encryption in Action
You can see the encryption process in real-time within Tap’s interface. Encrypted requests and responses momentarily flash across the screen, offering a glimpse of the secure infrastructure at work. This transparency is intentional—it showcases the robustness of our encryption.
The Cost of Doing It Right
Building a product with this level of encryption wasn’t easy.
- Retrofitting such features into an existing platform would have been nearly impossible.
- From the ground up, encryption added approximately 50% more time and budget to our development process.
But the trade-offs were worth it. Minimizing our data footprint means we can’t rely on traditional data-monetization models. Instead, we’ve embraced alternative business models aligned with our mission of empowering users.
A New Standard for Privacy-First Apps
At Tap, our goal isn’t just to help people reclaim control of their data—it’s to prove that tech products can thrive without exploiting user information.
We’re proud of the boundaries we’ve pushed in data collection and encryption. It’s a challenge, but it’s also a necessary step toward a more ethical and secure digital future.
After all, your data belongs to you—not us.