Re: A Somewhat Critical View of SOP (Same Origin Policy)

> On 15 Sep 2015, at 22:48, Alex Russell <slightlyoff@google.com> wrote:
> 
> 
> On 15 Sep 2015 5:29 pm, "Henry Story" <henry.story@co-operating.systems> wrote:
> >[snip]
> >
> > ( They could have also have added WebID to the mix http://webid.info/ 
> > but that is anoyingly simple, which is why I like it :-)
> >
> > Now WebID is not tied logically to TLS [1]. We have some interesting
> > prototypes that show how WebID could work with pure HTTP.
> >   • Andrei Sambra's first sketch with 
> >       https://github.com/solid/solid-spec#webid-rsa
> >   • Manu Sporny's more fully fleshed out HTTP Message signature
> >       https://tools.ietf.org/html/draft-cavage-http-signatures-04
> > these two could be improved and merged.
> >
> > This would allow a move to use strong identity in  HTTP/2.0 ( SPDY ) ,
> which could then be supported by the browsers who could build User
> Interfaces that give the users control of their identity with user
> interfaces described by your Credentials Management document developed here
> >   https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection
> >
> > Funnily enough one should already be able to try Andrei or Manu's
> protocol in the Browser with JS, WebCrypto, and ServiceWorkers [2].
> There are many things to explore here [3] and the technology is still
> very new. [4]
> >
> > But this shows that WebCrypto actually allows one to do authentication
> > across origins. ( And how could it not, since it is a set of  low
> > level crypto primitives? ). A Single Page application from one site
> > can publish a public key and authenticate to any other site with that key. 
> >
> > So its a bit weird that SOP is invoked to remove functionality that
> > puts the user in control in the browser, 
> 
> This assessment is patently false. What's being proposed for removal
> is silent, automatic installation of keys without user consent. To
> treat that as removal of user control is perverse bordering on prevarication.

We have 5 years of experience using keygen, and that is our experience of it
on all the browsers for certificate creation and selection.

A certificate creation

The <keygen> is an html element that is placed in a form and adds
a menu item allowing the user to choose key strenght. The user has
to 
  1) click the form in order for the browser's keystore to create
   a public/private key pair, and send the public key with the rest
   of the form elements to the server. Here the user is in control.
  2) when the server receives the public key it can create a certificate
   and send that back to the browser with the mime type application/x-x509-user-cert
   as you can see in the code here
     https://github.com/read-write-web/rww-play/blob/dev/app/controllers/ClientCertificateApp.scala#L236
   3) the user agent on receiving that certificate checks that the public 
  key of the certificate has a corresponding private key in its keystore. 
  If it has it can ask the user to add it to the keystore. Firefox did that. 
  Chrome just alerts the user. If Chrome whishes to give the user more choice 
  it could do the same too.

  The user chooses to submit the form, and the user can UI depending, choose
to add it. Where is the user not put in control?

B. Certificate selection

   When a site asks the user for a certificte using TLS's simple mechanism
for that, the browser pops up a certificate selection box to do this. The
user can choose to select one or not to send any. ( Not all browsers are as
good at this as Chrome or IE is, but I don't want to name names here )
Where is the user not in control?
  
  This is not unlike Basic Auth. And it is not unlike what is proposed
in the credential management document
  https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection

I don't see how it can be provocative to point out the facts here.

> 
> > and that WebCrypto is then touted simultaneously as the answer,
> > when in fact WebCrypto allows Single Page Applications (SPA) to do
> > authenticate across Origins, and do what the browser will no longer
> > be able to do.
> > Lets make sure the browser can also have an identity. It's an
> > application after all!
> >
> > Let's stop using SOP as a way to shut down intelligent conversation.
> > Let's think about user control as the aim.
> >
> > Henry
> >
> >
> > [1] as it may seem from the TLS-spec which we developed first because it actually worked.
> > http://www.w3.org/2005/Incubator/webid/spec/
> > [2] http://www.html5rocks.com/en/tutorials/service-worker/introduction/
> > [3] https://lists.w3.org/Archives/Public/www-tag/2015Sep/0051.html
> > [4] which is why it is wrong to remove 15 year old <keygen> technology on which a lot of people depend 
> > around the world as explained so well by Dirk Willem Van Gulik on the blink thread before a
> > successor is actually verified to be working. 
> >  See Dirk's messages here:
> >     https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/GnxmmtxSAgAJ 
> >     https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/4kKNMVCdAgAJ

Received on Tuesday, 15 September 2015 22:19:40 UTC