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

-----Original Message-----
From: "Martin com>" <martin.thomson@gmail.com>
Date: Thursday 5 February 2015 00:12
To: Göran Eriksson <goran.ap.eriksson@ericsson.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, W3C WEBRTC
<public-webrtc@w3.org>
Subject: Re: CSP/CORS (Re: ICE exposes 'real' local IP to javascript)

>Quite a few months ago I raised a point about connect-src and data
>channels with the webappsec group.  I believe that they intend to
>consider covering data channels with that.
Great. Then that part of the issue can be considered handed over to the
webappsec group to be addressed there.
>
>After a discussion with several interested people, we could not
>determine any other WebRTC feature that might require similar
>protections.  I could do some archive spelunking to find some links,
>but I'm sure that you are equally capable of doing that.
Yep- sounds like a task for me. Thanks for the pointer. Apparently You
have done the homework already and that this case therefore is an issue
not worthwhile looking more into for the group right now (more for
concerned citizens to do offline which I will do, :-)). I trust Your
judgement. Thanks!

PS. If I find something, Iıll let You know, :-)!


>
>On 5 February 2015 at 08:15, Göran Eriksson AP
><goran.ap.eriksson@ericsson.com> wrote:
>> ---snip---
>>> >> 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.
>>
>> Regards
>> Göran
>>
>>
>>
>>

Received on Wednesday, 4 February 2015 23:35:00 UTC