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

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

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 28 Sep 2015 11:20:47 -0700
Message-ID: <CANr5HFWStvvSnfzz5A8WHUPwmXJXBgv0eYBPkMHw3weo_WM-_Q@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>, "public-web-security@w3.org" <public-web-security@w3.org>
On Sat, Sep 26, 2015 at 11:43 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2015-09-25 23:46, Alex Russell wrote:
>
>> My apologies to nearly everyone for continuing this thread, but
>>
> > the document linked here contains a litany of factual and interpretation
> errors.
>
> Since I wrote the first two I guess I should try to clarify...
>
>
>> Breifly, it postulates:
>>
>> * "Native Messaging
>> https://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html
>>
> > somehow breaks the SOP. Browser extensions conceptually live outside the
> SOP already.
> > "Native Messaging" enabling one thing that's outside SOP (extensions) to
> talk to other
> > things outside SOP (OS programs) is a no-op.
>
> No-op = Redundant information?
>
> Anyway, Native Messaging extensions does not have to break SOP, it is
> rather
> one of the (numerous) limitations in Google's take on the matter which
> doesn't
> provide Native Messaging extensions with the calling page's security
> context.
>

Extension APIs are, by definition, outside SOP; not only do they break SOP
they exist primarily to subvert it (e.g., content scripts).

This is basic stuff. It's hard to have a conversation about such a
complicated area without shared understanding of the basics.

  * That it SOP doesn't apply to payments. Recent proposals
