Comment by dkoston | Hacker News Reader

Comment by dkoston | Hacker News Reader

What’s not clear to me is how this will work from a data storage and access standpoint.

In order to have a permissions system, you have to have permissions. For example: read:photos, write:photos, read:running_data, etc

In order to do that, there are a few hurdles:

  - You have to define ACLs for every type of data stored in everyone’s POD. 
  - More complex is to define what parts of what data certain ACLs give access to. For example: I may want to provide heart rate data from my runs, workouts, and temperature data but not GPS. That’s getting very granular 
  - Since every app will have different or possibly new types of data, having a central standard for data types and ACLs will be tough. 
  - You’ll also need a mapping mechanism for where the data is stored and how it’s named and the formats that are being used. Even within a single app, you can denotmalize data and store it in multiple places for different purposes.

I like the principle of this but it seems very challenging to adopt. I look forward to seeing someone solve the above challenges.

Right, so that's one of the reasons why Solid is built on top of Linked Data and RDF, we need the power of these technologies to support those advanced use cases.

The Web Access Control spec is here: https://github.com/solid/web-access-control-spec . In principle, we could support really granular data ACLs based on that spec, the ACL applies to a URL, and you can give any datapoint a URL, so problem solved. In practice, it may become a bit cumbersome, I suppose it remains to be seen how you'd do it in practice, but I think we have a really good start there, there's lots of stuff that can be realized now.

There's a wealth of academic research that applies to these problems, the problem of the Semantic Web community has been that it has been strong on the academic stuff, but not very focused on truly useful stuff that can be done right now (to quote AaronSw). That's one of the things that Inrupt sets out to change. But the good thing is that we're not setting out to solve really hard problems in the dark, since we have that academic research, we know pretty well what's hard and what should be within reach.

Thanks for the thoughtful reply. I think this is a good start and the question still remains as to how usable it will be.

We’ve seen this issue on mobile where users give access to certain capabilities on their phone and then are surprised at how apps use them (camera, mic, location, etc).

The challenge is how to describe these things in the way that the average user can understand and trust.

ACLs, capabilities, etc are generally easy for developers to consume but much harder for the average person to understand.

My main thought is that there will need to be some standardization of data and how it is consumed for this to take off. If a consumer is providing access to their location data in 15 different ways for 15 different apps, how are they even suppposed to keep track and understand that?

Standardization of ACLs/access has become standard on mobile and the permissions are very coarse so they aren’t overwhelming but it often leads to unwanted results. I’ve yet to see someone implement ACLs in a way that is easily consumable by the average user.

As noted, I’d love to see that happen. It’s a tough problem to solve but one that would benefit all users.

it's probably better to use capabilities (as in: having a secure handler to some resource means having some kind of access to it), instead of ACLs. As in Sandstorm (see https://docs.sandstorm.io/en/latest/using/security-practices...)

(note that URLs can't be a secure handler, since it's just a string that anyone can create. But a URL plus a cryptographic signature could be)

Same questions I have from reading "Build a Solid app in your lunch break", the app leverages the friends stored data but makes no mention of how the permissions system might work.

Reply on news.ycombinator.com