Re: Request for feedback: Media Capture and Streams Last Call

On Tue, Jun 30, 2015 at 2:49 PM, Nick Doty <> wrote:

> That's true, many fingerprinting mechanisms are difficult to provide
> transparency for. I don't take that as an argument that all future features
> should be equally so, such that no improvement in any feature can improve
> the overall situation. Canvas has seen some blocking for that reason;
> wouldn't it be better to avoid that with WebRTC if it's possible to do so?

I think that depends on the impact on the deployability of WebRTC, no?

> The webRTC standard is very troublesome from a privacy standpoint in other
> ways. Not only all your local IP addresses  (inside the NAT) visible,
> I'd really like to see a good analysis for why you think addresses behind
> the NAT are
> especially sensitive:
> 1. They are drawn from very small set of addresses (comparatively).
> 2. They change every time your public IP address changes.
> VPNs are different, of course, but then it's not clear how good a job VPNs
> do
> of preserving privacy.
> I think Wendy has been starting a list for us of some of the concerns
> around local IP address discoverability. On the NAT question, off the top
> of my head I'm aware of the problems of: 1) easier browser fingerprinting;

I keep hearing people say that it makes browser fingerprinting easier, but
the points
I raised above seem to call this argument into question, so I'd appreciate
a real

> 2) facilitating attacks on local network infrastructure.

Well, again, given that the IPs are drawn from a pretty small pool, it's
not clear
that it's actually that hard to discern which of these pools they are from.

> VPNs are indeed different! I'm no expert in that particular question, but
> I imagine some people would disagree with the conclusion that because there
> are some privacy risks even when using a VPN that there's no privacy harm
> in exposing IP addresses that users are obfuscating.

I think it depends how good a job the VPN does ordinarily of hiding the IP

> I would prefer it if we could design APIs as much as possible so that
> browsers don't need to make a choice between functionality and exposing
> additional information about a user. Yes, users should be able to just turn
> off functionality together and sometimes will feel the need to do so, but
> if we can design a feature so that a large number of use cases don't
> require such a trade-off, then we can benefit from that.

Sure, but I don't think shoving more permissions dialogs at the user is the
right way to do it.
Martin Thomson has suggested using double keying here. Would people
consider that

As it is now, do user agents that want to block access to a list of
> attached webcam devices have to completely block use of WebRTC, even when
> there's a permission grant?

AFAIK, yes.


Received on Tuesday, 30 June 2015 21:55:41 UTC