Re: Cross-Origin Restrictions

Does the current spec allow the inspection of the start and end time for 3rd party components by default?

Sent from my iPhone

On Oct 7, 2011, at 6:42 AM, Patrick Meenan <pmeenan@webpagetest.org> wrote:

> Strange as it may seem, I actually believe the current Timing-Allow-Origin policy strikes the right balance between privacy concerns and giving site owners the information they need.  Erring on the side of the users for something this unknown is a lot safer than having to patch all of the browsers after release.
> 
> You can still build a full waterfall and you will have the start/end times for all 3rd-party resources so you can still identify which resources are causing issues.  If it's a DNS, networking or server problem your resolution would still be the same - contact the 3rd party or remove the widget.  Having more visibility doesn't help YOU as the site owner.  If the 3rd-party would benefit from having the additional detail then they could (and should) add the headers to allow cross-origin visibility.
> 
> I'd strongly encourage any providers that serve embeddable widgets to add the headers (ad providers, social buttons, analytics providers, etc) but that seems quite reasonable (and even if they don't there is no huge loss for the actual site owner).
> 
> I honestly can't think of a use case where I would NEED the detailed timing information of 3rd party resources to take action as a site owner.
> 
> Thanks,
> 
> -Pat
> 
> On 10/6/2011 7:07 PM, Ricardo Oliveira wrote:
>> Im w/ Patrick here:
>> 
>> 1) inferring if an object is in cache or not can already be done by looking at the download times of the object and the RTT
>> 2) if the default is to not send the times, 3rd party providers will not change their stacks to start sending "timing-allow-origin", so we will only see timings of local objects; given the current trend of increase of 3rd party content (cdns, cloud providers, apis), local objects will be a diminishing case.
>> 3) my  suggestion is opt-in by default for http and opt-out by default for https for timing visibility
>> 
>> Cheers,
>> 
>> --Ricardo
>> 
>> On Oct 6, 2011, at 8:11 AM, Sigbjørn Vik wrote:
>> 
>>> On Thu, 06 Oct 2011 14:26:24 +0200, Patrick Meenan<pmeenan@webpagetest.org>  wrote:
>>> 
>>>> 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)?
>>> This is for including detailed 3rd-party information.
>>> 
>>>> 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?
>>> Yes, it offers more detailed information in an easier and more reliable manner. A shift from e.g. a 50% chance of a good estimation to a 100% chance of an accurate result is quite significant.
>>> 
>>>> 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.
>>> The breakdown of where time went cannot be found without the new API. Over a network which varies a lot, it is curently impossible to determine such sub-times, but that will be possible with more details available. Making it easier and more detailed is just making black hat's lives easier.
>>> 
>>> One might as well ask the opposite question: If this new API didn't expose new things, what would the point of it be? Javascript libraries could add in timing information, and web developers could use that instead - most likely they will end up using the new APIs through some such libraries anyhow.
>>> 
>>>> 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.
>>> True, there are possible indirect gains, but not gains which depend on the individual user's information, nor any gains which matter to the user during that page load. If I as a use visit some shady site, I really don't care about possible gains for that site some time in the future, but I do care about my own privacy. (If I do care about that site's future, as well as trust the site, I might be convinced by the site to enable some site specific pref to give it more information though.)
>>> 
>>> -- 
>>> Sigbjørn Vik
>>> Core Quality Services
>>> Opera Software
>>> 
>> 
>

Received on Friday, 7 October 2011 17:57:38 UTC