Let user select sandboxed directory to use?

[raucao]

Copying a new issue/request by @akumpf from the website repo:

I think the ideas behind remotestorage are great, but from the user's perspective, it seems important to let the user choose which folder to grant access to.

For example, let's say I have a folder of notes that I want to open in a "unhosted" remotestorage app. I don't want to grant full access to all my files, only a particular folder (or in the most constrained case, just a single file). While a global naming approach works (assuming that my notes are stored in a folder called "notes"), it would be a lot better if I, as the user, could decide which folder/file to grant access for a particular app.

I've also posted this question more broadly for Google Drive and Dropbox here: http://stackoverflow.com/questions/30736664/directory-sandboxed-access-for-google-drive-dropbox-api-remotestorage-apps

If this is already in remotestorage and I somehow missed it, let me know! Otherwise, I hope this can serve as a formal feature request to make remotestorage even better. :)

[raucao]

I've answered the question on SO, according to the current version of the spec. As for adding this as a new feature, I'm curious to learn what others think about this.

[michielbdejong]

If I understand the question correctly, I think this is already possible. If the server supports it, the user can untick boxes in the OAuth dialog, then the app gets a scope parameter back from the OAuth dance, and display accordingly which features will not work if not all requested scopes were granted. This is part of OAuth.

[raucao]

Yes. However, unticking boxes is not the same as telling the app "I want to use folder MyFancyDocuments for these documents" or even do it save by save.

[untitaker]

I think sandboxing apps by pointing them to separate storage roots each is a feature that can be provided by the server outside of the spec. It might be sensible to add this as a thing that the server MAY do, as a note for client implementors, but I don't think servers SHOULD implement it.

[ghost]

@untitaker that is also what I was thinking about already for a while. Maybe this should actually be the only storage available to an app, i.e. its own private storage. Sharing (data) between apps should occur using additionally (to be defined, and out of scope here) higher level APIs.

[michielbdejong]

I'm thinking in the same direction. Having per-app data makes a lot of things easier and safer. That would mean we abandon https://github.com/remotestorage/modules, right?

[untitaker]

What does "per-app" mean? Per access token?

For desktop apps there's no way to safely differentiate between apps and sessions.

[ghost]

We have to decide then how to determine the "scope" of a client, e.g. it could be the value of Origin?

@untitaker I guess per app is then per Origin?

[michielbdejong]

Yes, sorry, I mean per-origin.

I had a similar discussion when talking about "sync for the web" on the Kinto forum and with part of the Google Chrome team (in-person at edge conf). Maintaining data domain modules has so far proven harder than we initially thought.

[untitaker]

Per-access-token: You've now broken sync, since the server has separate data stores for each device.

Per-origin/redirect-URI/referrer: Desktop/native apps can easily spoof those values.

On Mon, Oct 12, 2015 at 09:49:05AM -0700, François Kooman wrote:

We have to decide then how to determine the "scope" of a client, e.g. it could be the value of Origin?

@untitaker I guess per app is then per Origin?

---

Reply to this email directly or view it on GitHub: https://github.com/remotestorage/spec/issues/88#issuecomment-147458665

[ghost]

I would actually say that it is a feature that desktop/native apps can spoof those! That makes them work too :-)

[untitaker]

You misunderstand. Desktop/native apps can spoof any origin.

That means if you identify apps by origin, native apps can pretend to be any other app and therefore your storage separation is useless against them.

On Mon, Oct 12, 2015 at 10:08:33AM -0700, François Kooman wrote:

I would actually say that it is a feature that desktop/native apps can spoof those! That makes them work too :-)

---

Reply to this email directly or view it on GitHub: https://github.com/remotestorage/spec/issues/88#issuecomment-147462963

[ghost]

Yes I know. I don't misunderstand I think. The native apps will need to obtain an access token as well, so it is not that easy to 'spoof' this. Am I missing something?

[untitaker]

I think you are. I'm not sure.

I don't see how the access token has anything to do with it.

Native apps can send any origin header they want. They can also provide any redirect URI during the auth flow. The only way you can safely differentiate apps is by their auth token. Any other way can be exploited in a native app, any other information is just as trustable as the User-Agent of your browser.

On Mon, Oct 12, 2015 at 10:22:49AM -0700, François Kooman wrote:

Yes I know. I don't misunderstand I think. The native apps will need to obtain an access token as well, so it is not that easy to 'spoof' this. Am I missing something?

---

Reply to this email directly or view it on GitHub: https://github.com/remotestorage/spec/issues/88#issuecomment-147467373

[raucao]

I think @untitaker's point makes sense. Also, having shared data is one of the main benefits of remoteStorage over other solutions at the moment, and in fact we never really had bad experiences with it so far. That might (and probably will) change, but it hasn't proven to be a real problem yet. On the opposite, I think it's one of the parts of the spec/technology with the most potential still.

The current implementation of modules and schemas is just not very good and was never really finished. I think we need to seperate schemas from the rs.js library modules and make them available outside of rs.js. That includes things like subdirectories/lists for common things (most commonly simple dirs/lists like photo albums or task lists, as well as storing data by date/time).

As @untitaker said, one can currently offer sandboxing as a feature without changing the spec in that regard. So this is already open for experimentation, and if someone implements it and finds it to be valuable, then they could present their findings and propose a spec change.

[michielbdejong]

I think @fkooman is right :) You should never install a malicious app on your device, end of story.

For websites, origins protect you.

[untitaker]

You should never install a malicious app on your device

Many users can't even properly define the words "malicious" (in the context of infosec) and "native app" vs "web app".

[untitaker]

Also I thought the whole point of a permissions system was to lower the risk of using new applications, because determining whether an app is malicious before installing it is hard.

[michielbdejong]

The current scopes are *:r *:rw, <module> :r, and <module> :rw. The proper way to do this would be to say that from now on <module> needs to match the domain name of the redirect URL. We currently have an example using the 'myfavoritedrinks' module, so we would have to update that example to use the 'drinks-unhosted.5apps.com' module.

Other apps can then still re-use data, but just instead of saying "This app wants access to your myfavoritedrinks data", it would say "This app wants access to your data from drinks-unhosted.5apps.com", and the advantage is that we can make the dialog less scary if an app only wants to access its own sandbox.

@untitaker Yes, OAuth (on which we rely a lot in this spec) assumes that your browser and the other apps installed on your computer are functioning correctly, because a malicious browser add-on (or malicious browser application for that matter) could easily send a fake redirect URL, spy on your keystrokes, and steal all your data.

[ghost]

Also I thought the whole point of a permissions system was to lower the risk of using new applications, because determining whether an app is malicious before installing it is hard.

Consider the scenario: you download an app from an app store. The app wants to access the store of https://fancyapp.5apps.com/ and "claims" the Origin https://fancyapp.5apps.com/ and also uses that as the client_id, redirect_uri and scope. It still needs to obtain an access token before it can do anything. So it opens a browser and the user will get the confirmation dialog first. It will show the https://fancyapp.5apps.com/ client_id/Origin. So the user at that point will have the choice to approve this or not.

I am not saying it is ideal, but I don't think there is actually a threat here. The confirm dialog will always still be there, opened in a browser by the 'malicious' app.

Hmmmm... there is actually no change from how it currently works... we don't even need Origin at all, it could all be linked to client_id.

Update: or redirect_uri...

[raucao]

Hmmmm... there is actually no change from how it currently works... we don't even need Origin at all, it could all be linked to client_id.

Update: or redirect_uri...

That's my point. Whoever wants to experiment with this, go ahead and report afterwards! :)

[michielbdejong]

Yes, the redirect_uri is the important part. client_id cannot be trusted because we don't whitelist a link between redirect_uri and client_id, and during OAuth, Origin header is not sent (although a Referer header probably is, so that might be one to check - not sure what OAuth says about that).

It could also make sense for a server to check the Origin header of REST calls against which bearer token is used. @fkooman what do you think of adding that restriction?

[untitaker]

@fkooman Yes, of course do the current scoping permissions work fine. However, the idea of per-app sandboxing is unreliable. If we can only provide it sometimes, I think it's better to not provide it at all, otherwise it might confuse the user and make them think: "the permissions requested may be a bit much, but the per-app scoping surely will prevent data access!" in situations where it is actually not the case.

[untitaker]

Just realized you can do much worse things to mess with auth in a native app. I guess that issue is off the table.

