Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

Without the benefit of full context (I only started following this list
recently), I'd like cautiously to suggest that the UM solution to Ian's
"challenge" seems awkward because the challenge is itself a poor design, and
UM tends to be more difficult to work with when used to implement designs
that are poor in the first place.

Specifically -- and note that I'm not sure I follow all the details, so I
could be missing things -- it seems that the challenge calls for site B to
be hard-coded to talk to site A.  In a better world, site B would be able to
talk to any site that provides feeds in the desired format.  In order for
this to be possible, the user obviously has to explicitly "hook up" site B
to site A somehow.  Ideally, this "hook-up" act itself would additionally
imply permission for site B to access the user's data on site A.  The
natural way to accomplish this would be for an unguessable access token to
be communicated from site A to site B as part of the "hook-up" step.  Once
such a mechanism exists, UM is obviously the best way for site B to actually
access the data -- CORS provides no benefit at this point.

So how does this hook-up happen?  This is mostly a UI question.  One way
that could work with current browsers would be for the user to copy/paste an
unguessable URL representing the capability from one site to the other, but
this is obviously a poor UI.  Instead, I think what we need is some sort of
browser support for establishing these connections.  This is something I've
already been talking about on the public-device-apis list, as I think the
same UI should be usable to "hook-up" web apps with physical devices
connected to the user's machine.

So imagine, for example, that when the user visits site A originally, the
site can somehow tell the browser "I would like to provide a capability
implementing the com.example.Feed interface.  The URL for this capability is
[something unguessable].".  Then, when the user visits site B, it has a
"socket" for an object implementing "com.example.Feed".  When the user
clicks on this "socket", the browser pops up a list of com.example.Feed
implementations that it knows about, such as the one from site A.  The user
can then click on that one and thus hook up the sites.

Obviously there are many issues to work through before this sort of thing
would be possible.  Ian proposed a new <device> tag on public-device-apis
yesterday -- it serves as the "socket" in my example above.  But, how a
device list gets populated (and the security implications of this) has yet
to be discussed much at all (as far as I know).

I just wanted to propose this as the "ideal world".  In the "ideal world",
UM is clearly the right standard.  I worry that CORS, if standardized, would
encourage developers to go down the path of hard-coding which sites they
talk to, since that's the approach that CORS makes easy and UM does not.  In
the long run, I think this would be bad for the web, since it would mean
less interoperability between apps and more vendor lock-in.

That said, I think it's safe to say that if you *want* to hard-code the list
of sites that you can interoperate with, it's easier to do with CORS than
with UM.

On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close <tyler.close@gmail.com> wrote:

