- From: Christian Biesinger <cbiesinger@gmail.com>
- Date: Tue, 29 Jan 2013 15:49:13 -0800
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <CACpOFMund3uw5Ma9+K6F2KxeW3urhPxyUQ9uF=jz4oBhadbdew@mail.gmail.com>
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