#667: Same-origin prerendering triggered by speculationrules

Visit on Github.

Opened Aug 16, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of same-origin prerendereing triggered by speculationrules.

This feature is about the specific case of same-origin prerendering triggered by the speculation rules API.

This feature enables authors to provide a hint to the browser to prerender a URL, so the end-user can experience a near-instantaneous page load if that URL is visited.

Further details:

  • ✅ I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG (future)
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: n/a
  • Major unresolved issues with or opposition to this design: none known
  • This work is being funded by: Google

You should also know that...

This feature is related to #611 in that it is a specific case of that triggering mechanism.

It is also related to #613, which is a particular API exposed by this feature.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Discussions

2021-09-20

Minutes

Dan: we fed back what's going on because Speculation Rules themselves are sitting in some private repo and looks like there's not consensus on them to begin with. I mentioned this to Chris H and he said he'll progress it. Nothing happened yet.

Sangwhan: seems like it's driven by people in Tokyo and it's a holiday in Tokyo this week

Sangwhan: a lot of web sites do click tracking - don't know how they plan to address this - sure they've thought about it. The concern I have is that this can trigger false clicks because the click tracking works via a rediretc. The prefetch will hit the redirect which will log a click that didn't happen. That's worth thinking about. Prefetch will destroy all of it.

Amy: I asked about that for the first speculation rules issue - response was that there's a prefetch header - but that means there would need to be code updates.

Sangwhan: won't work

Amy: other response was that prefetch doesn't run JS so any JS-based analytics won't run - which is good.

Sangwhan: but for an externally tracked redirect - that would render the prefetch refresh because the page you want to fetch is gated behind the script... it's worth asking.

Amy: it may be in the speculation rules explainer, at least there's discussion about it in the issue.

Dan: there's lots of work on this, lots of contributors, and it's not in a CG, IPR policy is still unclear. Why isn't it in WICG?

Dan: leaves comment on our original issue

2021-09-27

Minutes

Amy: there's been no response to dan's comment...

Dan: I went back to the original speculation rules review (#611) and asked about the process issue. Too early to build on top. We shouldn't be progressing this review.

Amy: close too early?

Dan: prefer pending external feedback, also asked about multistakeholder

Peter: closed as too early. If it hasn't met the threshold as being included in wicg why are we spending time.

Dan: it's worse - the thing it's built on top of isn't in wicg. I don't know what the temperature check of the developer community.. what implementers generally are thinking about speculation rules.. but we can close as too early

Peter: I'd like to hear the answers to the questions, but it's way before.. Getting input from wicg is first step before you come to the TAG

Dan: [leaves closing comment]

2021-09-Gethen

Minutes

Amy: the specs its based on were closed satisfied, but were early review. This a case of a feature being built on something that is not a standard yet

Hi @mfalken - one thing to note is that Speculation Rules itself is still in a private repo. 

@jeremyroman is this indeed in WICG? Yes there has been a positive TAG review that was based on an "early review" - if this feature itself is still in incubation then maybe it's premature to start building stuff on top of?   

Regarding speculation rules, Chrome Status still shows "no signals" from other implementers or developers. Is there any multi-implemnter implementation?  Again - a lack of consensus on speculation rules itself could mean that it's premature to base other features on it.
2021-11-22

Minutes

Dan: is now in WICG [leaves comment]

[Discussion on pre-rendering and how it fits into surveilance on the network ...]

Amy: the site itself sends the signal to the browser... Then the browwser decides to act on that based on what else is going on the user's device...

Dan: reasonable answer here

Dan: are there other unintended consequences - things that might trigger even if the person does not actually visit the pre-rendered page?

Amy: they've caught that - "restrictions apply to prerendered page" "promises do not resolve" and "preventing intrusive behaviours" seems like a work in progress. "downloading resource" "user prompts" "Async apis" A list of APIs that are delayed inlcuing EME. Also a section for preventing nonsenical behaviours...

Dan: looks like they are considering the issues.

Amy: haven't seen an answer to server-side traffic monitoring. There's a javascript function to see if a page is prerendered or not but how about from a server's perspective? Case that a whole lot of server code would need to be updated -- and most of the web is not going to be updated.

2021-12-Madripoor

Minutes

Amy: they responded to question about status but they haven't responded to the issues I left in their repo.... So not sure there's anything else we can do at the moment... comment

2022-04-04

Minutes

Amy: we looked at this in the f2f.. left feedback, proposed close, no response so far

we agree to close with reservations