Re: Font Based Fingerprinting Papers

Dear all, 

together with Pierre Laperdrix (the author of amiunique.org <http://amiunique.org/>, in CC) and his PhD co-advisors, we have written a survey covering all the studies on browser fingerprinting: 
https://arxiv.org/abs/1905.01051 <https://arxiv.org/abs/1905.01051>

Pierre is an expert in browser fingerprinting and says there are at least 7 new studies on fingerprinting that he plans to add to the next updated version of the survey. 

Best,
Nataliia


> On 30 Apr 2019, at 05:44, Nataliia Bielova <nataliia.bielova@inria.fr> wrote:
> 
> To complement, here are more papers on measuring how common is fingerprinting in the wild, all the papers are from 2013-2014. The latest work I am aware of is OpenWPM that Mike has mentioned (http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf <http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf>).
> 
> Gunes Acar, Marc Juarez, Nick Nikiforakis, Claudia Diaz, Seda Gürses, Frank Piessens, and Bart Preneel. 2013. FPDetective: dusting the web for fingerprinters. In Proceedings of the 2013 ACM SIGSAC Conference on Computer & CommunicationsSecurity (CCS’13). 
> https://www.securitee.org/files/fpdetective_ccs2013.pdf <https://www.securitee.org/files/fpdetective_ccs2013.pdf>
> 
> FPDetective measures fonts fingerprinting by logging all the calls of font probing methods. A script that loads more than 30 fonts or a Flash file that contains font enumeration calls is considered to perform fingerprinting. They found 0.04% of sites (404 out of 1M) performing JavaScript-based font probing and 1.45% sites (145  out of 10K) performing Flash-based font probing.
> 
> 
> Gunes Acar, Christian Eubank, Steven Englehardt, Marc Juarez, Arvind Narayanan, and Claudia Diaz. 2014. The Web Never Forgets: Persistent Tracking Mechanisms in the Wild. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS ’14).
> https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf <https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf>
> 
> Here the authors measured canvas fingerprinting. They instrumented the browser to intercept calls and returns to Canvas related methods, and tried to remove false positives by a set of rules (more details in Section 3.1). They found  5.54% of sites (5,542  out of 100K) performing Canvas fingerprinting.
> 
> 
> Best, 
> Nataliia
> 
> ---
> Nataliia Bielova
> Researcher at Inria
> http://www-sop.inria.fr/members/Nataliia.Bielova/ <http://www-sop.inria.fr/members/Nataliia.Bielova/>
> https://twitter.com/nataliabielova
> 
>> On 19 Apr 2019, at 23:07, Pete Snyder <psnyder@brave.com <mailto:psnyder@brave.com>> wrote:
>> 
>> Thanks for sharing this Aleecia.  Its a good paper! Antonine Vastel (the lead author) did an internship with me last summer at Brave, and I can give him a 👍 recommendation for anyone here looking for a privacy researcher.
>> 
>> However, I don’t think the finding / argument in the paper quite applies in this case, since (presumably, hopefully) changes to the standard would result in changes to implementors (i.e. the common browser cores).  So the mitigation wouldn’t result in people accidentally winding up in unexpectedly small anonymity sets (since all users of the browser[s] would be shifted to the same change).  Does that match your understanding of the situation?
>> 
>> P.S. the TL;DR; of the paper is that there are a lot of privacy tools that advertise / try to improve web privacy by (for example) blocking a fingerprintable browser characteristic (say, unique details of how chrome does Canvas on a specific piece of hardware).  The authors find that a lot of these tools actually make users more identifiable, because they make narrow changes.  Before installing the tool, the user was in the anonymity set of people using that version of chrome on that hardware.  After installing the tool, they may have blocked access to the canvas FP vector (some privacy benefit), but they’ve shot themselves in the foot because they’re in the much smaller anonymity set of people using the given tool.  The argument is a bit more involved than that, but thats the 9/10ths high level of it.
>> 
>> But, again, I dont think it applies here, because if all users of an implementation picked up the same mitigation / protection, the anonymity set would strictly increase (i.e. the user would be more private).
>> 
>> 
>> Pete Snyder
>> {pes,psnyder}@brave.com <http://brave.com/>
>> Brave Software
>> Privacy Researcher
>> 
>>> On Apr 19, 2019, at 10:45 PM, Aleecia M McDonald <aleecia@aleecia.com <mailto:aleecia@aleecia.com>> wrote:
>>> 
>>> Marginally relevant paper from Aug 2018 @ USENIX: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-vastel.pdf <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-vastel.pdf>
>>> 
>>> Tl;dr — techniques to obfuscate fingerprinting often harm more than help. 
>>> 
>>> (Also contains citations to papers quantifying fingerprinting in the wild but I lack time to chase them down)
>>> 
>>> Title: Fp-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies 
>>> Authors: Antonine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy
>>> 
>>>  Aleecia
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Best, 
Nataliia

---
Nataliia Bielova
Researcher at Inria
http://www-sop.inria.fr/members/Nataliia.Bielova/ <http://www-sop.inria.fr/members/Nataliia.Bielova/>
https://twitter.com/nataliabielova <https://twitter.com/nataliabielova>