- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Tue, 11 Sep 2012 19:30:41 -0400
- To: James Simonsen <simonjam@chromium.org>
- CC: public-web-perf <public-web-perf@w3.org>
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