RE: Resource Timing - What's included

>> The problem with explicitly exposing "cache" vs. "network" is that it 
>> precisely exposes privacy information about the page's visitor.
>
> Existing dev-tools in the browser have access to all this information and don't expose it to JS in a way that would
> enable such an attack. So, I guess I should step back and ask, is there a way we could make this information available
> to "secure channels" (like in-browser dev tools, add-ons, plugins, etc) but not to potentially malicious JavaScript?
> If so, would that offer a possible relief from this attack vector?

But developer tools are extensions on your machine, that you've given explicit permission to run (by way of installing), that may be exposing additional information such as cache status (and a lot more).

Developer tools, add-ons and plug-ins all fall into the same bucket -- the user has to give explicit permission for them to run, and understands (or doesn't) the risk of doing so.

Our Resource Timing interface is scoped to simply be a DOM interface.  Even though we (as web developers) would be able to benefit from knowing the cache status of our visitors -- there are many useful scenarios that could enable -- we have to respect the user's privacy concerns.

You could construct additional dev tools or add-ons to gather the additional caching data -- it is a matter, at that point, of convincing the user to install them.

As for having the DOM request this permission, we could take a look at the GeoLocation spec [1], for example, which can expose the end-user's geo location.  However, the browser is *required* to get explicit permission from the user that their location data can be shared, via UI or something.  I don't see a compelling argument (from a user's POV) for Resource Timing that the user would want to expose his browsing history to a site.

> Even with static resources (like <img> or <script> tags in the page), the presence of multiple/duplicate containers that
> "request" the same resource affects the timing of how the page is assembled/rendered. Like in the previous email,
> where I said that multiple <script> elements for the same script will still still cause some "blocking" because the browser
> has to assume there may be a document.write() in each, which will affect how the rest of the DOM is assembled/interpreted...
> the timing impact of such should be quite obvious.

I agree with your desire to have timing information for all resources, but I don't think it's in the scope of what we're trying to achieve for Resource Timing.  For Resource Timing, we are essentially trying to mimic the information available from Network panels in developer tools.  Additionally, we are proposing only exposing new, previously unavailable information to the user -- the network latencies.  The in-browser timing delays you mention are all somewhat measurable today via JavaScript.

Including "timing" information for *all* resources (whatever that is defined is) is a much larger, and more challenging issue. 

With your example of multiple IMG tags referring to the same resource, you would be suggesting that all IMGs on the page would be included in the RT array.  Additionally, SCRIPT elements (even inline ones) would be included, because they block parsing progress.  Continuing down that line of thought, TABLEs (large ones take a while to parse) and SVGs (even inline) would be included, etc.  It becomes a much larger and more complex spec at that point.
 
Also, to be clear, the existing loadEventStart and loadEventEnd times in the spec are only capturing the actual time to run any load event handlers attached to that element.  They do not include the time to decode/render/display and IMG, nor would it include the time a SCRIPT tag would be blocking parsing progress.

For this spec, we are focusing on just exposing the previously unavailable network latencies.

> Would it be possible to simply expose "success" or "failure" of a loaded item, as opposed to the exact HTTP Response code? In other words, 1xx/2xx/3xx codes are "success", and 4xx/5xx codes "failure".
>
> Also, same question as above, is it possible to devise a system by which untrusted JavaScript gets the more filtered/watered-down data (to mitigate attacks), but tooling/add-ons have access to the more full-fledged data stream?

We talked about this in today's conference call.  Knowing 200 vs. 304 could be very valuable (for same-origin resources).  We will attempt to add the HTTP status code (in some fashion) into the next version of the spec.

Thank for all of your input so far!

[1] http://dev.w3.org/geo/api/spec-source.html

- Nic
-----Original Message-----
From: Kyle Simpson [mailto:getify@gmail.com] 
Sent: Wednesday, March 23, 2011 12:44 PM
To: Nic Jansma; public-web-perf@w3.org
Subject: Re: Resource Timing - What's included

> The problem with explicitly exposing "cache" vs. "network" is that it 
> precisely exposes privacy information about the page's visitor.

Existing dev-tools in the browser have access to all this information and don't expose it to JS in a way that would enable such an attack. So, I guess I should step back and ask, is there a way we could make this information available to "secure channels" (like in-browser dev tools, add-ons, plugins,
etc) but not to potentially malicious JavaScript? If so, would that offer a possible relief from this attack vector?


> I think we're on the same page -- we both want RT to expose the "observed" 
> behavior of browsers.
>
> My example below was a simplification of the issue, and meant to point 
> out one optimization that I believe all current modern browsers implement.
> For *static* elements within the page (e.g. <IMG />), current browsers 
> re-use prior duplicate resource URLs instead of downloading them twice.
> From my simple HTML example, only one resource request for 1.jpg would 
> occur.  Current browsers don't re-check the cacheability of resource 
> within the *same page* for *static* resources.

Even with static resources (like <img> or <script> tags in the page), the presence of multiple/duplicate containers that "request" the same resource affects the timing of how the page is assembled/rendered. Like in the previous email, where I said that multiple <script> elements for the same script will still still cause some "blocking" because the browser has to assume there may be a document.write() in each, which will affect how the rest of the DOM is assembled/interpreted... the timing impact of such should be quite obvious.

But if only 1 listing in the RT array shows for the first network delay request, what's missing in that picture is how that resource being re-interpreted multiple times on the page had timing impacts on the page and on other resources.


>>Yes, and furthermore, I think (mostly for data filtering purposes) 
>>having the status code actually in the data structure would be 
>>important. For instance, if a  tool analyzing this data wants to 
>>filter out all 404's, etc.
>
> There may be some privacy/security aspects about exposing the HTTP 
> response code, especially for cross-origin domains.  For example, the 
> presence of a 301 response from a login page on another domain could 
> indicate that the user is already logged in.

Would it be possible to simply expose "success" or "failure" of a loaded item, as opposed to the exact HTTP Response code? In other words, 1xx/2xx/3xx codes are "success", and 4xx/5xx codes "failure".

Also, same question as above, is it possible to devise a system by which untrusted JavaScript gets the more filtered/watered-down data (to mitigate attacks), but tooling/add-ons have access to the more full-fledged data stream?


--Kyle

Received on Wednesday, 23 March 2011 22:16:51 UTC