Inter-app access control

1

In a another thread “Nice writeup of International Semantic Web Conference by Helena Deus” there is this quote:

Does that mean application A cannot access my data generated by application B?

To be more precise, this is the scenario I am concerned about:

  • I open a contact manager application “A” and grant it access to my data.

  • Using the contact app “A” I store all my contacts in my POD.

  • Then I open a memo writing application “B” on some other website and grant it access to “my” data.

The question is now - is the memo app “B” able to read all my contacts created in app “A”? Is there any kind of protection against this? Does “B” have to ask for my consent to access the data from app “A” - or can “B” just read any data on my POD?

I ask because I have been unable to find documentation about this. I have only found specs for granting other users (WebID identities) access to my data using access control lists … but how about hiding one app’s data from another app?

And if Solid does specify this kind of protection - where can I then find the specs? And how do apps identity themselves?

Thanks, Jørn

2 Likes
2

I don’t know if I can answer you question entirely, but I’ll provide my two cents:

but how about hiding one app’s data from another app?

With Solid it’s your data not the app’s data. Different apps are just different views of your data. So, if you put your data in an area which is readable by everyone, for example, then every app can read it, no matter how you put it there (i.e. which app you used to put it there).

4 Likes
3

To clarify a bit:

In general, the authentication for reading/writing your data happens between your browser and your POD. So Application A isn’t writing to your POD… they’re just providing a UI for you to update your POD.

If you did want an application to have access directly to your POD, I think you could do the following:

Set up a space in your pod which only yourself and App A to read/write. This probably means setting the ACL on directory in your POD explicitly granting App A’s solid webid (yes, the web app would have an ID) permission to Read and Write.

When you go visit App B, if you’re still authenticated, you could still view that data, since you are also allowed to read/write that data. However, the app itself would not be able to (e.g. the web server couldn’t make a request to your POD to change the data).

I’m fairly new here… so I may stand corrected on some of these, but that’s my understanding right now :smiley:

2 Likes
4

Yes, that is also my understanding of how Solid/PODs work - and I think there is a privacy issue with that.

Its like how it is on “old”-ish systems like Windows where every application have access to all of my hard disc - making it possible for rogue applications to harvest all my data.

And it is unlike “modern” mobile systems like iOS (and Android I believe) where each application only have access to their share of your data.

The problem is that I am allowing those different UI’s, as you call it (rightly), complete access to all of my data - not only a share of it.

It would be nice if an application could ask for access to my Contacts or my Images etc. But how it should be done with Linked Data, I do not know.

Thanks :+1:

2 Likes
5

See my second section above for that sort of thing. If an application registers itself with a Solid ID then you can grant access based on that and not put the “public” type of ACL on that info

1 Like
6

Ah, this one?

When you go visit App B, if you’re still authenticated, you could still view that data, since you are also allowed to read/write that data. However, the app itself would not be able to (e.g. the web server couldn’t make a request to your POD to change the data).

I think we are talking about different kinds of apps here - I only speak about the in-browser apps. No server communication is involved here.

The in-browser app “B” will still be able to access any and all of my data since I am logged in to my POD (in the browser) and using app “B”. As you say, apps are only UI’s on top of the data.

And nothing hinders app “B” JavaScript code to harvest all of my data and using Ajax to send it to it’s corresponding backend server.

/Jørn

1 Like
7

I think you describe the issue correctly. And I think Solid’s way to deal with this is through CORS (‘same origin’ policy, or similar) so that an app has access to your server, but can’t write to another.

I’d like to understand this better myself too because I’m not sure if it is bullet proof. This is currently a hard problem in the Web so I’m not sure how well anything can protect against it using existing browsers and protocols, so an important question.

I may be wrong, so better verify this, and I may have used the wrong terminology (CORS).

1 Like
8

I am not fluid in CORS, but I do not think it solves the problem since the POD server actually wants to serve all ajax requests for all apps. See for instance https://github.com/solid/solid-tutorial-angular/blob/master/solid_spec.md#cors---cross-origin-resource-sharing.

