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

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

From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 15 Sep 2015 13:14:49 -0700
Message-ID: <CAHOTMV+abrYdAtipYvawEBiswY-gV8pUjeQTjZjG1aottG1eew@mail.gmail.com>
To: Rigo Wenning <rigo@w3.org>
Cc: Henry Story <henry.story@co-operating.systems>, "public-web-security@w3.org" <public-web-security@w3.org>, "Mike O'Neill" <michael.oneill@baycloud.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, public-webappsec@w3.org
On Mon, Sep 14, 2015 at 10:08 AM, Rigo Wenning <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.

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).

-- 
Tony Arcieri
Received on Tuesday, 15 September 2015 20:15:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC