Re: Request Privacy Review of Navigation Timing Level 2

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