remoteStorage, Sauropod, and Browser[Id+O]Auth

[Michiel de Jong]

Hi!

Today is a nice day because I finally found the documentation of Sauropod: https://wiki.mozilla.org/Sauropod

Shane already pointed me to this existing mozilla project when we met in London, but today I finally got a chance to talk to one of the developers in the #openwebapps channel on mozilla irc.

The interesting thing is that they use BrowserId combined with strict separation between apps to auto-authorize. so whereas in remoteStorage you have to first authenticate with BrowserId, and then authorize with OAuth saying "yes, it's really OK for this app to also access my contacts and also my photos", on Sauropod there are only per-app categories, so each app is in a fenced area, where the worst they can do is go over disk quota. but by that time they probably saturated your bandwidth first. so that would be a stupid annoying app that feels broken to the user, and you don't use it again, but it will not be able to do any permanent damage to your remote storage, because it's fenced in in its own little storage partition on there.

we talked a few months back about how we can provide 'guard dog' apps that are authorized to access a certain storage area, and expose web intents so that other apps can access these areas.

web intents are more appropriate than oauth when you just want to pick one photo. because the user has to take the action to choose the photo anyway, and then the authorization is in context there.

consider a parable: you go to a restaurant, and the waiter shows you to your table. while you sit down, he asks you "do you allow this restaurant full access to your wallet?" Surprised by the stupid question, you say 'well, that depends obviously on what i will choose to eat and how much you want to charge. don't you have a menu?' and then, obviously, the waiter realises that up-front auth was bad ux here, and what he needs to implement is really per-intent auth. so he shows you a menu (compare: file picker dialog), and you see what you would like to eat, and as you choose the food, you consider the per-item authorization, which is then in context. so then you say "i hereby authorize you to charge me those 45 million Dong specified right there on this line in the menu, in the context of me getting to eat that barbecued squid (which is my intention)".

given that it is clear to me what the scope will be of your access to my wallet, and at the same time it is clear to me what the benefit will be to me of giving you that access, the choice makes ux sense to me. It's like saying 'I hereby give this app access to read that specific photo which i am pointing at right now, because i know i have the intention of making it appear inside this here tweet or whatever'

so on remoteStorage, we have two distinct cases: the 'pre-defined' categories, and 'per-app' categories. Some might be blurry, like the 'sandwiches' category is in a way a pre-defined category, but at the same time, there is unlikely to ever be more than one app using it. this opens up the option to silently auth any app you log in to to write onto your remote storage. you could do a per-app-origin quota. this is basically the situation we have with localStorage.

the bad thing of not using OAuth is that we lose the option to do one 'contacts' category, shared by all apps. but if we then install a 'contacts guard-dog app' that is going to play the role of addressbook, and that publishes a web intent, like 'pick a recipient for this message', then maybe not all apps need access to the raw contacts data.

it is also better because most apps will not need access to corrupt the data format of your address book. they only need access to do specific actions with your contacts (like picking one). there are some things we would lose with this. for instance, it separates the contacts picker from the rest of an app's ui, so say a chess app displays avatars in the history of chess moves, and the other person updates their avatar, then the app will still use the old avatar which it received (from the contacts picker!) at the time the game was played. so that's a trade-off i think.

on the other hand, if we can align our efforts with Sauropod and with Web Intents in this way, then that is also good, because then we can join forces. there can be only one future of remoteStorage for the web, and it can only happen, i think, if we join forces with mozilla (Sauropod), w3c (read write web), and google (Web Intents).

dropping OAuth would be a big change which wouldn't happen until the next protocol version (April 2012). but if we add BrowserId into the obligatory part of the protocol stack, and create the guard dog apps for the pre-defined categories, then i think it can work. in any case, it's definitely worth discussing this option i would say.


cheers!
Michiel

[Ben Adida]

On 12/14/11 6:27 PM, Michiel de Jong wrote:
> Today is a nice day because I finally found the documentation of
> Sauropod: https://wiki.mozilla.org/Sauropod

Michiel,

It's great that you've found this, but please keep in mind that this
project is highly experimental, so don't change your plans too much to
rely on it. Rather, if there are ideas we can work on together, I think
that would be best.

-Ben

[Michiel de Jong]

Hi Ben!

Thanks for the warning, and for the offer of working together! That would really be absolutely splendid for our goals, and also a dream come true for me personally of course.

Right now (subject to change, as always), I see two Big Questions regarding "per-user data on the web" that need to be worked on:

1) should we (like in readwriteweb) use ACLs to allow writing to /other/ people's pods, or (like in remoteStorage and sauropod afaics) just not bother with that [in the first version]? I think Melvin is in the best position to work on that question right now, in the context of Opentabs development.

2) should we use OAuth (like remoteStorage) or fenced data partitions (like sauropod) for deciding which app can write where? I already discussed with Jan yesterday that before we can continue discussing scenarios like this one, we first need to see what it looks like. Let me create a "myfavourite..." demo about this question, then it will be easier to talk about it.

I'll report back as soon as i have a demo to show about the second question (probably in about a week), so we can research/discuss it jointly.


