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

On 10/12/2013 1:42 PM, Stefan Håkansson LK wrote:
> On 2013-12-10 17:43, cowwoc wrote:
>> On 10/12/2013 9:58 AM, Stefan Håkansson LK wrote:
>>> On 2013-12-10 02:26, Eric Rescorla wrote:
>>>> For the record, I am opposed to this entire piece of Jan-Ivar's proposal.
>>>>
>>>> As has been observed many times, there are plenty of opportunities
>>>> for fingerprinting and so going through these gyrations to make
>>>> it fractionally more difficult is silly.
>>> Is there broad consensus that there is no point in trying to be careful
>>> when it comes to fingerprinting - that it is a battle that is already lost?
>> I'd like to draw your attention to
>> http://www.w3.org/wiki/images/7/7d/Is_preventing_browser_fingerprinting_a_lost_cause.pdf
> I don't know who is behind that pdf, or what I should take away from it.
> There are opinions going both ways.

Right. I wasn't trying to imply one way or the other. I just thought you 
might find that document an interesting read.

I think the author is Brad Hill. I tracked the document back to 
http://www.w3.org/wiki/TPAC2012/SessionIdeas#Is_user_agent_Fingerprinting_a_lost_cause.3F 
and what's funny is your name is listed under "People who have expressed 
interest".

In case you are interested in my (biased) interpretation:

  * Securing the entire browser against fingerprinting is very
    difficult, if not impossible.
      o Page 12: There are "Millions of lines of code and thousands of
        API points" that already leak fingerprinting information.
  * Securing only WebRTC against fingerprinting
      o Page 8: Ease of Circumvention vs Ease of Securing. My
        interpretation is that protecting against fingerprinting is not
        cheap. It requires ongoing work to stay ahead of the curve.

There is a nice quote in page 24 by Dan Kaminsky: "The whole *point* of 
DNT is that there's no technical fix, starting right at the non-random 
IP address that queries you"

So yes, my interpretation is that the battle is lost but obviously the 
document contains a lot of arguments that also point in the opposite 
direction (that even if the battle is lost, there might be a way to 
recover).

No matter which way you are leaning on the fingerprinting debate, I 
think it's pretty clear that you will not solve browser fingerprinting 
without a concerted effort across *all* API surfaces. Trying to solve 
the problem exclusively in WebRTC is meaningless in the grand scheme of 
things.

Gili