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

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

From: Jeffrey Walton <noloader@gmail.com>
Date: Thu, 17 Sep 2015 23:09:44 -0400
Message-ID: <CAH8yC8m07V_8H9Qzx+wWBU89_dUdBRoxGnWgN8=DXqSoYOrpjA@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: public-web-security@w3.org, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Sep 17, 2015 at 9:56 PM, Alex Russell <slightlyoff@google.com> wrote:
> I'm not sure I'm the right party to try to summarize, but here's what I
> think are the roots of various discussion points that have been raised:
>
> Some browsers have an allergy to PKCS#11, largely down to the API not
> working well with the now-pervasive multi-process model

Ah, that's been going on for years. Kudos to Brad for actually talking
about it :)

I think the idea or strategy is to support it so poorly it can be
killed off without much fuss. You see, mutual auth provides (among
other things) channel binding, and that conflicts with the browser's
"interception is a valid use case".

> The system keystore lives (conceptually) outside the Same Origin Model. This
> raises questions about how schemes (like TLS authentication) that use it can
> scope the effect of their actions
> Some people find these side-effects to be beneficial in cases they care
> about

One quick comment here...

We've evaluated a lot of proposed systems, and some of them are web
based apps. The organization classifies their data, and then selects
security controls commensurate with the data sensitivity level.

The organization's policies and procedures also requires something
like the following for mobile devices:

    LOW value data - ranges from "who cares" to encrypt,
             persist key in secure storage
    MED value data - encrypt, store salt in secure storage,
             prompt user for entropy, can't persist user entropy,
             OK to cache user entropy for fixed amount of time,
             can't persist login credentials (i.e., Auto-logins).
    HIGH value data - ranges from "you can't store it, period"
             for online apps to "send app over to risk acceptance" for
             offline apps because we don't have the controls we need.
             For example, if it was a laptop, we might be able to use
             FDE, a password and a token generator.

Web based apps usually fall short because they don't have secure
storage, like Isolated or Protected Storage or a KeyChain. I don't
ever recall a time when SOP's intersection with secure storage was
ever a factor.

Jeff
Received on Friday, 18 September 2015 03:10:14 UTC

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