- From: Alex Russell <slightlyoff@google.com>
- Date: Mon, 28 Sep 2015 11:20:47 -0700
- 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>
- Message-ID: <CANr5HFWStvvSnfzz5A8WHUPwmXJXBgv0eYBPkMHw3weo_WM-_Q@mail.gmail.com>
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