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

On 24 September 2015 at 12:08, GALINDO Virginie <
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.
>

+1 dont feed the troll

I believe the TAG also discussed this issue at the recent F2F and will
publish something on the topic.  I think that will be a great input too, as
this is a scoping problem which applies at both an architecture level, as
well as security.


>
> Thank you.
>
> Virginie
> Chair of the Web Security IG
>
> -----Original Message-----
> From: 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;
> 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> 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.
>
>