#667: Same-origin prerendering triggered by speculationrules
Discussions
Comment by @kenchris Aug 17, 2021 (See Github)
The "speculation rules API." URL doesn't work for me
Comment by @cynthia Aug 17, 2021 (See Github)
I think it is this: https://github.com/jeremyroman/alternate-loading-modes/blob/main/triggers.md
Comment by @mfalken Aug 17, 2021 (See Github)
Apologies, fixed, thanks.
Discussed
Sep 1, 2021 (See Github)
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?
Discussed
Sep 1, 2021 (See Github)
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]
Discussed
Sep 1, 2021 (See Github)
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.
Comment by @torgo Sep 16, 2021 (See Github)
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-implementer activity? Again - a lack of consensus on speculation rules itself could mean that it's premature to base other features on it.
Comment by @torgo Sep 27, 2021 (See Github)
We discussed it today and we've agreed it's premature for us to be reviewing this due to the status of speculation rules itself... Please can you request for the issue to be reopened when things have moved on a bit?
Discussed
Nov 1, 2021 (See Github)
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: 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.
Comment by @torgo Nov 23, 2021 (See Github)
@mfalken great to see that Speculation Rules itself has moved into WICG - that's progress. However, Chromestatus still shows "no signal" for Safari, Firefox and also for developer feedback. Can you provide any further info?
Comment by @jeremyroman Nov 23, 2021 (See Github)
@nyaxt @nhiroki should probably be the contacts for this on the Chromium side going forward (@mfalken is working on other projects now).
On the Speculation Rules side, we've received encouraging feedback for the overall effort in WICG/proposals#2 leading to the WICG/nav-speculation being created. Formal signals from Safari and Firefox in Chrome Status is generally populated by using their respective processes (webkit-dev, mozilla/standards-positions) and we're working on some updates before requesting those (along with other steps in standards-space).
Comment by @nhiroki Nov 24, 2021 (See Github)
Thank you for mentioning us. Yes, @nyaxt and I are the new contacts of the Chromium impl.
Comment by @torgo Nov 24, 2021 (See Github)
Hi @nhiroki thanks for letting us know - can you give an update on the status?
Comment by @nhiroki Nov 29, 2021 (See Github)
@torgo Chromium has already implemented the feature behind the runtime flag. We started Origin Trial from Chrome 94 (explainer) and will collect feedback from participants. In addition, we started upstreaming tests to the WPT repository.
Discussed
Dec 1, 2021 (See Github)
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
Comment by @rhiaro Dec 7, 2021 (See Github)
Hi @nhiroki, we're looking at this in our virtual face-to-face today. Have you had chance to make progress on the issues I raised in our review feedback (#90)? Thanks.
Comment by @yoavweiss Jan 18, 2022 (See Github)
Have you had chance to make progress on the issues I raised in our review feedback (#90)?
Drive-by question: Is this the right issue? Naively, it seems unrelated..
Comment by @yoavweiss Jan 19, 2022 (See Github)
NM, Found the issue is https://github.com/WICG/nav-speculation/issues/90
Comment by @torgo Mar 2, 2022 (See Github)
We will review the status of the 4 closed issues and decide whether to close this at the upcoming f2f.
Comment by @rhiaro Mar 25, 2022 (See Github)
We reviewed the six issues spun out from the TAG review at our face-to-face this week, and appreciate the thoughtful responses. We are happy to see this work move forward, with a few notes:
- We look forward to reviewing a completed Security & Privacy Considerations section including mitigations, in the future. (In particular, regarding your note in the questionnaire: "But the user agent's heuristics deciding whether to honor a prerender hint can potentially leak information.")
- We would like to see UA heuristics for prerendering developed publicly or even better in a standardised/normative way as a mitigation for some of the privacy concerns raised, or to discourage practices that may have a negative impact on end user control and choice.
- I would like to reopen #101 - I've left a comment to clarify my question, but this isn't blocking.
Discussed
Apr 1, 2022 (See Github)
Amy: we looked at this in the f2f.. left feedback, proposed close, no response so far
we agree to close with reservations
Comment by @rhiaro Apr 4, 2022 (See Github)
Hi @mfalken, @jeremyroman, @KenjiBaheux, just following up on my previous comment. Would you mind reopening issue 101? Thanks!
OpenedAug 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:
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