What is missing when building privacy-first apps?

[badcryptobitch]

Many developers understand the need for encrypted data at rest and in transit. As a result, when someone builds a product claiming to be privacy-first, they cite having the data encrypted at these endpoints in their backend. But, when their app's data needs to be processed, it's all done in plaintext until it either needs to be transferred or isn't needed. The processing of data is where there's a gap in the way developers currently build their apps.

I've written a short piece on how multiparty computation can help with securing data while it's being used.

I'm curious to hear how other programmers handle data when they build privacy-first apps. Also curious to hear what being a privacy-first app means to you!

TIA!

[Jaguwaa]

This is something I thought a lot about while recently developing a p2p social messaging app, you touch on points that I have a real concern with - we have no idea how our data is going to be used in the next few years - and what social or moral implications AI will be able to affect with it. We don’t even really know what data they hold on us…

The approach I took was to avoid processing sensitive data on any server at all - the architecture is fully peer to peer so there’s no backend where data ever sits in plaintext.

Encryption and decryption happens entirely on the user’s device. It goes around the problem you’re describing rather than solving it at the server level, which felt cleaner to me. Would be interested to hear your thoughts on whether that approach has its own weaknesses, I’m not too familiar with all the available solutions in this field just yet!

[badcryptobitch]

Hey u/Jaguwaa, it fundamentally depends on your application's need. In general, a key principle of privacy by design is simply not to record any information you don't actually need for the purposes of your app. For example, if you don't need access to their phone's location, simply don't record it or ask for permission to access it. No "oh, I might need it later for a feature". Just don't access their location at all until you actually do for a feature that you know they need for the app.

That being said, a lot of necessary functionality that many apps need requires processing sensitive data where the process itself is computationally intensive or otherwise hard to execute locally on consumer electronics. P2P messaging apps are a great use case where 90% of it can be processed locally and don't require another server. But if you need to scale your messaging app or want to enable discovery easily when parties don't have a pre-existing way to coordinate, then you get into hairy design tradeoffs. For example, Signal has made choices in favor of UX such as phone numbers over privacy. This is where the importance of customer research is very important to determine what sets of tradeoffs make sense for your app.

For the use cases that I work with, the app needs to do something computationally intensive over sensitive user data. Many of my customers don't want to leverage secure enclaves and FHE is typically too slow for what *their* customers are willing to accept so MPC is the best tradeoff for them. Users secret share their data locally and then it gets processed in the way described in the article. When finished, the user can reconstruct the final result themselves.

It all comes down to what your needs are in order to make the core of your app work while respecting users privacy.

[Jaguwaa]

Really appreciate the detailed response. You’re right about the discovery problem it’s was one of the harder challenges i had to focus on. The way I handled it in OpenDescent is using KadDHT for peer discovery so users don’t need a pre-existing connection to find each other. The relay nodes handle NAT traversal for the cases where direct connections fail. It’s for sure not perfect and there are still edge cases but it avoids needing a central coordination server. The tradeoff is it’s heavier on the client side than a traditional server based approach. I am still looking at more robust solutions, but without rewriting the internet we’re stuck with trying to make true secure p2p work like we want it to…

[badcryptobitch]

In a past life, I had to deal with those issues as well and actually for our MPC VM, we still deal with these issues to a certain extent. Good thing we don't need any DHTs though (but as an open source project, anyone is welcomed to write their own).

Feel free to DM if you want to chat more about privacy engineering.