Benjamin De Kosnik, Steven Bougon, Tim Dresser, Nicolás Peña, Thomas Kelly, Gilles Dubuc, Todd Reifsteck, Ryosuke Niwa, Will Hawkins, Philippe Le Hegaret


Yoav Weiss


Todd Reifsteck

Next call

May 2nd, 10 am PST

Resource Timing

Specify TAO check for 304 responses

Yoav: Discussed on last call and decided to align with CORS. Anne Van Kesteren said that RFC 7234 defined that cache TAO headers should if the 304 response does not have one.

Ryosuke: What about the other 3XX Response headers?

Yoav: They are different, as they are redirects.

Ryosuke: Should we review all 3XX for proper behavior?

Yoav: The spec doesn’t require updates for these as they don’t require special behavior. The PR change to fix this is just a note.

Ryosuke: Does the redirection handling match fetch?

Yoav: Not perfectly.. If CORS crosses origins then goes back to same-origin, it requires the same-origin domain to give access to itself. TAO does not yet have this. Discussed adding to L3.

Ryosuke: Might be risky to keep it as is, sites may start to rely on current behavior.

Yoav: It has been this way for awhile, and current implementations are not all compliant, so risk is low. I’d love L2 to reflect what’s implemented.

Rniwa: If implementations need to align anyway, might as well go with the end goal spec.

Yoav: That logic relies on Fetch integration, would be easier to do after integration happened.

Todd: Seems like Ryosuke is saying this leaves a potential privacy leak in browsers if we don’t write this down in a spec.

Ryosuke: Yes, also risky for compat if sites rely on this. And don’t want implementers to implement the incorrect version.

Nicolás: Who hasn’t implemented?

Ryosuke: Talking about bug fixes to current tests.

Yoav: Safari/Firefox fail these tests. Chrome passes them. Doesn’t cause a privacy leak. This intent of making this update is to be consistent with CORS.

Todd: Why is it specified if there’s no privacy risk?

Yoav: The current definition does protect against privacy issues. The CORS-aligned behavior does not. There are no privacy risks I’m aware of that will be blocked by the origin opting-into itself in those cases.

Todd: So we’re just doing that to align with CORS?

Yoav: Yes. We want to be consistent, and want to be able to say TAO is a subset on CORS.

Ryosuke: It is risky to leave in the current state. It would be ideal if the spec/tests are updates now.

Yoav: What’s the risk.

Ryosuke: Sites will rely on it and stop getting entries once we change. It’s better to be more restrictive sooner.

Nicolás: How hard is it to add change to code/spec?

Yoav: Will Safari and Firefox align?

Ryosuke: Once we fix the tests, might as well fix to the right behavior

Todd: If Chrome has the right behavior and Safari or Firefox intend to align, Is that enough to push to CR?

Philippe: Yes. Maybe even PR, as this is an edge case.

Yoav: Will, are you willing to update the TAO behavior to be CORS-like?

Will: No immediate reason to push back, but need to review offline.

Yoav: Seems reasonable. Also, found an earlier commit that specifies this. Will make the updates.

AI: Yoav to update spec and tests. 

Resource Timing and range requests

Yoav: Image lazy loading are likely to trigger more of these. Proposal is to dupe it to issue for multi-request fetches

Ryosuke: agreed

Add tests for not-same-site nested contexts

Yoav: Nothing major to discuss. We need to add tests

Test Status

Yoav: Firefox/Safari said they will review tests and give back bugs on blocking issues. Any progress?

Ryosuke: No updates.

Will: First time I’m seeing this list.

Nicolás: Can we remove the ones that pass in two implementations?

Yoav: This list already precludes those. Can we agree that the tests are testing the right things and open implementation issues?

Will: Is the blocker for L2 the agreement on the tests, or the alignment of the implementation?

Yoav: Agreement will enable to move to CR. Maybe PR as well. Philippe?

Philippe: Depends if they are corner cases or not. Major bugs will need implementation fixes as well to move to PR.

Yoav: So tests are potentially blocking moving beyond CR.

Will: Is the agreement that the tests are testing what they are supposed to or that the product will be fixed?

Todd: Just following up with regard to timing for Firefox/Apple.

Will: Unsure on time commitment for test review. Maybe > 4 weeks

Ryosuke: Can’t commit any time due to other priorities (WebComponents F2F, then WWDC). Hope to work on this, but not sure when.

High Resolution Time

can timers be frozen for background tabs, etc?

Yoav: Chrome is freezing when tabs are backgrounded. Is this a Chrome bug? I believe it is

Ryosuke: How does it work? Time is advancing slower?

Yoav: Either incrementing slower or not at all

Ryosuke:Sounds like a bug

Tim: Devil’s advocate. If we don’t pause, it causes time between 2 separate to look like a very long period of time.

Yoav: But it DID take a long time. The freeze or pageVisibility events are the best way to understand this.

Ryosuke: Can we pause mid-function if it’s not async?

Tim: Maybe if the computer is put to sleep. Not sure if this happens and in which cases.

Todd: Edge took the position that should not be frozen as far back as Windows 8.

Ryosuke: that’s what Safari does too.

Will: Is there a test that Firefox could use to double-check their behavior?

Yoav: No WPT, but there’s a JSFiddle attached to the issue that can help testing

Nicolás: Does spec need to refer to sleeping PC to ensure doesn’t stop?

Yoav: Probably a note.. And manual testing

Todd: Useful for each browser to run the manual test to confirm sleep and background behavior

Gate Timestamps behind existing permission prompts

Yoav: *summarize the issue*

Would like to close as this is a significant change to a widely used web standard, with no implementer support

Ryosuke: Probably not the best way to approach this. So many other timers exist.

Yoav: Many other mitigations that make an impact. COOP, CORP, CORB can help. Blocking coarse timers won’t help.

Todd: This would be a hugely breaking change to the web today.

Ryosuke: If we implemented, it would be to lock precision unless permissions. It turns out there are too many holes to plug this way.

Will: Mind keeping the issue open to poll Firefox folks till Friday?

Yoav: Sure

Find better sources to quote than Wikipedia

Yoav: Moving the strict time to ECMA reference. Needs a review of the PR

Can HR-Time be moved forward?

Yoav: Can we move this to PR?

Phillipe: We should close the privacy issues, give them a week to see if they push back, and then move forward.

Yoav: Any objections?


Todd: Sounds great!


Republish L2 based on the latest "level2" branch

Yoav: Can we republish the level2 branch as L2?

Philippe: Can do that today!

Yoav: Awesome!

Yoav: Also, all issues and tests seem to be green.

Navigation Timing

"timing allow check" is not well defined in the context of NavTiming

Yoav: Issue comment needs a review. The role of TAO for navigations seems a bit inverse, as we need to protect the previous document or redirects from the current document. This is not well defined currently.

Todd: Review by who?

Yoav: Todd/Anne/Ryosuke

Ryosuke: document can be created by script, and have no resource.

Yoav: In those cases, there’s also no previous document and no redirects. So we can just check for those cases.

Ryosuke: and treat them like TAO wasn’t provided

Yoav: Yes. And when there is a previous document, we need that document to opt-in to current origin. Same for redirects.

Ryosuke: Opting-in to the destination origin makes sense.

<out of time>