Re: Request Privacy Review of Navigation Timing Level 2

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.  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 18:33:41 UTC