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.
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.
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
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)
>
>
>