Re: [NavigationTiming] Privacy and fingerprintability

On 09/11/2012 05:56 PM, James Simonsen wrote:
> Yeah, this is the primary concern with the specs. We've discussed it
> extensively internally and on the list. Maybe we haven't done a good job
> recording the results in specs or wherever else is appropriate.

Thanks, it would help to mention the linkability issue distinct from
private information disclosure.
> 
> The basic conclusion of all the security & privacy teams is that
> fingerprinting attacks that use timing are already viable without
> Navigation Timing and this additional data doesn't open a new attack
> vector. The biggest concern was that if a solution was found for the
> existing timing attacks, it'd be harder to patch because of Navigation
> Timing.

> 
> In general, if we felt timing was insecure, we'd just disable the feature
> entirely. There's no need to distinguish between incognito and normal
> browsing.

There's a difference in the threat models. If users may not be looking
for indistinguishability of their browsers, most of the time, it's not a
security risk to them, but when they explicitly choose a privacy mode or
tool, it would be good if they were not made to expose extra potentially
identifying information.

> Note that I'm not an expert on security and privacy; I'm just summarizing
> what others have said in the past. You might want to follow up on the
> public-web-security thread from last year about this. [1]
> 
> James
> 
> [1]
> http://lists.w3.org/Archives/Public/public-web-security/2011Oct/0000.html

I saw that discussion, with reference mostly to the discoverability of
secrets and crypto operations.  With linkability, none of the individual
pieces may be sensitive, but their aggregation is.

--Wendy

> 
> 
> On Tue, Sep 11, 2012 at 2:38 PM, Wendy Seltzer <wseltzer@w3.org> wrote:
> 
>> I know it's late in the process, but I wanted to add a privacy concern
>> to the mix: Navigation timing can add to the fingerprintability of
>> browsers.  Even limited to same-origin, that origin's profiling of
>> browser latency could link multiple browsing sessions in unexpected
>> ways, hindering users' ability to browse anonymously. [0] (This is of
>> particular concern to the Tor Project [1], which aims to provide strong
>> anonymity through the Tor Browser Bundle [2] -- a uniformly
>> pre-configured browser and onion-routed anonymized network connections.)
>>
>> Noting that several of the Web Performance specs have fingerprinting
>> implications, I wonder whether the group might consider the linking
>> attack, distinct from private information disclosure. For example, if
>> someone doesn't want a website to be able to correlate comments with a
>> login ID, he might log out, clear cookies, and write under a pseudonym,
>> but still be identifiable based on his browser timing connecting his
>> would-be-anonymous activity to previous sessions.
>>
>> As a general response, then, should there be a way to disable response
>> to timing information requests? More broadly, might we consider a
>> standard profile for anonymous browsing (incognito mode, private
>> browsing) that disables uniquely identifying features (despite the
>> possible performance hit) to provide a larger anonymity set?
>>
>> Thanks,
>> --Wendy
>>
>> [0] See https://panopticlick.eff.org/ and
>> https://panopticlick.eff.org/browser-uniqueness.pdf
>> [1] https://www.torproject.org/
>> [2] https://www.torproject.org/projects/torbrowser.html.en and
>> https://www.torproject.org/torbutton/en/design/
>>
>> --
>> Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
>> http://wendy.seltzer.org/        +1.617.863.0613 (mobile)
>>
>>
>>
> 


-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Tuesday, 11 September 2012 23:30:44 UTC