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.
* 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.gali...@gemalto.com <mailto:virginie.gali...@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.st...@bblfish.net <mailto:henry.st...@bblfish.net> [mailto:henry.st...@bblfish.net <mailto:henry.st...@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-webapp...@w3.org <mailto:public-webapp...@w3.org> Subject: Re: A Somewhat Critical View of SOP (Same Origin Policy) > On 24 Sep 2015, at 06:07, Harry Halpin <hhal...@w3.org <mailto:hhal...@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.
