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

On 24/09/15 21:50, Harry Halpin wrote:
> Note that use of OAuth does *not* violate SOP because it asks for and
> gets permissions, and the data transfer is done server-to-server.
> Client-based sending of personal data has real difficulty in a
> multi-device world due to issues of syncing and devices being offline.
> However, you can *do* data transfer server-to-server with digital
> signatures and anonymizing property. But building from these kind of
> OAuth data-flows is probably the way to go, where key material can be
> dynamically bound to the session (ala TLS Token Binding) so avoiding
> "one key per user" designs. This slide-deck is a good overview [3].


Maybe this outlines one the problems I'd like to see avoidable as a
required piece of the "web identity" puzzle, if possible: dependence on
central, *on-line* identity providers (what server-to-server
communication depends on). That's a SPOF that has amplification
capability which is not desirable.

Maybe it makes sense to talk about the technical building blocks rather
than a identity solution and provide machinery to build things that
don't screw up the basic constraints "the web" and user agents should
possess and agree upon those constraints. And see if everyone can build
their systems on top of these blocks.

In fact, I don't know why the talk always drifts towards identity. Maybe
identity magnifies the fundamental problem of SOP and non-SOP approach,
but the problem, as Anders has already said, is not unique to identity
but also payments (which I don't know much about, to admit).

As "conspiracy theory" as it sounds there is still in my opinion a
fundamental difference between two camps, the US and EU: one where a
customer database is an asset vs the other where it is a liability. And
mistrust towards different things, eg. there's no "post-Snowden era"
surprise panic among the older population where I come from, because...
history.

Maybe the "require SOP and only SOP, for privacy and security" is
comparable with the "burqa ban" dilemma in some European countries: the
choice should not be to forbid wearing one as option A nor enforcing
everyone to wear one as option B.

But this is exactly what the SOP requirement and super-cookie paranoia
seems to compare to: thinking that one option is "better for everybody,
because ... history and fears and stuff"

I'm not vouching for being forced to choose between option A or option B
with the burqa ban nor in the web space. I believe that "the Web" (and
user-agents) should let the *user choose* what they want. And the Web
should accommodate both.

What I want to say is that whatever the "web platform" will look like
after coming out of W3C or from major browser vendors implementations,
solutions that work for the other camp *will* be implemented. But most
probably with reduced usability and worse security or privacy
properties, if the platform does not facilitate building such things.

And please be confident that it is about clear and articulated user
choice and permissions.

Martin
-- 
Cybersec R&D
www.RIA.ee
+372 515 6495

Received on Thursday, 24 September 2015 20:41:53 UTC