- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 4 Feb 2015 17:21:13 +1100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I can't think of any application of CSP or CORS in this context. We already have consent mechanisms equivalent to CORS in the form of ICE. And CSP serves only as a voluntary reduction in capabilities on the part of a site. On 4 February 2015 at 16:45, Harald Alvestrand <harald@alvestrand.no> wrote: > Limiting to Webrtc and changing subject.... > > On 02/03/2015 09:41 PM, Göran Eriksson AP wrote: >> Inline >> >>> >>> 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the >>> API as long as the other side needs to try to send packets to these interfaces. >>> We can't obfuscate them or encrypt them because they have to be >>> communicated to the other party, through channels that aren't in the >>> WebRTC spec. >> [GAPE:] OK, sure, that would fit in IETF. But CSP/CORS are within the W3C scope, right? For instance, consider using Web platform mechanisms such as CSP; that should be in the scope of the W3C draft, right? Something along the lines Web site admin using CSP/CORS to have the UA 'check' the 'find&connect' proxy origin (especially when it is not in the same 'origin' as that of the parent document)? > > Can you explain in more detail what you mean here - what exactly are you > suggesting be checked with CSP/CORS? > > As far as I understand, if the "attack" is like the "you have this IP > address" Web pages we've seen, all the resources that the page needs > access to are either wide open or under the control of the "attacker" - > and the user has already performed the "engagement gesture" - he clicked > on the link to the page. > > CSP/CORS is, I believe, intended to make sure a page doesn't reach out > to resources outside what it is supposed to have access to - but in the > "you have this IP address" page, all the resources it needs access to > are (potentially) controlled by the page's author - so even if we had > protocol details to verify access, what is it that we would be using > CSP/CORS to check against? > > If there are mechanisms that are relevant, I think I need some more > explanation before I get what they are. > > > > >
Received on Wednesday, 4 February 2015 06:21:44 UTC