I briefly brought it up in the conversation about the security of the safe launcher, but as no one has picked it up by now, I’d like to start the discussion on this. To quote what I was talking about (highlights and formatting done here for clarity):
To give an example: the facebook app asking to read my SMS might simply be so it can do the one-time phone-number authentication (I am fine allowing this) or to continuously ears-drop on all my communication with all those other ppl the app isn’t supposed to know about IMHO. Same goes for the question of whether the App can use the microphone: Sure, when I press the button to record a message, but to always listen to everything in background all day long and send it to the server?
General-Feature-based-Permission is broken by design as it doesn’t give the User enough privacy choices.
So, I continued:
As it stands today, our privacy is pretty well protected in safenet, as it is essentially a filesystem only known to the user that an app is sandboxed to only write into the users area and it takes quite some finesse to get any information out of that context (you could however – but that’s not the point here). In the whole concept of a serverless network, this is great, however, there will be occasions where you want apps to directly communicate with another “instance” of the app somewhere else: Just take the simple example of telling a “google”-like indexing mechanism that your blog was just updated and that you’d like them to index it again.
Traditionally this would have happened through a clever formatter GET or POST request to a specific endpoint of a specific server, which – in turn – would start a programme to do things. With the entire concept of moving away from a server “instance”, we are closer moving to an “actor” in the system (not as a persona within safenet but more like an “account” on safenet). This old model won’t work. Correct me, if I am wrong, but the closest I can see of that being possible soon is when we will have “messaging”, where an App could listen to incoming messages to once inbox (running on your system) and react accordingly – the messaging RFC is in the works here.
But before we start building the system now, we should stop for a moment and think about its privacy and security implications and how we can model that in a way to not have the old problems all over again. The way the launcher currently acts, you need to allow apps specific feature settings. But if we implement the messaging RFC the same way, as a feature an app might just require to work at all, we have our old tracking problem again, but worse: Not only will any authenticated app running against the launcher be able to send arbitrary information to any party (or third party for tracking), it even has a clearly identifiable user to pin this, too (as messages are always signed) – YIKES, what a privacy nightmare.
And even if we decide today to not recommend users to allow that feature on arbitrary apps, apps could easily block if they don’t have it enabled and effectively enforce bad citizenship (and as we know from experience: Tracking and Ad companies WILL DO WHATEVER IT TAKES), if it would be a possibility to do it.
Instead, I’d like to start discussing how we could build this system differently to prevent this from ever being (ab)used without the users full consent and understanding of what is going on. And I think now is a good time to start this discussion. I am looking forward to it!