Participants
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
Issues
ResourceTiming 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, etc)
- ... 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 information
- ... 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 origins
- ... 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.
ResourceTiming
- Yoav: Mostly discussed by the above
- The step to queue a task to run fire a buffer full event should specify its source
- Yoav: Editorial, I will just do that
PerformanceTimeline
- Is the observer buffer of a PerformanceObserver a PerformanceObserverEntryList or a PerformanceEntryList?
- Yoav: Editorial, moved to Level 2
NavigationTiming
- 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 document?
- 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 500s?
- 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
UserTiming
- 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 off.
- Yoav: This might be better handled in user-land. I’ll loop in the devtools folks.