I would just add that keeping door open for WebAssembly web apps is important for future proofing. Similar security conversations going on for wasm, and lots of exciting progress being made in rust wasm space and elsewhere…
Technically you don’t need shared accounts for many of discussed applications because it will be possible to have multiple owners for a MutableData object on the network. In fact, it’s already defined this way but for now it’s not possible to have more than 1 owner.
We had this before with pre-Authenticator apps: all writes and requests were proxied through SAFE Launcher and it served as a gateway that could manage permissions. However, this approach was deemed inefficient (you can read more about the reasoning behind the change here), and it’s not really necessary for fine-grained permissions control because all writes from apps will go through MaidManagers (vaults persona handling users, apps, and permissions).
Consequently, MaidManagers have a wealth of information about apps activity. So for example if an app creates a MutableData object without a user’s knowledge, the user’s MaidManager will still be able to know that an app did that – and pass that information to an app’s owner (a user).
So really there are several possible levels of control here: a client-side (an app requesting permissions from the Authenticator), a network level (MaidManagers + MutableData permssions), an encryption level (i.e. when you decide to share a data map with someone else), and a browser/web app level (considering that web apps run in a sandbox environment of the browser).
Same idea about MaidManagers applies here: it’s totally possible to impose a fine-grained control of what an app can or can not do on the network. It’s just that a set of rules that we can apply now is a bit limited by the permission control of MutableData.
It certainly is: all DOM API function calls are ultimately pass through the SAFE Browser and we have many options of handling or controlling it on the browser side. I think it even should be seen more from the standpoint of UX rather than technical ability
It’s more challenging with desktop apps however, but I think that containerisation of apps will help tremendously: with technologies like Flatpak or Snap on Linux we can virtualise apps environment and disallow access to clearnet or to a user’s disk entirely.
Woah, this is brilliant! [quote=“nbaksalyar, post:82, topic:26023”]
Same idea about MaidManagers applies here: it’s totally possible to impose a fine-grained control of what an app can or can not do on the network. It’s just that a set of rules that we can apply now is a bit limited by the permission control of MutableData
Thanks @nbaksalyar, you’ve maid my day.
So the answer to my key question is actually better than I had hoped, because this means that a user can limit or monitor what and where a Web app can send data.
Plus, the SAFE part works for desktop apps too as far as SAFE goes, but obviously not if it sends data out of band, via HTTP or IP sockets, for example.
This is BIG news.
It means that we can now think about the usefulness of this facility and try to design suitable UX. Again, I suggest we keep this topic just to web apps for that discussion.
I think UX, and the associated concerns above re: permission fatigue, are probably the biggest hurdles (outside of enabling the technical side of things). How to keep things clean and clear, given such murkiness that (I’d wager) most people are not interested in.
There are other options that could be available re: vetting of apps and permissions. WoT (as paul frazee is punting for beaker permission: https://twitter.com/pfrazee/status/1058830217798660096?s=19), could help simplify what apps to trust, out-with of any AppStore setup. So you don’t necessarily need one single authority to say ‘this is okay’ as with an app store. But you could opt to automatically trust things if both @nbaksalyar and @happybeing do (for example ).
(though that may be a bit down the line).
We can tell that an app wrote data somewhere, but we can’t tell what that data was, can we? So the previous example of the app somehow encrypting/obscuring data it should only locally work with and then writing them somewhere else still holds, and we can’t implement a “Allow to send X data to Y” with just this.
I mean, I really would like to see a permission model “Send elsewhere” instead of “Read”, too, but as of now I still don’t see how it would be possible to implement.
To be effective, this would need to be enforced for all apps trying to access the SAFE Network, right? And there may be cases where the user actually wants the app to have access to local storage. So there’d probably be a need to have an interface that manages that, too.
On that side, I think web apps and desktop apps should be treated the same from a user perspective, the only technical difference would be that the environment differs: One lives inside the browser, and the other within a container. Both should basically have the same level of access (as little as possible, including limitations on getting user identifiers like hardware information, etc.) by default.
I think that these should only be an “implementation detail” and not something the average user can see. Having more than one place to manage app permissions will be confusing to anyone who isn’t willing or able to learn about the system more in-depth. An exception would maybe be that there should be seperate lists of applications having access to something, and other people having access.
Another question I have: How fine grained should access be? “Give access to private storage” sounds too broad.
My suggestion here would be to only give access to folders. Any app has exactly one folder it has access to by default: Its installation dir. Access to one folder oviously also means access to all subfolders, so there should probably some sort of incentive for apps to request as specific folders as possible. Like only “Images” or even only “Images from vacation 2016” instead of the whole home/private folder of the user.