RE: Font Based Fingerprinting Papers

Fingerprinting could be being used to cookie sync, match 1st party cookies on different sites to the same person. This used to be done with 3rd party cookies but now with ITP etc. they are often not available.

A few extra bits via fingerprinting, and the time of the page load, maybe is enough to correlate  first party cookies. It only has to be done once per site also, so the computation load is not so important.

But I think the way to mitigate it is to control 1st party cookies rather than try to stop fingerprinting, like the way Safari's ITP 2.1 is starting to do (7 day expiry for 1st party script placed cookies). 

Mike West has a proposal that could eventually replace cookies (in many use cases) with a browser generated short duration (1 hour default) token, inaccessible to script. 
https://github.com/mikewest/http-state-tokens/blob/master/README.md

I have a maybe complementary one that would enable sites to limit the duration of all browser storage once user interaction stops.
https://github.com/w3cping/storage-policy

Mike

-----Original Message-----
From: Pete Snyder <psnyder@brave.com> 
Sent: 19 April 2019 22:07
To: Aleecia M McDonald <aleecia@aleecia.com>
Cc: public-privacy (W3C mailing list) <public-privacy@w3.org>
Subject: Re: Font Based Fingerprinting Papers

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
Brave Software
Privacy Researcher

> On Apr 19, 2019, at 10:45 PM, Aleecia M McDonald <aleecia@aleecia.com> wrote:
> 
> Marginally relevant paper from Aug 2018 @ USENIX: 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
> 
> 
>

Received on Friday, 19 April 2019 22:02:28 UTC