>>
> > http://discourse.wicg.io/t/rfc-proposal-for-new-web-payments-api/1100
> > attempt to ensure that SOP is enforced through the browser by making the
> > payment mechanisms a browser-mediated conversation, allowing
> interposition
> > of user consent to information sharing.
>
> Either this proposal does something "magical" which I couldn't find in the
> proposal or it simply (with the browser's help) enable the user to accept
> or reject requests from arbitrary domains including remembering choices
> etc.
> In the WebCrypto list this was sometimes referred to as "SOP exception".
>
> Regards,
> Anders
>
>
>
>   * That client certificates are somehow "safe" because they can invoke UI
>> for users. This isn't always the case for non-browser consumers of the
>> global keystore in some OSes. Further, it misinterprets the FIDO threat and
>> provisioning model.
>>   * The section on WebCrypto is simply nonsensical. I literally don't
>> know which error to tackle first.
>>
>>
>> It would save the authors/contributors considerable embarrassment if it
>> were edited down to solid facts.
>>
>> Regards
>>
>> On Thu, Sep 24, 2015 at 3:08 AM, GALINDO Virginie <
>> Virginie.Galindo@gemalto.com <mailto:Virginie.Galindo@gemalto.com>>
>> wrote:
>>
>>     Henry,
>>
>>     I rely on your constructive sense of communication to feed the wiki
>> page I have indicated here
>> https://www.w3.org/Security/wiki/IG/a_view_on_SOP and stop arguing
>> against particular email in this thread.
>>
>>     If we have a problem, lets *document* it.
>>
>>     Thank you.
>>
>>     Virginie
>>     Chair of the Web Security IG
>>
>>     -----Original Message-----
>>     From: henry.story@bblfish.net <mailto:henry.story@bblfish.net>
>> [mailto:henry.story@bblfish.net <mailto:henry.story@bblfish.net>]
>>     Sent: jeudi 24 septembre 2015 12:01
>>     To: Halpin Harry
>>     Cc: Dave Longley Longley; public-web-security@w3.org <mailto:
>> public-web-security@w3.org>; public-webappsec@w3.org <mailto:
>> public-webappsec@w3.org>
>>     Subject: Re: A Somewhat Critical View of SOP (Same Origin Policy)
>>
>>
>>      > On 24 Sep 2015, at 06:07, Harry Halpin <hhalpin@w3.org <mailto:
>> hhalpin@w3.org>> wrote:
>>      >
>>      > On 09/23/2015 11:56 PM, Dave Longley wrote:
>>      >> As this has degenerated into what I consider flaming, I've removed
>>      >> others from the CC list and I don't plan on responding further.
>>      >>
>>      >> On 09/23/2015 09:12 PM, Harry Halpin wrote:
>>      >>> TL;DR
>>      >>>
>>      >>> As its pretty clear we're just rehashing known problems with
>>      >>> violating same origin policy and basic crypto key management
>> issues,
>>      >>> I will now turn my spam filter back on :)
>>      >> I do agree we're getting no where, but for different reasons.
>>      >> Accusing someone of positions they don't hold and then telling
>> them
>>      >> any response will be considered spam isn't a discussion. No wonder
>>      >> the motivations of others are unclear to you.
>>      >
>>      > I apologize if I've misconstrued your position from specs you've
>>      > written, code you've written, or blog posts. If your views, or
>> Manu's,
>>      > have changed then you should simply update your specs and write new
>>      > blog posts.
>>      >
>>      > However, I see relatively recent posts like this:
>>      >
>>      > http://manu.sporny.org/2015/credentials-retrospective/
>>      >
>>      > In which it is noted that WebID+TLS is given higher 'ratings' than
>>      > OAuth 2.0, and it is incorrectly notes that OAuth 2.0 is not used
>> with
>>      > digital signatures or used for the transfer of verified
>> credentials,
>>      > when it is used by almost all major sites. There are probably ways
>> to
>>      > simplify the flow (as shown Eran's Oz) and all sorts of privacy
>> improvements.
>>
>>     Good find. Nice article :-)
>>
>>     There is a big sign at the top of the blog saying "DRAFT DRAFT ... ",
>> so I suppose Manu will appreciate your feedback.
>>
>>     Note that I also have an issue to it, so I'll BCC Manu.
>>     In the WebID-TLS section Manu writes that it "depends on the KEYGEN
>> HTML element in a non-trivial way". This is a misunderstanding.
>>     <keygen> is important because it makes it possible to create
>>     $0.00 certificates in a way that enables the user to be in control,
>> and can runs in current browser.
>>
>>     The issue with WebCrypto's manner of making a public/private key is
>> that the private key can be stored on the server ( bad practice ), and
>> there is no browser UI tie in at all at the moment, so the User can only be
>> in control in so far as he chooses an Origin.
>>
>>     The discussion here was to find for example a principled explanation
>> of why that is ok or not.
>>
>>      >
>>      > Thus, again, I recommend doing a good deal of background reading
>> and
>>      > understanding of the work the IETF and others have done in this
>> space
>>      > before re-inventing the wheel. The current work of the Credentials
>> CG
>>      > would not pass any kind of security or privacy review, and so I
>> don't
>>      > see why it or related work would justify getting rid of the Same
>>      > Origin Policy.
>>
>>     Harry you have a philosophy degree, not a degree in cryptography. So
>> I am not sure that you are in a position to judge here, and I am not sure
>> why you find it necessary to do so. Many others from different areas have
>> disagreed with your attempt to close down the conversation here.
>>     To name just a few:
>>
>>     - Dave Longley who has written the most level headed messages to
>> this  list requiring a zen like skills when replying to you, and who  has
>> experience actually implementing security protocols such as TLS [0]
>>     - Virginie Galando co-Chair of the Web Security mailing list [1]
>>     - Martin Paljak, Cybersec R&D of the estonian https://www.ria.ee/en/
>> [2]
>>     - Hadi Nahari, Chief Security Architect at NVidia [3]
>>     - Adrian Hope-Bailie Web Payments officer to Ripple Labs, is actually
>>        interested in the question of how SOP might affect web payments [5]
>>     - Anders Rundgreen who has worked on various possible improvements to
>>        keygen, and implemented a lot of the technologies you mention
>> including
>>        JOSE .
>>
>>     As pointed out by Brad Hill [6] this space is complicated and a lot
>> of efforts have failed. That means that there is a lot of invention still
>> to be made, and that will always of course start off by a few people coming
>> together to scratch and itch. OpenID did not have security reviews for a
>> long time, nor did OAuth.
>>
>>     But if we put all that aside, in the messages [7] I mentioned
>> draft-cavage-http-signatures [8] the point was not that that draft spec was
>> the be-all-end-all solution to everything, that it had security reviews,
>> etc... but rather that whatever you make of it it seems very likely that
>> WebCrypto can be used to implement it.
>>
>>     Now if you think that protocols like this are supercookies that leak
>> huge amount of information, that this is a catastrophe, as you seem to do
>> in your previous mail [9] then
>>
>>                WE HAVE A PROBLEM!!
>>
>>     Because WebCrypto is a W3C standard that is shipped in actual
>> browsers, and that has passed I suppose security reviews.
>>
>>     So what gives?  Do we stop thinking in stereotypes and do actual
>> conceptual analysis supported by working code, or should we throw the baby
>> out with the bath water and close down WebCrypto ?
>>
>>     Henry
>>
>>
>>     [0] https://www.npmjs.com/package/node-forge
>>     [1]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0051.html
>>     [2]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0050.html
>>     [3]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0054.html
>>     [4]
>> https://ripple.com/blog/welcome-web-payments-officer-adrian-hope-bailie-to-ripple-labs/
>>     [5]
>> https://ripple.com/blog/welcome-web-payments-officer-adrian-hope-bailie-to-ripple-labs/
>>     [6]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0059.html
>>     [7]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0061.html
>>     [8] https://tools.ietf.org/html/draft-cavage-http-signatures-04
>>     [9]
>> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0066.html
>>      >
>>      >         cheers,
>>      >
>>      >
>>      >
>>      >
>>      >>
>>      >>> However, action was necessitated as I have had complaints from
>>      >>> various members and non-members (including members of the Bitcoin
>>      >>> community) over excessive emails both on-list and off-list from
>>      >>> WebID+TLS Community Group members, Credentials Community Group,
>> and
>>      >>> Anders - and even harassment of W3C Team members via Skype and
>>      >>> Facebook asking for "support" of these specs. At least personally
>>      >>> I've had to block members of the WebID and Credentials CG on
>> popular
>>      >>> social media sites due to the level of spam and due to abuse
>> remove
>>      >>> one member from a Working Group. Strangely, this really seems
>>      >>> motivated by about a dozen people with emotional attachment to
>>      >>> certain specs, not a huge upsurge of grassroots support from
>>      >>> end-users.
>>      >> The implication that a member of the Credentials CG or the entire
>>      >> group is guilty, by association, of harassment is quite
>> unbecoming.
>>      >> Did they also have mustaches? As you know, W3C Community Groups
>> are
>>      >> freely open to all on the Internet.
>>      >>
>>      >>
>>      >
>>      >
>>      >
>>
>>     Social Web Architect
>>     http://bblfish.net/
>>
>>
>>     ________________________________
>>       This message and any attachments are intended solely for the
>> addressees and may contain confidential information. Any unauthorized use
>> or disclosure, either whole or partial, is prohibited.
>>     E-mails are susceptible to alteration. Our company shall not be
>> liable for the message if altered, changed or falsified. If you are not the
>> intended recipient of this message, please delete it and notify the sender.
>>     Although all reasonable efforts have been made to keep this
>> transmission free from viruses, the sender will not be liable for damages
>> caused by a transmitted virus.
>>
>>
>>
>
Received on Monday, 28 September 2015 18:21:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:38 UTC