Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[Balwant Bisht <[e-mail]>]

All VPN setup are not for hiding location, but some are setup to allow
remote users to connect to company network. If MCU server is inside VPN and
browser didn't get VPN candidates then its not possible to establish
PeerConnection with MCU. Also linking it with device access is bad, e.g. if
participants joining a webinar and they didn't want to give access to
devices, they will not be able to join at all.



Regards
Balwant Bisht


On Thu, Mar 29, 2018 at 10:09 AM, Justin Uberti <
juberti=[e-mail]> wrote:

> Note that this VPN behavior is not unique to web browsers. Mobile
> applications are free to use whichever interface they prefer without
> needing any additional user permissions.
>
>
> On Wed, Mar 28, 2018 at 7:15 AM westhawk <[e-mail]> wrote:
>
>> I tend to agree with Cullen here, this is an issue. (As I said when I
>> first raised it way back when).
>>
>> It is bad practice to ask a user one (clear) question and the deduce
>> their agreement to some other things that aren’t (at least to the user)
>> related.
>>
>> Conversely an infinite series of questions before each call isn’t going to
>> work either,
>>
>> With that in mind, perhaps we are hanging off the wrong existing consent.
>> Given that the VPN users in question are (in practice) trying to hide
>> their location,
>> perhaps that’s the dialog we should hang off instead.
>>
>> “This page would like to use your location: allow, deny”
>> would also unlock public IP address access.
>>
>> Tim.
>>
>>
>> > On 27 Mar 2018, at 17:57, Cullen Jennings <[e-mail]> wrote:
>> >
>> > Theses comments are sent as an individual contributor.
>> >
>> > Let me start by saying I think I am in the rough on the consensus of
>> this draft and I expect the draft to be sent to the IESG with no changes.
>> For the record, as I have said at the floor microphone in the past, I don't
>> agree with the draft.
>> >
>> > This draft results in the situation where implementations decide if
>> they should reveal the users location to the website by asking a questions
>> of the form "Will you allow example.com to use your camera?" If the user
>> says that is OK to use their camera, in many cases they have also allowed
>> the website to get their location via the IP address. From a user point of
>> view, I think this is awful, There are many reasons I might allow a website
>> I do not trust to know my location to access my camera - for example, I
>> have a black cover over my camera and the website won't work unless I say
>> yes to this request. Or a webcam worker where the job involves revealing
>> video but revealing the locations they work at may put them at risk of
>> serious harm. Or I am in a domestic abuse shelter and want to have a call
>> but revealing may location puts me at risk of physical harm. I do not think
>> the IETF should in any way endorse this extremely misleading form of
>> consent. It is simply not consent. I realize this would be good for
>> companies that are primary funded by by web advertising for which location
>> is valuable.
>> >
>> > There are several people who's opinion I deeply respect that have
>> looked at this problem in detail. They somewhat agree the above is a
>> problem, but they argue it is better than any alternative design. I
>> disagree with this.The root of the problem we are trying to solve with this
>> draft is that some VPNs are configured to send some packets over the VPN
>> while at the same time some other packets are not sent over the VPN. If you
>> use a VPN configured like this to try and hide your location, WebRTC can
>> end up sending packets not over the VPN and that can reveal your location.
>> I think the right solution to this problem is to acknowledge this is a VPN
>> problem, not a WebRTC problem. If you are using a VPN to hide your
>> location, do not allow that VPN to send packets outside the VPN. I will
>> note most VPNs support this.
>> >
>> > John Morris words from [1], more or less sum up about how I feel about
>> this - just reverse W3C and IETF.
>> >
>> >    "By not actually building privacy into the specification, the W3C has
>> >    both missed a significant opportunity to improve user privacy on the
>> >    Web, and it has harmed the efforts of another standards body -- the
>> >    IETF -- to protect location privacy and to improve the privacy
>> >    paradigm for Internet services."
>> >
>> > From a process point of view: 1) I have had time to express this
>> opinion in the rtcweb WG meetings and it has been discussed. My read of the
>> consensus in the room is that I am in the rough on this topic  2) I don't
>> think the rtcweb WG is the WG in the IETF with the most expertise in VPNs
>> >
>> > Thanks, Cullen
>> >
>> >
>> > As FYI, the actual questions that are asked by today's browsers are
>> roughly the following:
>> >
>> > In firefox: "Will you allow webrtc.github.io to use your camera?"
>> >
>> > In chrome: "webrtc.github.io wants to use your camera"
>> >
>> > In safari: "Allow webrtc.github.io to use your camera?"
>> >
>> > In edge: "Let webrtc.github.io use your webcam?”
>> >
>> >
>> > [1] https://lists.w3.org/Archives/Public/public-geolocation/
>> 2009Jul/0020.html
>> >
>> >
>> >
>> >> On Mar 7, 2018, at 7:49 PM, Sean Turner <[e-mail]> wrote:
>> >>
>> >> All,
>> >>
>> >> This is the WGLC for the "WebRTC IP Address Handling Requirements”
>> draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-
>> handling/.  Please review the draft and send your comments to this list
>> by 2359UTC on 30 March 30 2017.
>> >>
>> >> Thanks,
>> >> C/T/S
>> >> _______________________________________________
>> >> rtcweb mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>