Re: Bug 23934 - Proposal: Always launch permission prompt to avoid leakage

On 05/12/2013 7:37 PM, Jan-Ivar Bruaroey wrote:
> On 12/5/13 2:25 PM, cowwoc wrote:
>> If you read https://panopticlick.eff.org/browser-uniqueness.pdf 
>> section 6.3 it explicitly states that "Fingerprintability is 
>> inversely proportional to Debuggability".
>
> Uhm, no it doesn't. The closest actual quote I could find is:
>
> " Plugin and browser developers want the option of occasionally 
> excavating the micro-version numbers of clients when trying to 
> retrospectively diagnose some error that may be present in a 
> particular micro-version of their code. This is an understandable 
> desire, but it should now be clear that this decision trades off the 
> user's privacy against the developer's convenience"
>
> Do you realize you're quoting from a polemic against fingerprinting? :-)

Sorry, I meant "Fingerprintability is *directly* proportional to 
Debuggability". I took that from the title of section 6.3. And yes, I'm 
aware of the fact that this document advocates taking steps to prevent 
browser fingerprinting, however (and this is very important!) they 
highlight the fact that doing so always comes at a price of debuggability.

>> There is no getting around this fact. Any time we take steps to 
>> protect against Fingerprinting we *will* suffer worse usability and 
>> debuggability.
>
> You're conflating usability with debuggability. I find no mention of 
> usability in the document.

I agree that the document does not mention usability explicitly but you 
cannot have good usability without access to information made available 
by "debuggability". When something goes wrong, "debuggability" allows 
you to find out why/what went wrong. An application leverages this 
information to provide a better user experience, especially in the case 
of a failure conditions.

Case in point: an end-user tries joining my conference bridge. He always 
gets a permission prompt, clicks "Allow" but the operation fails with 
some vague error. After many hours of investigation we still can't 
figure out whether the browser can't see the camera, or the camera 
doesn't support the requested resolution, or a camera-specific bug 
prevents the request from going through (e.g. 
https://code.google.com/p/webrtc/issues/detail?id=1912), or the user is 
doing something wrong (reporting he is doing something when he is not), 
etc. If I could read the camera's capabilities I could quickly 
investigate which of these conditions is occurring, but with your 
proposal I have no way of finding out. I don't look forward to 
supporting non-technical users who run into this kind of problem.

To summarize: I don't take issue with whether your proposal will prevent 
fingerprintability, nor with the fact that "fingerprinting is bad". My 
only argument is that preventing fingerprinting comes at a cost, and in 
this case I argue that doing so is not worth the price.

Gili