The default behavier on the web is “Same origin policy” (see https://en.wikipedia.org/wiki/Same-origin_policy) - but in Solid we actually want “Any origin policy”.

And it makes sense to allow it too. Assuming two apps https://app-a.com and https://app-b.com: to allow both to work with my POD at https://my-pod.com, the POD server has to allow requests from each app. And I do want both apps to be able to access my POD - but only a sub-set of it (namely “My contacts” OR “My memos” - not both).

I am pretty sure Solid apps could identify themselves by a certificate exposed by the server they are served from - and Solid apps could in principle use that to make authenicated requests to my POD where they BOTH pass my credentials, to access my data, AND some “app token” that can be verified by their corresponding server side certificate. The POD server could then slice the data by assigning each Solid app their own private share of my POD data.

And on top of that we then need the ability to grant different apps access to each other’s data.

/Jørn

3 Likes
9

Thanks, maybe one of the Solid folk has better insight on this issue. We have the same concern on SAFE Network, and this is one reason why we have SAFE specific browser which, by default, won’t let apps access http(s):// at all (only safe://), but evenso it is hard to stop an app from storing data to a place that leaks it. It’s a smaller problem for us, because an app must have access rights to the place it writes - which in effect means the user running the app must have those rights (rather than the app), but I think a dodgy app could write to a place where, say, anyone can write.

It is easier to deal with though, both through limiting the amount of data an app can write on your behalf, and through detection of this kind of behaviour.

I expect there will be further measures added to prevent this in SAFE (such as limiting where an app can write to a storage owned by the user), but at this time that is it.

I think this is an important privacy issue so I’m hoping it can be made watertight.

1 Like
10

That thing about CORS and allowing any website to access my POD combined with this part of the spec https://github.com/solid/solid-tutorial-angular/blob/master/solid_spec.md#finding-out-the-identity-currently-used scares me a bit.

The referenced spec states:

Regardless of the authentication mechanism that was used during an HTTP request, the server must always return a User header, which contains a URI representing the user’s identity

It makes me believe that any and all website on the great Internet can embed a piece of JavaScript that tries to do an ajax request to for instance the solid.community server and 1) get the WebID reference back and then 2) use the rdflib.js code to read all my data, as if I requested it manually, without me ever noting it or giving conset to it.

Can that really be true?

11

Okay, turns out the “User” header is for WebID-TLS only (if it works at all, that spec reference was three years old). There is no User header when signing in using OpenID Connect.

12

I just spent a few hours looking at lists of pre-existing rdf ontologies for use in modeling the data for an app idea. The vast preponderance of them had their origin in government and academic settings where the overriding concern was how to make the data easily shared and easily combined/mashed. The privacy concerns of individuals in apps designed for a ‘Person’ as the data owner just don’t exist in those contexts, and as a result, have not yet been made a priority. It’s clear that the answer here is ‘we haven’t figured that out yet, what do you think we should do?’

If I, as an institution, have written the application that I am running against my Solid server, it’s probably ok to assume that I don’t need to worry overmuch about privacy access controls. But individuals need methods to ensure that applications from 3rd parties can be trusted to enable and respect privacy constraints, while still supporting ease of data sharing / mashup, when desired.

I think it’s something that needs its own working group to focus on the issue. Any community protocol on establishing one?

2 Likes
13

In thinking about how access security might be implemented I’ve been considering the data I want to have for my related apps.

As the owner of the data: ‘personalProperty’ and ‘friends’, I want to allow my friends to see a filtered list of my personal property, limited to those tagged ‘shareable’,‘toGiveAway’,‘forSale’ allowing only apps that support such filters to expose my property data to only my friends.

As the owner of the data: ‘personalProperty’, I want to allow my insurance company to see a filtered list of items that were stored in my home that was destroyed by fire, including linked (meta) data: aquisitionDate, photos, modelIds, serialNumbers, storageLocation, cost, replacementValue, receipts, wasGift, (but not giftedBy) allowing only apps that support such filters to expose my property data to my insurance company, and related persons, such as independent agents or their/my legal representation.

As the owner of the data: ‘personalProperty’, I want to create a schedule b form in support of my federal bankruptcy filing. I want to allow a selected application to produce an ordered list of personal property including only metadata subType, description, ownershipClassification, currentValue, appraisal - allowing only applications that support this filter to expose this data to their report formatting app or my legal representation.

I have other use cases for this data, but I think I’ll stop at these three, for now. It seems to me that access control needs to be via query or ‘view’ in order to support the fine grain privacy control that Data owners who are individuals have come to expect.

Next up for discussion: create, update, delete permissions on data. In the context of individual ownership of data, does permission to create/update a type of data imply permission to delete? Not necessarily. What if meta/linked data not supported by your app exists? What support for end user UX messaging should exist to explain delete failure in such cases?

3 Likes
14

