Participants
Yoav Weiss, Alex N. Jose, Lucas Pardue, Annie Sullivan, Refael Lebre, Michal Mocny, Nic Jansma, Dan Shappir, Pat Meenan, Amiya Gupta, Alex Christensen, Andrew Galloni, Aoyuan Zuo, Ian Clelland, Abin Paul, Philip Walton, Giacomo Zecchini, Marcel Duran, Rafael Lebre, TK(?), Mike Henninger
Admin
- Next meeting - September 1st
- 1pm EST / 10am PST
- Skipping August 18, 2022 due to holiday and slowdown in topics
- Please add issues, proposals, use-cases that are/are not covered well
- Any objections, please voice on mailing list
Minutes
Set response body info's content type to type after sniffing
Summary
- Strong preference to avoid exposing sniffing results
- No real use case for sniffing, server generated mime type seems good enough
- Preference to coalesce server provided values to a known set of valid mime types, to avoid servers leaking information to the document using cross-origin resources.
Detailed minutes
- Abin: Issue regarding Content-Type that we wanted to expose
- … Either surface the Content-Type from the server
- … or use mime-sniffing and expose that into ResourceTiming
- … Draft feedback to not expose mime-sniffing so as to not hard code that in
- … Can we just stick to what the server tells us?
- … What’s the use case for exposing the sniffed type?
- Nic: From a CDN point of view, it would be sufficient to expose the server’s responded content type. There may be some cases where knowing the browser chose to use it differently could be useful (to surface bugs).
- … At the end of the day, those would be rare, so the server’s content type would be interesting to get
- … If there are spec concerns around exposing sniffing, it’s ok to take the simple path
- Yoav: Exposing the Content-Type is easier from spec perspective
- Dan: Exposing Content-Type would be beneficial, seeing more scenarios where mismatch from type expected from URL vs. Content-Type.
- … E.g. images where the URL can be one thing and other content delivered
- Yoav: And server-provided Content-Type is good enough?
- Dan: Yes
- Amiya: If it can be an arbitrary field, could servers fingerprinting or have a unique ID sent down?
- Yoav: They can already do that with Server-Timing, providing an arbitrary string, or as part of the content
- … Don’t see any specific capability that this would provide beyond what we have
- Dan: If anything not using the server-specified Content-Type would be more susceptible to fingerprinting, if it was a client-derived value vs. what the server says
- Yoav: If there are differences in implementations, theoretically all browsers should MIME-sniff identically, but it could be used by a user-agent fingerprinting
- … You could detect browser behaving unlike what it’s advertised to be
- Lucas: Using server Content-Type is fine, ensuring reflecting omission should be possible
- Yoav: We need to specify what happens when it’s not there
- Alex: Use-case for this is to detect incorrect content types
- Nic: We have an image compression services at the CDN level, but from a RUM perspective, we only see the URL. Knowing what type of content came in would help a lot
- Dan: Wix already implemented such a mechanism, where the URL is fixed, but the image format delivered depends on the UA
- Alex: I can’t say that there are no fingerprinting concerns. May have to do some sanitized content type. We’ll deal with that as it comes.
- … “Can already do that with Server timing” is not a great argument from our perspective as we don’t yet ship Server Timing
- … I proposed we’d enable server timing and it was denied
- Yoav: Trying to understand the case, do you have some sort of server-side identifier
- … If you don’t have cookies, you can send it w/ the resource to the document, and you somehow reflect it back?
- Alex: I think so.
- Dan: Just to clarify I follow, third-party cookies are prevented, but the third-party resource sends Server-Timing information?
- Alex: Correct.
- Yoav: Could be an interesting topic for discussion at TPAC if you’re interested in discussing this further
- … But for this maybe you could keep Content-Type as a pred-efined list of options, or coalesce to a set
- Alex: Something like that. Not sure if UID could be tacked on to the end of the Content-Type field.
- Yoav: Yeah I think the primary use case is getting the class/type instead of the full field, so we could start from there.
- … I will add that Server-Timing fingerprinting stuff as a subject at TPAC if you don’t mind
- Alex: In favor of no sniffing
User Timing conventions - Annie
Recording
Summary
- Removed from spec due to lack of usage
- Seems useful, and we should try to revive it
Detailed minutes
- Annie: In UserTiming Level 1, there was a “recommended mark name” section
- … Sites could mark when fully loaded, fully visible, above the fold and time to user interaction
- … Events like Page Load didn’t fit all the cases, and we think even with Core Web Vitals there may be a lot of product-specific cases with points to track
- … The reason we’ve been looking at it in Chrome, sites would like to tell us specific points in page load where e.g. a large object is loaded they want to optimize
- … But could help with RUM, automated testing tools, etc
- Nic: Vague memory, but removed due to lack of usage
- … extremely little use, and when the spec moved to L2, it was dropped
- Annie: Did an HA study last year and 6000 sites use mark_fully_loaded
- Nic: Was always in favor of keeping them in. Not doing anything special with them due to low usage. But we would incorporate if more people use them
- Michal: One that isn’t on the list mark_time_to_interactive. TTI is a browser-defined metric, but many sites define their own “interactive” as hydration complete. A hot topic of competition. Would be interesting to see
- Dan: Contrary to that. Instead of using the same name for potentially different things, we may want a standard implementation and measurement
- Annie: Working on that, but there are still concerts that are only relevant in some pages
- Dan: Standard names without standard semantics seem problematic. Different implementations would do different things. “Naming things” without specifying what they are
- Pat: Part of that can be avoided by naming these. “Mark_site_is_useful”.
- … Not used for comparing sites, but in the context of the same site or in the browser, they can be used to spot regressions and optimize to improve those metric
- … “user engaged” or “user did something useful from a biz perspective” would enable us to correlate perf and biz metrics
- Nic: Bringing it outside of perf focus could indicate to a RUM system that something interesting happened. Understand Dan’s concern about these being undefined. As long as there are no carrots attached to that, that seems fine.
- … intentionally left vague and not comparable across sites. Useful for devtools, RUM, etc
- … The original user timing spec design foresaw everyone using those, but that didn’t happen
- … In favor of reviving those
CORS, CORP, TAO & "public static resource" metadata
Summary
- Strong preference to not override semantics of existing ACAO opt-ins, but create new ones
Detailed minutes
- https://github.com/whatwg/html/issues/8143
- Yoav: Figuring out a way to somehow bridge the gap between CORS and TAO
- … Came up in context of Content-Type changes
- … CORP enabled reading of metadata
- … Instead of trying to force metadata reading opt-in to CORP, it would be better to just have some sort of public resource opt-in that would work for CORS, and non-CORS fetches
- … Dominic proposed to simply consider ACAO: * if no credentials were sent nor set (even if the fetch itself was in no-CORS mode) it would be a public resource and would be OK to expose various details about the source, TAO opt-in, Content-Type and other bits
- … A bunch of discussion but maybe most notably Ollie on the Mozilla side is generally in favor of that idea but prefers a more explicit opt-in that would avoid changing the current semantics.
- … The adoption curve is steeper since ACAO: * is widespread
- … Advantages and disadvantages to both sides, but seem generally reasonable
- … We’re still waiting on some more opinions, but wanted to let everyone know this is happening and you can chime into the issue
- … Are there any particular objects here?
- Alex: I’m generally opposed to CORS implies ability to read timing data
- … Because timing data is not visible across-origin by default
- … And if they want to make it available via TAO, I don’t think we should add a generous interpretation of old technologies to data they did not have access to.
- Yoav: For a resource that is CORS enabled, looking beyond network data (requestStart), the rest is exposed to any origin that would fetch what that resource would fetch.
- … e.g. measure when responseStart is observable
- Alex: This is the side-channel argument and you’re correct it could be gleamed
- … But I would be opposed to exposing the information just because CORS has a * on it
- Yoav: What about a new opt-in what would imply ACAO and TAO
- Alex: Yes that means the server was updated by somebody that says “I’m allowing both”
Need a new DOM concept for user-driven events rather than using isTrusted
Summary
- Similarity to the concept of user activation, but it doesn’t take scrolls into account
- Seems like this is needed for scrolls only.
Detailed minutes
- https://github.com/w3c/largest-contentful-paint/issues/105
- Yoav: Issue regarding isTrusted attribute and one of the tests is that we’re modifying the scroll using element.scrollLeft() and this is triggering a trusted scroll event, which by spec should stop LCP entries
- … Seems like there’s a bug in Chromium where this doesn’t stop LCP
- … Not what we intended by trusted events stopping LCP entries
- … We want user scrolling to stop LCP but not what user is doing with script
- … Need a new concept in DOM spec that indicates that type of user interaction, at least for scroll events
- … Not clear if we also need this for input events
- … Having a discussion with Domenic and Noam regarding this is something that needs to be defined
- Michal: Some APIs are gated on user-interaction already, e.g. permission prompts, do they have a similar problem?
- Yoav: Not sure. User activation spec concepts, not sure if it relies on trusted events or not
- … I don’t believe scrolling is considered user activation
- … It’s a good point we can try to look into how that’s specified and piggy-back on it
- Philip: Is the use-case to point to something from LCP spec in HTML spec that is not accurate, or is the use-case to provide a web-exposed version of this behavior that someone can then measure LCP with by checking isTrusted
- Yoav: Goal is to initially properly specify LCP, as spec is not doing what we want it to do
- … If you have JS driven scrolling, that is something that is supposed to stop LCP due to the spec, but not according to the spec’s spirit
- … If there are use-cases beyond that to web-expose, that could be interesting but beyond what we had in mind here
- Philip: Is the problem in Chrome implementation or what’s specified?
- Yoav: What’s specified. Chrome does what’s intended of the spec but not that’s not well specified. Which is why it's helpful having a second implementor to point out those gaps.
- Philip: There was a point in the web-vitals JS library, we would look at scroll event not as a signal for LCP but to understand when to not look for more events
- … It was a nice feature of the library to know when to stop listening
- … If we need to better specify an algorithm for LCP that makes sense
- Yoav: Dan in the past asked for some way to know the browser is no longer listening to LCP entries, and that could be a separate event or entry.
- … Underlying concept based on isTrusted or something else, but higher level abstraction that says LCP has stopped
- Dan: I asked for that primarily so the client could send this information back to the server
- … If there’s any way to send this information earlier it increases likelihood of a RUM provider to send this data
- Michal: Exactly why we had listened to this scroll event
- Yoav: With Unload Beacon you may no longer need that
- Dan: Unload Beacon would increase likelihood to send info at the end of a session, but it’s not 100%
- Yoav: And you may want to send LCP when it’s ready or send complementary data
- Michal: I found user activation algorithm, it’s defined in terms of isTrusted, but it filters on specific event types, and I wonder if those event types in this context you can’t fire from JavaScript
- Ian: User Activation is based on isTrusted but doesn’t cover scroll events
- … pointer-up may be true on mobile devices but not desktop
- … Don’t consider page activated on scroll
- … Activation also does interesting this with frames, activating a frame activates its parent
- Yoav: Yeah wasn’t planning on tying it to it, but could be interesting to see what it’s doing
- … Good for input but not scrolling
Links:
Abin Paul7:14 PM
https://github.com/whatwg/html/pull/8139
Lucas Pardue7:19 PM
you could constrain the list to registered media types from IANA - https://www.iana.org/assignments/media-types/media-types.xhtml
Nic Jansma7:32 PM
https://github.com/whatwg/html/issues/8143
Nic Jansma7:39 PM
https://github.com/w3c/largest-contentful-paint/issues/105
Michal Mocny7:48 PM
Hmm, user activation is defined in terms of isTruster + types: https://html.spec.whatwg.org/multipage/interaction.html#activation-triggering-input-event