Re: WebPerfWG call - May 19th 10am PST

Hey folks,

Minutes and video from the call are now available. Copying the minutes here
for safe keeping:

WebPerfWG call - May 21st 2020


Yoav Weiss, Michal Mocny, Nic Jansma, Steven Bougon, Philippe Le Hegaret,
Nicolás Peña, Alex Christensen, Annie Sullivan, Gilles Dubuc, Michelle Vu,
Next Meeting

June 4th @ 10am PST / 1pm EST
CFC for Group Extension

   - Philippe: No feedback on mailing list
   - Yoav: Haven’t seen any objections
   - Decision - Extend the charter

IssuesResourceTiming Information Types

   - Presentation
   - Yoav: We need to better categorize the types of information that
   ResourceTiming is exposing, and see what different opt-ins fit for which
   types of information
   - ... RT historically only exposed timing information (DNS, TCP, TTFB,
   - ... we have a bunch of feature requests for processing time, and
   already expose it through Element Timing’s rendering time
   - ... sensitivity of this information varies
   - ... DNS, TCP and TLS information doesn't not expose anything
   user-specific to that origin.  It can expose information related to the
   user's network status, but that can also be gathered elsewhere
   - ...TTFB, processing time can expose information about that user (how
   long it takes to generate user-specific data)
   - ... Sizing information such as encoded-, decoded- and transfer-size
   exposes information about the user through the content they load
   - ... i.e. through tranferSize, exposing the credentialed resource size
   and header size can give information about login state and other sensitive
   - ... transferSize also reveals caching information or whether it was
   re-validated.  We have feature requests related to code caching and/or
   explicitly caching information.  This is potentially sensitive today
   (exposing the user history), but we say this is OK because this can also be
   reliably exposed in other ways.
   - ... But in a double-key-cached world, this will no longer be sensitive
   information, and would potentially not require an opt-in
   - ... This is my opinion as an editor of ResourceTiming, and I have not
   yet solicited feedback from Chrome/security folks.
   - Philippe: What’s double-keyed caching?
   - Yoav: Keying the resource based on both its URL and the top-level
   domain that requested it. Shipped in Safari in 2012, Chrome to switch to
   that soon.
   - ... Next is protocol information via nextHopProtocol, and some
   requests for cipher information and Server IP.  One of the issues that PING
   has opened is that it can reveal information about one's network (e.g.
   proxy settings).  We think this could also be detected by characteristics
   of resource loads (e.g. H1 vs H2 load differences)
   - ... Some of this information could possibly be handled by ServerTiming
   instead.  If that's not the case, we need to decide if this information is
   OK to expose, and if so, it doesn't match any of the existing opt-ins
   (which we'll talk about later)
   - ... Last we have initiator information, initiatorType, and a proposal
   for more details about the initiator elements.  I don't think this exposes
   new sensitive information, but we need to make sure of that. We know that
   we need to make sure we don’t exepose post-redirect URLs.
   - ... Finally we have requests for Status Code and Content Type, and
   this is sensitive information as it can reveal details about the user if
   the content is credentialed.
   - ... We also have a proposal by Nic about automatic reporting of a
   frame to its parent about its resources.  This might be a separate thing
   with its own Opt-In.
   - .... We have a few opt-ins available: Timing-Allow-Origin, used for
   opting in timing and size information.
   - ... Cross-Origin-Resource-Policy - a relatively new opt-in that
   signifies a resource can be safely embedded by other content, even in a
   world with Spectre and Meltdown.
   - ... CORS allows complete sharing of the resource across different
   - ... How do we map the types of information to those opt-ins?
   - ... Timing-Allow-Origin would expose timing information, and not much
   else.  For developer recommendations it seems that it's perfectly OK to add
   TAO for public resources, and slightly personalized resources.
   - ... Cross-Origin-Resource-Policy should be OK to reveal sizing
   information (similar to measureMemory API).  From my perspective it also
   seems safe to expose timing information in those cases, similar to what TAO
   does.  We could turn this on for public resources for those which may not
   be CORS fetched.
   - ... CORS content is fully exposed.  Timing, sizing and response
   information is OK to expose.
   - … Thoughts?
   - Nic: Helpful to scope the different buckets and map them to opt-ins.
   - Michal: How would conflicting headers affect this?
   - Yoav: I think CORS either passes or fails, and if it fails, it doesn't
   apply.  Then if TAO is on the resource and it passes, it would apply.
   - ... Ideally, CORS is a stronger policy than CORP, which is stronger
   than TAO, so the strongest that passes would apply
   - Steven: How do we effectively explain this to the community?
   - Yoav: Agreed that explaining this already is and could be a challenge
   - ... I'm hoping that the “layered” opt-ins would be easier to explain.
   CORS is complex, CORP is a bit simpler. There are a bunch of new
   capabilities bound behind CORP, so that might motivate people to understand
   CORP beyond performance APIs
   - Nic: We would need good documentation in the spec itself
   - Yoav: This could affect the RUM community.  In cases where CORS is
   enabled but not TAO, RUM would be able to get more timing information
   automatically.  But in cases where there’s TAO but not CORS, they'd just
   get timing information and not size info.
   - Steven: Would like to see some sort of guide or table which describes
   what happens in each case or bucket when these headers apply
   - Michal: Where I'm concerned is that it's not self-documenting based on
   the header name, where if you just have Timing-Allow-Origin it's not
   obvious what's missing.
   - Yoav: a shame that they’re not self-explanatory. We can use work to
   define the relationship between CORS and CORP to also include TAO.
   - Alex: We do agree if you have access to the content bytes, then access
   to the timing information is less sensitive.  We have similar assumptions
   for WebRTC. We need to help people understand the principle.
   - ... The only detail about this that I kind of disagree with is that
   the timing info about the DNS data and how easy it is to measure it outside
   of this API
   - Yoav: The way that I thought about it is there are ways of measuring
   hosts that are expected to not resolve, to time DNS
   - … Will run this proposal by folks and let y’all know how it goes.



   - Yoav: Mostly discussed by the above


   - Yoav: Similar issue


   - The step to queue a task to run fire a buffer full event should
   specify its source
   - Yoav: Editorial, I will just do that



   - Is the observer buffer of a PerformanceObserver a
   PerformanceObserverEntryList or a PerformanceEntryList?
   - Yoav: Editorial, moved to Level 2



   - PerformanceNavigationTiming needs a realm
   - Yoav: Need realm to create NavigationTiming entry, but navigation may
   get started before the document exists
   - Nicolás: Keep variables around until document is created, Editorial
   - Yoav: Is there any other precedence for objects created before the
   - Nicolás: Not sure
   - Alex: question. Can we move the entry creation until the navigation
   has ended?
   - Yoav: The early creation enables folks to migrate from NavTiming L1
   which reported things as they?


   - Possibility to get the HTTP status code from the Response Header
   - Yoav: We also have a feature request for this for ResourceTiming
   - Yoav: Non-actionable for the moment
   - Nicolás: Why not actionable?
   - Yoav: We could make it a feature request for L3. NEL may resolve the
   use cases
   - Nic: NEL gives you an out-of-band signal, but doesn’t enable you to
   correlate RUM with it
   - Yoav: So there’s a case to be able to tell apart your 200s from your
   - Nic: Akamai customers are using that, and we’re routing the status
   codes through the HTML to expose it.
   - …: It’s hard to tie NEL with the rest of your data: session ID, etc.
   RUM is easier.
   - Yoav: Also, NavigationTiming has no opt-in issues
   - Nic: AI to add Akamai use-case to Github issue
   - Yoav: OK, so we can label it as a feature request for L3



   - Allow performance.measure() to specify optional color parameter, to be
   used by perf visualizations in devtools
   - Yoav: Request to send colors along with marks/measures for use in
   developer tools. Feels overly specific.
   - Michal: We could look at how the console handles coloring.  Maybe
   could be a part of the details object that's a convention per browser.
   - Yoav: Agree that it seems like a better way to tackle this. Might be
   interesting to loop in devtools folks.
   - Michal: Console API accepts CSS properties, with a whitelisted set of
   properties they can specify


   - Allow marks and measures to be shown in developer tooling without
   adding it to the performance timeline
   - Annie: Ideally these would be handled by the developer tooling folks.
   There was also an issue around UserTiming slowness in Chromium that is also
   conflated here.
   - Nicolás: I don’t get how would these entries be created in developer
   tooling but not remain in memory
   - Yoav: console calls might not do much when dev tools are closed, but
   not sure this is true
   - Nicolás: Feels like they want a "debug mode" for their profiling which
   could be something they handle instead of building it into UserTiming
   - Annie: They get that today by turning marks and measures on and the
   - Yoav: This might be better handled in user-land. I’ll loop in the
   devtools folks.

On Tue, May 19, 2020 at 12:00 AM Yoav Weiss <> wrote:

> Hey all,
> Let's talk <> webperf tomorrow!
> On the agenda
> <>,
> we have a bunch of issues to discuss for Resource Timing, Performance
> Timeline, Navigation Timing and User Timing. But beyond that, I'd love to
> discuss the different information *types* that Resource Timing exposes
> and the various opt-ins that this information is currently barred behind,
> and what that should look like in the future.
> As always, the call will be recorded and posted online.
> Cheers :)
> Yoav

Received on Friday, 29 May 2020 08:48:53 UTC