Re: Request Privacy Review of Navigation Timing Level 2

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?  What cases are anticipated that wouldn’t be solved by
> requiring the server to explicitly mention domains.  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.
> 
> 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 08:00:22 UTC