Cheers!
Michiel

[Melvin Carvalho]

On 15 December 2011 09:27, Michiel de Jong <mic...@unhosted.org> wrote:
> Hi Ben!
>
> Thanks for the warning, and for the offer of working together! That would
> really be absolutely splendid for our goals, and also a dream come true for
> me personally of course.
>
> Right now (subject to change, as always), I see two Big Questions regarding
> "per-user data on the web" that need to be worked on:
>
> 1) should we (like in readwriteweb) use ACLs to allow writing to /other/
> people's pods, or (like in remoteStorage and sauropod afaics) just not
> bother with that [in the first version]? I think Melvin is in the best
> position to work on that question right now, in the context of Opentabs
> development.
>
> 2) should we use OAuth (like remoteStorage) or fenced data partitions (like
> sauropod) for deciding which app can write where? I already discussed with
> Jan yesterday that before we can continue discussing scenarios like this
> one, we first need to see what it looks like. Let me create a
> "myfavourite..." demo about this question, then it will be easier to talk
> about it.
>
> I'll report back as soon as i have a demo to show about the second question
> (probably in about a week), so we can research/discuss it jointly.

Sauropod looks like a cool concept. I just had a read through of the docs.

I do like the ACL model, am currently going through the OAuth 2.0 spec
to see if they also allow something similar ... will post back after
I've increased my knowledge! :)

Looks like lots of people are working towards similar goals, some work
to do, but it seems reasonable that we can have this aligned (at least
at a high level) by the next protocol release (April)

[Melvin Carvalho]

On 15 December 2011 09:27, Michiel de Jong <mic...@unhosted.org> wrote:

> Hi Ben!
>
> Thanks for the warning, and for the offer of working together! That would
> really be absolutely splendid for our goals, and also a dream come true for
> me personally of course.
>
> Right now (subject to change, as always), I see two Big Questions regarding
> "per-user data on the web" that need to be worked on:
>
> 1) should we (like in readwriteweb) use ACLs to allow writing to /other/
> people's pods, or (like in remoteStorage and sauropod afaics) just not
> bother with that [in the first version]? I think Melvin is in the best
> position to work on that question right now, in the context of Opentabs
> development.
>
> 2) should we use OAuth (like remoteStorage) or fenced data partitions (like
> sauropod) for deciding which app can write where? I already discussed with
> Jan yesterday that before we can continue discussing scenarios like this
> one, we first need to see what it looks like. Let me create a
> "myfavourite..." demo about this question, then it will be easier to talk
> about it.
>
> I'll report back as soon as i have a demo to show about the second question
> (probably in about a week), so we can research/discuss it jointly.
>

In general I think there are 3 visibilities that are *really* useful

1 Private
==========

Kind of goes without saying that the user should have some private
storage ability.

Encryption is a bonus. Dropbox do some aes but they have the key.

2 Public
=========

This is normally added with most cloud stuff ive seen (amazon, u1, dropbox etc.)

Kind of also speaks for itself

3 Friends
=========

Somewhere between a nice to have, and a must.

This is less ubiquitous, however I'd say there's strong reasoning behind it.

Facebook grew in popularity as essentially a shared space among
friends. This alone could be a strong motivation, it's the 'social'
thing to do, not to mention the ability to go viral through friend
connections.

I know dropbox allows shared access to files. Google circles raises
the bar even further, but may be overkill for a first version.

A good way to achieve this, imho, is access control lists. I checked
over the weekend with the OAuth list and they said this is possible
using OAuth. Read / Write web spaces such as data.fm are already
implementing first versions of access control lists too. I have
already found this to be very useful in starting to implment apps.

So I think (1) and (2) are natural extensions of cloud storage over
HTTP. (3) may be newer but I think there's growing call and good
motivation. Just my $0.02 :)

[pir...@gmail.com]

This remind me the unix user-group-others priviledges, isn't it?

Sended from my Android cell phone, please sorry the lack of format on the text and my fat thumbs :-P

[Michiel de Jong]

Hi!

Forgot to report back on this thread. Here goes.

On Thu, Dec 15, 2011 at 10:27 AM, Michiel de Jong <mic...@unhosted.org> wrote:

2) should we use OAuth (like remoteStorage) or fenced data partitions (like sauropod) for deciding which app can write where? I already discussed with Jan yesterday that before we can continue discussing scenarios like this one, we first need to see what it looks like. Let me create a "myfavourite..." demo about this question, then it will be easier to talk about it.

I'll report back as soon as i have a demo to show about the second question (probably in about a week), so we can research/discuss it jointly.

 ok, so 'a week' was optimistic, and instead of making a demo app we put it straight into Libre Docs. And then took it out again. The thing we did was add an extra attribute into the remoteStorage webfinger link called 'browserid-access', to which an app could post its /own/ assertion, so an assertion with the app as the audience, and get back an OAuth token for its /own/ category, so a data scope that has the app origin (audience) as its unique identifier.

This had advantages:

- the user does not have to go through the OAuth dialog
- the user does not have to go through BrowserID a second time

