Re: Cross-Origin Restrictions

Are the concerns with providing the specific component times for 
3rd-party resources or to provide the timing information at all (and 
does the opt-in http header even address the concerns)?

Unlike CSS :visited, to make any use of the timing information you have 
to actively probe resources on the network and you can already get 
overall timing information from javascript so the component times would 
be the only new information being offered (and possibly a higher 
accuracy for the overall time).  Do the component times offer 
information that couldn't be gleaned through active probing today?

I can get your RTT to a bunch of different locations by requesting tiny 
resources from a few global locations from servers that don't keep 
connections alive and don't allow the resources to be cached.  Once I 
know your RTT I can infer just about everything else.

If I want to know if you have been to a banking site I can just request 
a static resource from the bank and time it - then compare the time to 
the expected RTT (different cacheability of resources will give me 
different levels of information).  Granted, it's one step more 
complicated than just referencing the resources and getting the timings 
but it's not offering up new information that you couldn't probe for before.


I'm on the fence about needing the component times for 3rd party 
resources as long as the overall start and end times are made 
available.  Ultimately the benefit for users will come from improved 
page performance as site owners (and 3rd-party widget providers) get 
information about the performance of all aspects of their pages from the 
field.  The component times would help diagnose issues faster (is it a 
back-end problem, a networking problem or a GSLB routing issue) but 
those can actively be investigated through other means.

-Pat

On 10/6/2011 5:44 AM, Sigbjørn Vik wrote:
> On Fri, 30 Sep 2011 01:15:34 +0200, Tony Gentilcore <tonyg@google.com> 
> wrote:
>
>> Thanks for the reminder and sorry for the delay. I think this is the
>> information we want to convey. Do you want to do any tweaking and send
>> then it out? I'm also happy to mail it on our behalf if you think it
>> is good to go.
>
> We've discussed this in the security group in Opera, and don't think 
> this is a good idea, for all the obvious reasons. While we didn't look 
> for novel attacks, it will increase the attack surface significantly 
> of a number of existing attacks. Third party DNS information is the 
> CSS :visited issue all over again, which browsers have been trying to 
> fix. Statistical fingerprinting is an issue which is small for every 
> working group, but in total large for affected users. Timing attacks 
> to know server setup, visited webpages, port scanning, guess at 
> credentials etc will all be easier. There is also no obvious user gain 
> by allowing this.
>
> The right question to ask would be what user gains there are in 
> allowing third party timing information, and if those gains are 
> significant, detail the potential gains, and then look for ways to 
> give those gains to user without privacy or security implications. The 
> security group considered allowing a user opt-in to such third party 
> information, similar to the geo-locaiton opt-in in browsers, but 
> rejected the idea, as it could find no reason why a user would want to 
> answer yes to such a question.
>

Received on Thursday, 6 October 2011 12:26:53 UTC