Re: ResourceTiming API & byte-size

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
>>>
>>
>>
>

Received on Tuesday, 29 January 2013 23:49:40 UTC