Re: Request Privacy Review of Navigation Timing Level 2

Sure, for example, say I want to figure out what other sites a user has visited, either because I think that will be semi-identifying (finger printing) or otherwise valuable, say for add targeting (history leak).

Previously I’d do something like this https://www.brokenbrowser.com/css-history-leak/

Instead, I 
1) build a large set of websites
2) find resources referenced on each site, and served with “*” from each of those domains
3) load them from my page, and use the new high res timing information to see which ones load very quickly (e.g. are cached) and use that to determine the browsing history of the user (and possibly finger print them)

If the standard required that serving domains didn’t allow “*”, but instead required specifying domains, the above attack would be more difficult (the attacker would need to rely on other, potentially less reliable, and definitely less fine grained, methods to try and get the same timing information)

Pete

> On Dec 18, 2018, at 10:56 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> 
> 
> On Tue, Dec 18, 2018 at 7:33 PM Pete Snyder <psnyder@brave.com> wrote:
> Hello Yoav and Xiaoqian,
> 
> The concern about the “*” is not that it’d reveal something about the user’s state, its that a single site serving a large number of files, sending “*” could be used as the timing vector for the finger printing. 
> 
> Can you detail the attack here? What does the timing vector of a single subresource expose, and how is that used for fingerprinting?
>  
> The suggestion for not having a “*” option, and requiring an explicit list of domains isn’t to push the domain-calculation logic onto the server, its to limit the number of pages that have access to the timing information to where its useful for first-party testing purposes.
> 
> As you mention, high resolution timing information comes with privacy risk.  The advice “unless there is a compelling reason to do otherwise, serve ‘*’” does not address the timing / fingerprinting / privacy concern.  Instead, the header should be a way of limiting the timing information to sites the server trusts (or, at least make it more difficult for the server to give the information away).
> 
> Xiaoqian, I looked at the GH issue you mentioned.  It seems to be addressing something different though; about whether there should be wildcards w/in domain definitions.  My suggestion is different, its to not allow any wildcards at all.
> 
> Best,
> Pete
> 
> > On Dec 18, 2018, at 2:49 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> > 
> > Hey Pete!
> > 
> > 
> > On Tue, Dec 18, 2018 at 9:00 AM Xiaoqian Wu <xiaoqian@w3.org> wrote:
> > Thanks Pete!
> > 
> > There is an on-going discussion of allowing semi-wildcard 
> > `Timing-Allow-Origin` values [1] on GitHub, your comment will be very 
> > appreciated there.
> > 
> > Looking back at the early discussions of Timing-Allow-Origin, there was 
> > suggestions to use the Timing-Allow-Origin: * header for embedded 
> > widgets [2] :
> > [[
> > I'd like to encourage all companies that provide widgets that get
> > embedded in other people's pages to also include the
> > Timing-Allow-Origin: * header for transparency into their service but
> > I'd hate to be encouraging people to do it if it is the wrong thing to
> > do for privacy reasons.
> > ]]
> > 
> > Tony Gentilcore drafted a summary for the privacy concern of the 
> > cross-origin restriction for these Timing APIs in 2011 [3], hope it 
> > helps.
> > 
> > -xiaoqian
> > 
> > [1] https://github.com/w3c/resource-timing/issues/175
> > [2] 
> > https://lists.w3.org/Archives/Public/public-web-perf/2011Sep/0003.html
> > [3] 
> > https://lists.w3.org/Archives/Public/public-web-security/2011Oct/0019.html
> > 
> > On 2018-12-15 06:44, Pete Snyder wrote:
> > > Hi Xiaoqian,
> > > 
> > > Thanks for this.  I’m very nervous about the cross origin /
> > > Timing-Allow-Origin proposal.  What is the thinking for allowing a “*”
> > > there?  
> > 
> > For any resource which is public and does not reveal anything regarding the user's state, it should include a TAO header of "*".
> > This is very similar to CORS, and in-fact I'm suggesting that the concept be somewhat unified, and that CORS-enabled resources would also have their timing exposed.
> >  
> > What cases are anticipated that wouldn’t be solved by
> > > requiring the server to explicitly mention domains. 
> > 
> > That raises a significant deployment hurdles for people that want to deploy TAO, as it requires dynamic serving logic instead of static one.
> >  
> > My concern here
> > > is that it would only take a single domain serving Timing-Allow-Origin
> > > =  “*” to allow the new timing information to be used to increasing
> > > the FP-via-timing channel.
> > 
> > What's "FP" in this context?
> >  
> > > 
> > > Thanks,
> > > Pete
> > > 
> > >> On Dec 14, 2018, at 6:00 AM, Xiaoqian Wu <xiaoqian@w3.org> wrote:
> > >> 
> > >> Hi,
> > >> 
> > >> The WebPerf WG is working on a new version of the Navigation Timing 
> > >> spec:
> > >>  https://www.w3.org/TR/navigation-timing-2/
> > >> 
> > >> Most of the L2 features have been implemented by the major browsers.
> > >> [[
> > >> Navigation Timing 2 replaces the first version of [NAVIGATION-TIMING] 
> > >> and includes the following changes:
> > >> 
> > >> * the definition of Performance interface was moved to 
> > >> [PERFORMANCE-TIMELINE-2];
> > >> * builds on top of [RESOURCE-TIMING-2];
> > >> * support for [PERFORMANCE-TIMELINE-2];
> > >> * support for [HR-TIME-2];
> > >> * support for prerender navigations [RESOURCE-HINTS];
> > >> * exposes number of redirects since the last non-redirect navigation;
> > >> * exposes next hop network protocol;
> > >> * exposes transfer, encoded body and decoded body size information;
> > >> * secureConnectionStart attribute is now mandatory.
> > >> ]]
> > >> 
> > >> The L2 spec contains a privacy consideration section, which introduces 
> > >> the timing allow check algorithm defined in Resource Timing L2 spec.
> > >>  https://www.w3.org/TR/navigation-timing-2/#privacy
> > >> [[
> > >> There is the potential for disclosing an end-user's browsing and 
> > >> activity history by using carefully crafted timing attacks. For 
> > >> instance, the unloading time reveals how long the previous page takes 
> > >> to execute its unload handler, which could be used to infer the user's 
> > >> login status. These attacks have been mitigated by enforcing the 
> > >> timing allow check algorithm when timing information involving the 
> > >> previous navigation is accessed. [RESOURCE-TIMING-2]
> > >> 
> > >> The relaxed same origin policy doesn't provide sufficient protection 
> > >> against unauthorized visits across documents. In shared hosting, an 
> > >> untrusted third party is able to host an HTTP server at the same IP 
> > >> address but on a different port.
> > >> ]]
> > >> 
> > >> Please let us know if there is any new concerns for the Navigation 
> > >> Timing API before the end of January, either by 
> > >> emails<public-web-perf@w3.org> or GitHub issues 
> > >> <https://github.com/w3c/navigation-timing/>.
> > >> 
> > >> Thanks.
> > >> 
> > >> -xiaoqian
> > >> 
>

Received on Tuesday, 18 December 2018 19:08:58 UTC