W3C home > Mailing lists > Public > public-web-security@w3.org > September 2015

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

From: <henry.story@bblfish.net>
Date: Wed, 23 Sep 2015 15:30:59 +0100
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Alex Russell <slightlyoff@google.com>, public-web-security@w3.org, Tony Arcieri <bascule@gmail.com>, Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Rigo Wenning <rigo@w3.org>
Message-Id: <24F338C5-BCAC-490F-8BD3-96471BD30490@bblfish.net>
To: Halpin Harry <hhalpin@w3.org>

> On 23 Sep 2015, at 14:57, Harry Halpin <hhalpin@w3.org> wrote:
> On 09/23/2015 03:42 AM, Anders Rundgren wrote:
>> In my opinion the #1 problem with this discussion is that when you
>> mention
>> things that doesn't match the SOP vision like the fact that Android-,
>> Apple-,
>> and Samsung-Pay doesn't work on the Web, dead silence is all you get.
> Since the same origin policy is the primary meaningful security boundary
> on the Web, I expect for most people interested in security and privacy
> that emails that dismiss SOP are generally put in the spam folder.

Dismissing SOP out of hand would indeed be foolish. What this discussion 
is about is how SOP actually relates to security, privacy, linkability 
and user control. Perhaps we can make the following intial distinctions:

- SOP is  a technical concept at the layer of information flow
- privacy is a  concept that is in the political space
- linkability is a key logical concept, and central to the web
- use control is in the ethical and technical space ( control requires
  the ability of a human agent to transform decisions into actions easily )

I am sure we could with a few iterations get to some consensus along 
these lines. 

> I do understand some people are interested in creating, for example,
> 'unique identifier' across all websites such as in the form of a X.509
> certificate.

A URI is a global identifier, a public key is a mathematical construct, which
indirectly identifies an agent. 

FIDO enables global identifiers to be used as you can see in their web architectural
document here:


> These sort of  totalitarian identity scheme (often based on
> broken crypto, such as <keygen>) will likely implemented across all
> browsers, as would any payment scheme that makes the same broken
> assumptions.

So FIDO is helping totalitarian schemes?

In a previous e-mail we have shown that WebCrypto allows JS from one origin
to create keys with which it can sign documents sent to other origins. There
is not really any way that webcrypto can stop this.  A simplistic application
of SOP would mean that WebCrypto presents a security hole. Can you help
us find a principled way of coming to understand how SOP, privacy, use control
and linkability are related?

> Supporters of such positions seem to have a lack of
> understanding of the modern Web and/or basic cryptography and while to
> some extent basic education can be done on Web-related mailing lists, I
> doubt many people find it is a productive use of their time given the
> large amount of high quality online courses out there and relatively
> important work that has to be done in terms of Web standards.

This type of dismissal of people trying to engage in a conversation
is not conductive to coming to an understanding of the complexities 
involved. It is not the kind of attitude that suits someone whose
role at the W3C is to engage people into a process of consensus.

> In particular, it is likely more productive for various non-SOP schemes
> to find a way to adopt to SOP in a principled manner and so maintain
> security and privacy properties. Payment schemes, identity schemes, and
> the rest should and can do this.

Yes, but things are not so easy. Do we remove WebCrypto because it does not
fit SOP? Or does it actually fit SOP? Is there a document where these issues
have been written up that we can refer to? For the moment it seems to me
the discussion is actually quite confused. 


>            cheers,
>              harry
>> -- Anders

Social Web Architect
Received on Wednesday, 23 September 2015 14:31:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:38 UTC