Further to the ‘friends’ filter/view. If the user controls what friends can see, does the user have control of which apps their friends can use to see the data? I can imagine a generic ‘friendView’ filter under the complete control of the user, which could then be granted permission by any app being used by a friend to view the data.

15

The way sharing is done today is by controlling access to resources - e.g. files. You grant access to agents, whether that be users or an app acting on the behalf of the user. The UX of this is a bit crude today, and we’re working on mechanisms/models that enriches this approach.

A short contribution to a long thread, but I hope this helps? (I’m still learning the model myself, so I might not be completely understanding it all yet, so take it with a grain of salt.)

1 Like
16

So, how and by whom is this being addressed? Is there a working group? Should there be one? I’d like to follow the progress, and perhaps contribute. I would certainly like to contribute my use cases outlined above. I find it helps to have a consistent set of examples to center discussion around, in order to save time, and ensure everyone is on the same page.

I created a thread for this question here:

2 Likes
17

Right now Solid is all about filtering by WebId. It is as though you have a choice about who you invite into your house, but once they are there you also need to be able to have some choice about what it is that they do. I think for questions about what data is harvested, and what 3rd party apps have access to what data, this is very relevant. So we need filters not just for people, but for ideas. We need to be able to set rules based on ideas, not just based on people or organizations of people. For this, a capability to do natural language processing seems pretty fundamental. That piece is fundamental to privacy just as filtering by people and their id’s.

18

Well, it is slightly worse than that - you do not even have to invite them! If they know where you live they can just walk in all by themselves - given that you visit their website.

Scenario:

  1. It is normal for people to make their webID public available on the web together with some kind of contact information, just like being listed in a phonebook (see for instance Ruben’s friend list https://ruben.verborgh.org/profile/#me or https://www.npmjs.com/package/solid-server#contributing).

  2. Using the public information and some social engineering, an attacker can craft a message to those people and ask them to visit a certain web page.

  3. Once they visit the webpage, it can use rdflib.js to access their data in the background - and if they happen to be logged in, the website can read/write/modify/delete any and all of their private data.

This is possible due to the fact that there is no application validation - I do not grant access to an application. This is very unlike Facebook and others where I explicitely have to grant each and every third party application access to my data before they can, well, access it.

19

Things to understand about the current situation as of 2018/10. You need to distinguish between different sorts of aps.

  • If you install a native app on you mac or pc, under mac os, linux, etc, then it runs under you control with full privilege, like Word or Quicken, or Chrome. The OS doesn’t give us the ability to stop it accessing anything you as a person can access. Desktop apps are trusted.

  • If you run a web app in a web page, the browser does severely limit its access to anything on the web, using the Same Origin Policy, and in complicated way allows limited access between different web apps, where a web app is defined by the domain, “origin”, likefoo.solid.community. Web apps are not trusted. That’s largely why each user gets a different domain. In solid, if you try to get at data from a web app, then the web app AND you must BOTH have the access required in the Access control system. You do this with the ACL by making an Authorization which has an origin property. Because that is a bit fiddly, we are also thinking about giving the publisher of data a way to say, in their public profile, a list of webapps they trust and will allow users to use with their own data.

  • If an app runs as a service at a remote place on the internet, some other computer out there, then it can only get access to the your data by logging in just like a person. It has to be set up with a way of storing the password (or certificate) it uses in a secure way. You then give it access just like a person. You can put it in groups, even. so yo can allow myimaginaryphotoprintigservice.com to have read access to your photos. Remote services are agents which are authorized just like people .

  • If an app runs on a locked-down system like iOS, the operating system can limit its access. As far as I know, IoS, while it does allow you to block an app from accessing the web, there isn’t as far as I know yet a way in which it warns the server which app is going the access (like the browser does for a web app). The solid code cannot control iOS apps. Apple does. iOS apps are trusted if (but only if) you give them network access.

So when we talk about authentication of apps, we have to distinguish between these situations. The most pressing case is webapps, the most complex, and the place where we can potentially addd more functionality specifically to the solid platform.

10 Likes
20

Ah, thanks :slight_smile: So there is actually a (future idea) way to protect against mailicious web apps, by including the value of the “Origin” header in the access control list. That makes it possible to solve the privacy problem.

The next step would be to make that solution a bit more accessible, by for instance 1) disallowing access by default, and 2) adding a standard protocol/workflow for granting access in an easy way.

Again, thanks for the clarification.

2 Likes