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

On Sun, Aug 30, 2015 at 9:57 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> For security-related applications of the kind I mentioned (e.g. payments),
> the desktop Web haven't progressed much.
>

I'm a fan of what Stripe has done in this space, and I say this as someone
who works at a monosyllabic five-letter San Francisco payments company that
starts with "S" and ends with "e" which isn't Stripe. While I can't speak
for them, I will definitely cite them as a successful counterexample of
what you seem to be claiming doesn't work.


> Even on the desktop, "Apps" have (through rather clumsy OOB-arrangements),
> essentially been the only improvement that have gotten any traction worth
> mentioning.  SOP-crippled solutions like WebCrypto doesn't really cut it.
>

The reality of the cryptographic technologies WebCrypto hoped to unlock
in-browser is they're rarely used, and only for point-solutions, and when I
say that, I'm talking about outside the browser. In-browser usage of these
technologies is practically nonexistent, or for the handful of people who
attempt to use these technologies they're too half-baked and ill-conceived
to be either usable or secure.


> The W3C WebCrypto.Next effort targeting smart cards etc. was shelved.
> AFAICT, they among many things ran into the SOP roadblock (restricting a
> card/key to a domain).
>

I was a meatspace attendee of the "W3C Workshop on Authentication, Hardware
Tokens and Beyond" and my personal opinion is the problems are much deeper
than SOP. In fact, I think your argument here is more of a non-sequitur as
it was in your original email. There are many problems involved in adopting
such technologies which are not relevant to web payments. For example,
Firefox does not have a USB stack it can use to leverage the CCID interface
to access PKCS#11/PIV hardware tokens. This is not relevant to purely
software EMV payment tokens. I say this as an enthusiastic user of both
PKCS#11 HSMs and hardware tokens (which is why I attended the workshop in
the first place). EMV is well-positioned to provide purely software
payments. And lest we go down a point-solution rabbit hole with that
argument, I think Bitcoin is too (I say this as a half-hearted Bitcoin fan).

On mobile, I think there has been a lot of progress exposing features which
cross-cut SOP in mobile browsers. Many of the capabilities of mobile phones
are exposed to web browers in a cross-platform manner. WebCrypto's problem
was trying to put a standard API on an incredibly diverse set of hardware
tokens with variadic capabilities, where the underlying browser support for
these capabilities was nonexistent.

Workarounds are imaginable but then you get hit by the permission-monster:
> http://webpki.org/papers/permissions.pdf
>

Some constraints could be incredibly liberating here, I think. Fortunately,
if we look at something like the EMV payment workflow in the abstract (I
don't want or expect the W3C to standardize EMV as a point solution and
would in fact consider that bad), I think browser-based payment tokens
could be incredibly effective and have both an abstract and easy-to-use
workflow.

Anyway, a long-winded email aside, in my opinion the Same Origin Policy is
not the problem here. The devil is in the details. I expect understanding
and overcoming the obstacles these details present will be critical to the
success (or non-success) of the Web Payments API. I do not in any way shape
or form feel like deviating from SOP will help solve any of these problems.
I feel like the Web Payments API is a very "ambitious" standard and if it
tries to deviate from SOP it may already be DOA.

Anyway, all that said as someone working in the browser-based payments
space I don't think you've made any compelling arguments against the Same
Origin Policy, and I am strongly in favor of retaining it as the
foundational security principle of the Web. I do not think there's anything
unique or compelling about payments that requires abandoning it, on the
contrary as a potential Web Payments API consumer it's something I would
like to leverage.

-- 
Tony Arcieri