- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Feb 2019 05:32:26 +0000
- To: public-webrtc-logs@w3.org
I wonder how this PR translates in terms of implementation. If there is a query and one has two constraints, width and sampleRate, or width and audio deviceId, how am I supposed to know which one to pick? Should the spec define the rules of which constraint is triggering higher fingerprinting? How can we verify that implementation strategies cannot be abused? WebKit is returning an empty string constraint when getUserMedia is not granted or site has no persistent access. This is a simple strategy which is AFAIK the most robust against fingerprinting. If we cannot define a better strategy that is as robust and enables more use cases, I think the spec should allow implementations to pick this strategy. I would tend to add to the PR the following sentence: "Implementations MAY select no constraint to further limit fingerprinting risks". > However, we should probably be clear whether "tamper" extends to returning no name at all, which may be controversial (in today's spec, `error.constraint == ""` means _"you're getting close"_, i.e. none of the required constraints used would fail by themselves), it's solely a "combination failure". Is it controversial though? I am not aware of any real usage to "you're getting close" or to failure stats. I am not aware of queries used by websites for which the constraint information would provide really useful information. FWIW, this constraint mechanism is not providing sufficient information to real cases like "I want to get the same mic and camera as last time": the returned constraint would be deviceId but the important information for an app would be to know whether the failure is for mic, camera or both. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/pull/564#issuecomment-468143699 using your GitHub account
Received on Thursday, 28 February 2019 05:32:28 UTC