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

> On 15 Sep 2015, at 21:14, Tony Arcieri <bascule@gmail.com> wrote:
> 
> On Mon, Sep 14, 2015 at 10:08 AM, Rigo Wenning <rigo@w3.org <mailto:rigo@w3.org>> wrote:
> The same argumentation has already be used during the rechartering of the WebCrypto Group. The privacy argument used by people from one of the largest origins is funny at best. If I use my token with A and I use my token with B, A and B have to communicate to find out that I used them both.
> 
> Speaking as someone who attended WebCrypto Next Steps, the common theme to me was actually a fundamental incompatibility between PKCS#11 APIs and how web browsers operate. Many talks alluded to some sort of "bridge" or "gateway" or "missing puzzle piece" to connect the Web to PKCS#11 hardware tokens. Unfortunately there were no concrete proposals from either a technical or UX perspective. It was mostly a dream from all of the vendors, realized in slightly different vague handwavy visions, of how someone could swoop in and magically solve this problem for everyone. Clearly dreams without actual technical proposals didn't go anywhere.
> 
> The reality is the SOP is the foundational security principle of the web. Period. Introducing SOP violations is a great way to ensure browser vendors don't adopt proposals.

SOP is a technical Principle, which is trumped by the legal principle of User Control. I made this point in the thread to the TAG
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0038.html <https://lists.w3.org/Archives/Public/www-tag/2015Sep/0038.html>
and it fits the TAG finding on Unsactioned Tracking
http://www.w3.org/2001/tag/doc/unsanctioned-tracking/

Current browsers respect user control with regard to certificates - some better than others. It can be improved, but that can best be done through legal and political pressure.

If the user is asked if she wants to authenticate with a global ID to a web site, then that is her prerogative.
As long as she can select the identity she wishes to use, and change identity when she wants to, or become anonymous: she must be in control. 

Privacy is actually improved in distributed yet connected services. By having distributed co-operating organisation each in control of their information, each can retain their autonomy. As an example it should be quite obvious the the police cannot share their files with those of the major social networks, nor would those have time to build the tools for the health industry, nor would those work for universities, etc. etc... The world is a sea of independent agencies that need to look after their own data, and share it with others when needed. In order to share the data, they need to give other agents access, they need to *control* access, which means you need some form of global identities that can be as weak as temporary pseudonyms, or stronger. In fact they can evolve out of pseudonyms into strong identifiers on which a reputation has built itself.

Of course anonymous or one site identities should be the basis of that and FIDO provides that, but not more.
On top of FIDO you can see OpenID, SAML and OAuth profiling themselves very clearly in the FIDO UAF Architectural Overview:

https://fidoalliance.org/wp-content/uploads/html/fido-uaf-overview-v1.0-ps-20141208.html#relationship-to-other-technologies <https://fidoalliance.org/wp-content/uploads/html/fido-uaf-overview-v1.0-ps-20141208.html#relationship-to-other-technologies>

These global identities based on URIs won't go away in a Web that is a web of billions of organisations, individuals and things, connected and interconnected. 

> 
> Going back to your original point though, what you're describing is of course extremely commonplace on the web. Web sites often leverage multiple advertising and analytics networks, so "A and B communicating" (perhaps vicariously via ad or analytic network C) is so exceedingly commonplace I'm not sure what you're even suggesting. This already happens practically everywhere all the time, to many commonly shared third parties who very much want stable identifiers to link users.
> 
> There are of course ample other signals by which ad and analytics networks can track people with (IP addresses and "supercookies" certainly come to mind), but by brushing it off, you're actually suggesting that cryptographic traceability should be built into the fundamental cryptographic architecture of the Web. This is a slippery slope argument, i.e. things are bad, so why not make them worse?
> 
> There's no going back from that, short of throwing it all away (as what is likely to happen to the <keygen> tag soon) and starting over from scratch (ala FIDO).

Here is the picture from the architectural UAF document mentioned above. (It fails to mention that in many cases after an OAuth or OpenID the Relying Party communicates with the Federation Party until recently called the identity provider.)  So really FIDO is just setting a super strong cookie with some cryptographic properties which then more and more often needs to be bolted onto actual Identity Providers. All of this relies on server side cryptographic keys tied to TLS, so that the major parties are in effect using certificates for global authentication.



( 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 <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 <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 <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, 
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/ <http://www.w3.org/2005/Incubator/webid/spec/>
[2] http://www.html5rocks.com/en/tutorials/service-worker/introduction/ <http://www.html5rocks.com/en/tutorials/service-worker/introduction/>
[3] https://lists.w3.org/Archives/Public/www-tag/2015Sep/0051.html <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
 Also note that Japan is moving to eID
    http://www.securitydocumentworld.com/article-details/i/12298/
 that sweden has a huge number of people there, and that it might not be too good to get noticed by
states: Russia and the EU just  this month started anti trust investigations  against Google for example.
   
> 
> -- 
> Tony Arcieri