> On Mon, Dec 14, 2009 at 11:35 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> >
> > On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:
> >
> >> On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth <w3c@adambarth.com> wrote:
> >>>
> >>> On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees <
> jar@creativecommons.org>
> >>> wrote:
> >>>>
> >>>> The only complaint I know of regarding UM is that it is so complicated
> >>>> to use in practice that it will not be as enabling as CORS
> >>>
> >>> Actually, Tyler's UM protocol requires the user to confirm message 5
> >>> to prevent a CSRF attack.  Maciej's CORS version of the protocol
> >>> requires no such user confirmation.  I think it's safe to say that
> >>> asking the user to confirm security-critical operations is not a good
> >>> approach.
> >>
> >> For Ian Hickson's challenge problem, I came up with a design that does
> >> not require any confirmation, or any other user interaction. See:
> >>
> >> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1232.html
> >>
> >> That same design can be used to solve Maciej's challenge problem.
> >
> > I see three ways it wouldn't satisfy the requirements given for my CORS
> > example:
> >
> > 1) Fails "AJAX UI" requirement in the grant phase, since a form post is
> > required.
>
> I thought "AJAX UI" just meant no full page reload. The grant phase
> could be done in an <iframe>.
>
> > 2) The permission grant is intiated and entirely drive by Site B (the
> > service consumer). Thus Site A (the service provider in this case) has no
> > way to know that the request to grant access is a genuine grant from the
> > user.
> >
> > 3) When Site A receives the request from Site B, there is no indication
> of
> > what site initiated the communication (unless the request from B is
> expected
> > to come with an Origin header). How does it even know it's supposed to
> > redirect to B? Is site A expecting that it's only going to get service
> > requests from B? That would amount to a prior bilateral arrangement.
>
> Ian's challenge scenario did involve a prior bilateral arrangement. I
> forgot that yours instead asked for the user's permission and so is a
> semantically different challenge problem.
>
> We could adapt the solution to Ian's problem to fit yours. We precede
> the solution to Ian's challenge with a step almost exactly like the
> first step of your own solution to your challenge problem. In
> particular,
>
> User Consent Phase:
> 1) On a page served by Server A, user picks Site B as having
> permission to add calendar events.
> 2) Server A records this grant in the user's account. In particular,
> the user account could store the relation (<https://B>,
> <https://A/user123?s=secretkey>).
>
> Now, when Site B sends its request for the user's unguessable feed
> URL, Site A can check the user account to see if the user consents. In
> particular:
>
> Grant Phase:
> 1. User logs into Site B.
>
> 2. Site B generates an unguessable token (to be used for CSRF
> protection on a subsequent request) and associates it with the user
> account.
>
> 3. A page from Site B sends a request with the token to Site A, using
> a URL like <https://A/getfeed?for=B&csrf=asdf>. The "csrf" query
> string parameter holds the unguessable token generated in step 2. The
> "for" query string holds the URL <https://B>.
>
> 4. Site A receives a request containing the user's login cookies, and
> the query string parameters. Using the "for" argument, Site A looks up
> the unguessable URL for the user's feed, generated in step 2 of the
> User Consent Phase. If there is none, a 404 is returned. If a match is
> found, Site A responds with a 303 back to Site B that contains the
> feed URL and the csrf token, such as
> <https://B/gotfeed?csrf=asdf&feed=xxx>. The "feed" query string
> parameter holds the unguessable URL for the user's feed.
>
> 5. Site B receives a request containing the user's login cookies,
> the csrf token and the feed URL. Site B does a lookup for the expected
> csrf token in the user's account. If the csrf token is not the
> expected one, Site B stops processing the request. Site B discards the
> csrf token. Site B stores the feed URL in the user's account. Site B
> responds with the normal, post-login user home page.
>
> Exercise Phase:
> 1. A page from Site B gets the user feed URL from the user's account
> and uses a UniformRequest (XHR-like protocol for uniform requests) to
> do a GET request.
>
> 2. Site A receives a GET request on a feed URL, looks up the
> corresponding feed data and returns it, along with the same-origin
> opt-out header.
>
> > I also note that the protocol you describe there uses cookies (and
> possibly
> > origins, if point 3 is addressed) to bootstrap a shared-secret based
> scheme.
>
> Were I allowed some freedom in the user interface, I could solve all
> these challenge problems without resort to cookies. For example, the
> User Consent Phase and Grant Phase above could be replaced by a single
> copy-paste operation by the user. But in these challenges, I've been
> prohibited from using copy-paste. (As a side node, with some changes
> to the browser implementation, I could also solve these challenges
> using a single-click user gesture, instead of copy-paste.)
>
> > As I've mentioned before, CORS would be a useful tool for that type of
> > technique. It can allow such bootstrapping without having to jump through
> > hoops with form posts, without disrupting the user's interaction with a
> full
> > page load, and without necessarily having to put secrets in the URL
> (since
> > the URL part of the request is by far the most likely to leak to the
> outside
> > world inadvertantly.
>
> With no secrets in the URL, the solution would also be vulnerable to
> CSRF-like attacks. Keep in mind that the solutions I have been
> proposing provide greater security under an identical user interface.
> That costs me some implementation complexity (the hoops you refer to).
> Again, that complexity goes away if I can have some user interface
> flexibility.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
>