RE: CSP/CORS (Re: ICE exposes 'real' local IP to javascript)

> >> 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.
> > [GAPE:]
> > Just to make it clear- this is not [intended] as a discussion about the
> ICE/consent mechanism. This is as far as I understand it, another matter;
> which tools do the well-behaved web site owners have available to have a
> defense-in-depth in case the web app is compromised, e.g. by content
> injection or simply poorly written?
> >
> > This is separate from the VPN-case, also of concern.
> >
> Thanks for clarifying your intent with mentioning these tools!
> Do they belong in the spec, or do they belong in supporting material - "how
> to write a secure WebRTC application"?
> (it's natural for me to think that it belongs in supporting material, given that I
> want the spec finished....)
[GAPE:] That is a very good question that I honestly don't have a final answer to right now. And I share Your interest in wanting the spec finished, believe me. I do not know how one would document "supporting material" in the context of W3C but perhaps chairs have an idea there.  

Then we have the question if a deeper analysis of this (including UA vendor internal prototyping and discussion I assume, :-)) would result in a need of not only a description of how existing CSP directives could be used but also of new, improved CSP mechanisms, specific to WebRTC (excluding the getUserMedia part which some to be about to be addressed in blink as we speak). In the that case spec is needed at some point and in some WG, perhaps not the WebRTC one.

But a supporting material sounds like a good starting point.


Received on Wednesday, 4 February 2015 21:15:30 UTC