Re: ResourceTiming API & byte-size

In yesterday's meeting I saw that byte-size was mentioned, and james is
opposed to adding that value:
"I feel that the interface should only include novel information that isn't
easily available today. The server serving the resources already knows the
size of the images."

Image size is often *not* easily available to the server's logic (e.g.
mod_pagespeed automatically optimized images, and as far as the server
logic is concerned, it is a lower layer)
Image size information would enable:
* Creating full fledged waterfall charts in the browser
* Possibly estimating bandwidth [1] in JS, which can bring in much more
people to solve the bandwidth estimation problem.

I agree that at least in some cases these applications can be done by
having the server send over a manifest that includes a resource size map,
but that is not always the case, a


[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0086.html


On Wed, Jan 30, 2013 at 2:11 AM, Arvind Jain <arvind@google.com> wrote:

> I looked through the archives for previous discussion on this, and I found
> only one thread:
> http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0059.html
>
> I suppose we could add the size field in next revision. We'll keep track
> of this for Resource Timing v2.
>
>
> On Tue, Jan 29, 2013 at 3:49 PM, Christian Biesinger <cbiesinger@gmail.com
> > wrote:
>
>> Nvm, missed the "same origin" part of the question.
>>
>> -christian
>>
>>
>> On Tue, Jan 29, 2013 at 3:48 PM, Christian Biesinger <
>> cbiesinger@gmail.com> wrote:
>>
>>> Why do you say this poses no security risk? Byte size can reveal things
>>> like "is user logged in to site X", which is not something we should expose.
>>>
>>> -christian
>>>
>>>
>>> On Tue, Jan 29, 2013 at 3:39 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>>> Since it poses no security risk and can be extremely useful, can byte
>>>> size information be added to same origin resources in a future version of
>>>> the Resource Timing API?
>>>>
>>>> Thanks,
>>>> Yoav
>>>>
>>>>
>>>> On Thu, Jan 3, 2013 at 12:23 AM, Jonas Sicking <jonas@sicking.cc>wrote:
>>>>
>>>>> On Wed, Jan 2, 2013 at 6:09 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>> >
>>>>> > I'm wondering if there's any reason the resource's byte-size &
>>>>> compressed
>>>>> > byte-size were not added to the ResourceTiming API.
>>>>> >
>>>>> > The use cases I see for adding this information to the API would be:
>>>>> > 1. Enabling Web apps access to the full information required to
>>>>> create
>>>>> > complete waterfall charts or HAR files that are equivalent to the
>>>>> browser's
>>>>> > own Web Inspector/developer tools. Current demos creating a
>>>>> waterfall chart
>>>>> > [1] or HAR files [2] either ignore the file size altogether, or use
>>>>> the IE
>>>>> > only property of "fileSize" on image resources.
>>>>> > 2. Detecting compression issues using RUM scripts (text resources
>>>>> that
>>>>> > were not GZIPed, automated image compression regressions).
>>>>> > 3. Enabling Web applications to get a notion of the average download
>>>>> > bandwidth each resource had. Even though such a measurement may not
>>>>> be
>>>>> > accurate (because of slow-start, contention, packet losses,
>>>>> different hosts
>>>>> > per resource, etc), it may be useful information either for RUM or
>>>>> for
>>>>> > progressive enhancement purposes.
>>>>>
>>>>> The byte size and the compressed byte size can't be exposed for
>>>>> cross-origin loads. Other than that I don't see any security issues
>>>>> with this.
>>>>>
>>>>> / Jonas
>>>>>
>>>>
>>>>
>>>
>>
>