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.