Safe Browser security or access control model

Features
1

The Safe Network is a huge undertaking with the potential to revolutionize the internet as we know it. Not many people used (or knew about) Google just twenty years ago. It’s quite possible that the current model of social networking (and more) will be obsoleted by the Safe Network in another twenty years.

While the foundation of the network design is already solid, we also need to get the app side right, and preferably right from the start because it’s much tougher (if not impossible) to correct bad practices that already gained momentum–and it may end up as cludgy aftertought even if successful.

So, the point of this exercise is to figure out how far we could go with privacy and security with the model where the Safe Browser is used to mediate access between standard Safe Apps and the Safe Network, and what kind of API could facilitate that the best. Just a bit of brainstorming for ideas about things the Safe Browser should be able to control, together with some ideas about how.

I’m thinking about things like:

  • Access to hardware, such as: camera, microphone, GPS, and so on–apps shouldn’t even see things they are not explicitly allowed to access.
  • Access to Safe Network resources through transparently proxying requests. The Safe Browser stores and uses credentials on behalf of authorized apps.
  • Communication between apps on the same device, and how much they should be able to see of each other.
  • Multiple accounts or sub-accounts on the same device, and how to make it obvious which one is being used.
  • More exotic ideas, for example, a “Media Access API” that could, among others, inject filters between image sources (for example, between a Safe folder or the phone camera) and destinations (other apps, other filters). It could be useful for things like removing GPS coordinates, blurring faces or applying other filters, and I’m certain a hundred other things devs could come up with. The gist of the idea, as with all things about access control, is that it would be guaranteed that the filters couldn’t be bypassed.

I’m curious what else others can come up with, and about proposals to tie it all up into a unified and, preferably, simple framework.

14 Likes
2

Sounds like the idea of middleware. Could be really interesting stuff made with this (as your examples illustrate), but the API needs to have the right hooks to allow intercepting payloads for filtering before passing the payload on to the next middleware or endpoint.

3 Likes
3

That’s exactly what I’m talking about. We need to think about how certain functions that are can be implemented, so that the API can be made flexible enough for that.

In the simple example for when I want to remove GPS coordinates from my images, we have two options: 1) each app should ask if they can record or, in the case of attaching an existing image, retain such coordinates before posting them, 2) we don’t let the app have access to GPS data from the phone and we remove GPS coordinates from images before handing it over to it.

The first option is simply impossible. We can’t demand everything is opensourced so we can verify them, we can’t depend on unrealistic expectations about the code quality of some random app, and we can’t rely on the honesty of strangers. Most likely, the app wouldn’t worry about GPS coordinates and almost surely not about whether they are included in the EXIF metadata.

The second option gives full control but it needs some help from the Safe Browser to organize the data flow between not only the hardware and the apps but also between the apps themselves.

A possible approach (though not sure if the right one, and not very flexible) is that the secure app could pose as a virtual camera and the insecure app would be given access to that and not the real camera.

The tougher part is creating a clean and intuitive UI for end users.

3 Likes