and disadvantages:

- storage providers would still need to provide OAuth, so that other apps can always still export data from an app-gone-rogue when necessary.
- no multiple apps can work on the same data; each app needs to have its own fenced-off data category. this means you would rely fully on web intents for apps to collaborate, or that you would only use the BrowserID-access category as a scratch pad, and then /still/ use OAuth for categories like 'contacts', 'photos', etcetera.
- storage providers need to implement 4 special things (the existing OAuth, CORS, Webfinger, plus BrowserID-access) which is extra burden.

So yeah, 3 against 2 made us think we shouldn't propose it. :)

Also, the impact of the OAuth dialog and the second BrowserID dialog is less than it may sound, because if a user uses n apps in their entire life, then they will only be confronted with it n-1 times. Namely, 'n' because it's only the first time you use an app (subsequent visits to an app can reuse the token that was generated in the first visit). And, '- 1' because if you visit for instance Libre Docs and have no remoteStorage yet, then you will sign up for one, and during the sign up process, the OAuth token can silently be generated by the app itself, and planted on the storage without asking. You are signing up for the storage through a certain app, so it's safe to assume you want to allow that app access to it - so that you can actually use it.

So in short, we explored this option, but our conclusion is we should probably leave everything as it is now (see http://www.w3.org/community/unhosted/wiki/RemoteStorage ). Comments and reactions welcome!


Cheers,
Michiel.

[Ben Adida]

On 1/16/12 8:12 AM, Michiel de Jong wrote:
> ok, so 'a week' was optimistic, and instead of making a demo app we put
> it straight into Libre Docs. And then took it out again. The thing we
> did was add an extra attribute into the remoteStorage webfinger link
> called 'browserid-access', to which an app could post its /own/
> assertion, so an assertion with the app as the audience, and get back an
> OAuth token for its /own/ category, so a data scope that has the app
> origin (audience) as its unique identifier.

This is very similar to stuff we've been exploring.

I've also been toying with the idea that BrowserID could replace, in a
user-centric way, the "dance" portion of OAuth. This is so raw I haven't
even posted it on the dev-identity list, but since we're discussing
OAuth here, I'm wondering what your take is? Might BrowserID be the
right place to present a dialog that says "do you want to allow site A
to authenticate as you to site B?"

-Ben

[Thad Guidry]

I've also been toying with the idea that BrowserID could replace, in a
user-centric way, the "dance" portion of OAuth. This is so raw I haven't
even posted it on the dev-identity list, but since we're discussing
OAuth here, I'm wondering what your take is? Might BrowserID be the
right place to present a dialog that says "do you want to allow site A
to authenticate as you to site B?"

-Ben

Is it at all possible for an app or a browser app to disguise itself as a BrowserID dialog and force a YES answer even when the user clicks on NO ?  Is it even a remote possibility for hijacking anywhere along the path ? or faked path ?

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Ben Adida]

On 1/16/12 6:45 PM, Thad Guidry wrote:
>
> Is it at all possible for an app or a browser app to disguise itself as
> a BrowserID dialog and force a YES answer even when the user clicks on
> NO ? Is it even a remote possibility for hijacking anywhere along the
> path ? or faked path ?

I think you're talking about click-jacking, because the only way that a
phishing action causes a true action to occur is either by stealing the
credentials, or by framing the real site with a fake overlay.

We do extensive clickjacking protection on BrowserID, and when the
dialog goes native, of course, clickjacking will be inherently impossible.

Let me know if that answers your question. And maybe it's time for me to
take this thread to dev-identity :)

-Ben

[Thad Guidry]

Yes clickjacking is what I was referring to.  Do you expect the dialog to go native ?  Will that truly solve the potential for clickjacking loopholes ?

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Ben Adida]

On 1/16/12 7:24 PM, Thad Guidry wrote:
> Yes clickjacking is what I was referring to. Do you expect the dialog
> to go native ? Will that truly solve the potential for clickjacking
> loopholes ?

So modern browsers already support the X-FRAME_OPTIONS HTTP header [1]
that strictly prevents framing/clickjacking, and we have that deployed
already on BrowserID. That should be a solid solution to this problem.

When we go native with the dialog (and yes, we do expect this at least
on Firefox in the second half of 2012), the protection will be at least
as strong.

-Ben

[1] https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header

[Thad Guidry]

Ah, makes sense now... Thanks for the pointer, Ben.

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Michiel de Jong]

Hi Ben!

On Tue, Jan 17, 2012 at 4:39 AM, Ben Adida <b...@adida.net> wrote:

I've also been toying with the idea that BrowserID could replace, in a
user-centric way, the "dance" portion of OAuth.

Yes, I think there's stuff that can be done there.
 

I'm wondering what your take is? Might BrowserID be the
right place to present a dialog that says "do you want to allow site A
to authenticate as you to site B?"

Since this is relevant for BrowserID and not specific to Unhosted, I replied here:

http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/803f8ab7812d7d20

If anything, this is definitely interesting stuff to think about!


Cheers,
Michiel