On 12 October 2015 22:10:50 CEST, Michiel de Jong notifications@github.com wrote:

Yes, the redirect_uri is the important path. client_id cannot be trusted because we don't whitelist a link between redirect_uri and client_id, and during OAuth, Origin is not known (although Referer probably is, so that might be one to check - not sure what OAuth says about that.

It could also make sense for a server to check the Origin header of REST calls against which bearer token is used. @fkooman what do you think of adding that restriction?

---

Reply to this email directly or view it on GitHub: https://github.com/remotestorage/spec/issues/88#issuecomment-147506369

Sent from my phone. Please excuse my brevity.

[ghost]

I was actually thinking about something different. I would like to see a data store similar to what Google provides in Chrome OS, Apple in iCloud and Mozilla in Firefox OS: every app has its own private "read write" storage. For accessing "common" things like calendars, notes, contacts cooperating with the application responsible for that is required through an API. Whether these apps are running in the browser, or are "native" should not matter. I would be great if also "native" apps could use the storage instead of using e.g. Android's storage internal storage for more than say an offline cache.

@michielbdejong I do not think restricting Bearer tokens to a redirect_uri or Origin is something that should be mandatory, especially since in my use case above it would not be helpful. Of course, making this optional, i.e. servers MAY require, is alright with me and then for clients SHOULD set the Origin header on requests.

@untitaker I do not think providing per-app "sandboxing" is detrimental. I would just not call it "sandboxing" as that is something else. I would call it "per app private storage". If the user grants other (non-web) applications the permission to use the particular storage that should be fine!

An example user story: On my GNOME desktop I want to use the Calendar application to work with my RS server and sync the appointments to/from the server.

[raucao]

An example user story: On my GNOME desktop I want to use the Calendar application to work with my RS server and sync the appointments to/from the server.

Why would you not want to be able to access that same data from other apps? That's what excites me about RS so much in the first place. :)

By the way, to me at least it was clear that this is what you were talking about. And I still think you can easily experiment with that and collect findings, without changing the spec first.

[ghost]

Why would you not want to be able to access that same data from other apps? That's what excites me about RS so much in the first place. :)

Yeah, but there is a problem with this: there should be one authority for managing data inside the private app data. If there are more than one it will be a big problem, unless you standardize the data formats there. It seems easier to standardize (or use) an higher level API to manage contacts, e.g. copy the one from Mozilla, than interop on the filesystem. If you want to use the filesystem then it makes sense to standardize on something like vCard.

Update: but then you slowly go towards requiring something like WebDAV again... so better not :)

[raucao]

Yer, what you said there is basically throw away RS and use system-specific APIs.

unless you standardize the data formats there

Yes, of course! That's the whole idea of the categories. Instead of having pre-defined APIs for just a few data types, you can standardize anything you want. We need to improve that considerably though, because most developers are actually choosing per-app storage by way of using their own category at the moment. In that sense, the current liberal situation apparently provides natural incentives to either be certain about compat or not use the same category at all.

[ghost]

But but but... I think this is actually something not so good. Having the API be the file system can be a problem. It works when you have a well defined standard and a rich enough FS API where you can do things like locking and atomic updates, i.e. getting back to WebDAV complexity. There is probably a way using JS to 'talk' to other open tabs and then this channel can be used to use higher level APIs to e.g. add something to the calendar.

[untitaker]

This is kind of offtopic, I'd suggest to continue discussion at the discourse instance.

On 13 October 2015 16:17:04 CEST, "François Kooman" notifications@github.com wrote:

But but but... I think this is actually something not so good. Having the API be the file system can be a problem. It works when you have a well defined standard and a rich enough FS API where you can do things like locking and atomic updates, i.e. getting back to WebDAV complexity. There is probably a way using JS to 'talk' to other open tabs and then this channel can be used to use higher level APIs to e.g. add something to the calendar.

---

Reply to this email directly or view it on GitHub: https://github.com/remotestorage/spec/issues/88#issuecomment-147727864

Sent from my phone. Please excuse my brevity.

[raucao]

Good idea.

[michielbdejong]

Continued in https://community.remotestorage.io/t/storage-sandbox-per-app-origin/321.

We can create a new gh issue to actually implement a specific outcome of that discussion.