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

On 2015-09-01 04:54, Tony Arcieri wrote:
> On Sun, Aug 30, 2015 at 9:57 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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.

Yes, this is what I hear here all the time.  A payment startup somewhere has a fantastic solution.  Unfortunately it is not documented in such a way that anybody else can verify the claims.


>     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,

The is a US-centric view.  In the US 0.5% of all POS-transactions use chip-card technology.  In France it is more like 80%.

In Sweden half of the population have a PKI-based eID (electronic ID) used for authenticating and signing on the Web.
It (of course) builds on an "App" + OOB since the Web can't do this (after the plugins were deprecated).


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

Although I agree that there are tons of issues with hardware tokens w.r.t. middleware, it was actually the violation of SOP in the Gemalto and Microsoft proposals that caused the activity to wind-down.


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

Since neither You nor Google/Microsoft/Apple/Mozilla/Whatever haven't told us anything on how *they* think that any number of unrelated merchants should/could get access to a client's payment resources on Web, we are apparently awaiting "Divine Intervention" :-)

Anders


>
> -- 
> Tony Arcieri

Received on Tuesday, 1 September 2015 04:53:22 UTC