W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

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

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 29 Aug 2015 13:53:56 +0200
To: Mike O'Neill <michael.oneill@baycloud.com>, public-web-security@w3.org, public-webappsec@w3.org
Message-ID: <55E19D54.4010603@gmail.com>
On 2015-08-29 13:23, Mike O'Neill wrote:
> Yes, a single legal entity (like a company) can control several origins,
  > and a single origin can be controlled by many entities (via subdomains).
  > The SOP needs to be re-enforced by a Single Entity Policy, i.e. by secure
  > declaration of what legal entity manages a subdomain or domain (or set of them)

I must confess that I don't understand how such a scheme could serve average Web users.

Anyway, this proposal seems orthogonal to what I'm talking about.

-- Anders

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
> Sent: 29 August 2015 09:21
> To: public-web-security@w3.org; public-webappsec@w3.org
> Subject: A Somewhat Critical View of SOP (Same Origin Policy)
> A core part of the Web Security model is based on SOP.
> However, the world (outside of the Web) isn't working according this model; it is rather ad-hoc.
> This has lead to the "App-explosion" which is better aligned (for good or for worse) to needs of the world than a SOP-crippled Web.
> Since SOP (if taken literally) would more or less kill the Web, the "Super-Providers" have come to rescue.  That is, browsers still adhere to SOP but this is effectively short-circuited by services like PayPal which enable payments to any domain.
> This is where it (IMO) gets wrong.  If Super-Providers are trusted for mediating access to arbitrary domains, why couldn't [properly designed] applications also perform this task?
> In addition, payments and authentication (to take an example), typically exhibit quite different privacy- and security-characteristics making the SOP-hammer a pretty blunt tool.
> -- Anders
Received on Saturday, 29 August 2015 11:54:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC