Intent to Ship: Speculation Rules (Prefetch)

530 views
Skip to first unread message

Jeremy Roman

unread,
Apr 13, 2022, 6:36:07 PM4/13/22
to blink-dev

Contact emails

jbr...@chromium.org, kenji...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html

https://wicg.github.io/nav-speculation/prefetch.html


Summary

Flexible syntax for defining what outgoing links are eligible to be prepared speculatively before navigation. Enables access to additional enhancements, such as use of a private prefetch proxy, where applicable.


This is limited to the "prefetch" action, and does not include "prerender". The Chrome setting (extended preloading) which allows any site to request use of the private prefetch proxy and was previously mentioned on intents for this feature, is currently disabled for policy reasons but can be exposed via Finch as part of a launch, if approved.


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/611 https://github.com/w3ctag/design-reviews/issues/721


TAG review status

First is complete, second is pending.


Risks



Interoperability and Compatibility



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/620)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2022-March/032158.html)


Web developers: Some positive signal from a developer using the feature, and from a developer operating a site that is prefetched using this feature.


Other signals:


WebView Application Risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

Limited, though fixing crbug.com/1315706 should provide basic insight and I'm not aware of anything that would preclude us from adding more sophisticated developer tools integration in the future.


Is this feature fully tested by web-platform-tests?

Tests are being landed at speculation-rules/prefetch/ in the WPT directory. We are continuing to work on adding more, though coverage in some areas will require the completion of some ongoing refactoring and additional test integration.


Flag name

The origin trial name is SpeculationRulesPrefetch. Some code internally calls this SpeculationRulesPrefetchProxy, but is not limited to proxied prefetches exclusively.


Requires code in //chrome?

Some code exists in chrome/, but refactoring work is underway to migrate as much of this as reasonable to content/. Some code specific to, e.g., the specific Google proxy service, will remain in chrome/.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1173646


Estimated milestones

M103 (Android)


Since the current origin trial ends after M101, we would like to extend the experiment until shipping and request a gapless launch.


I believe a gapless launch is justified here. The speculation rules API has been used by developers as part of this launch and the prerendering experiment. There is an ongoing early access program for publishers to opt in to receiving IP-obscured traffic enabled by this feature, and have received positive feedback about this program – which is planned to launch by default in coordination with this web platform side launch. Enforcing a gap here would interrupt this and require the private prefetch proxy team to notify affected partners (who are receiving prefetch traffic, rather than being direct users of this API), for no known benefit in this case.


Shipping on desktop is not possible at this point due to extensions. We expect to file a separate Intent to Ship in the future.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5740655424831488


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/1q7Fp3zpjgQ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Cw-hOjT47qI/m/EObn9-4MAgAJ

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cKaJB%3D2GQS4N3om1eSmuCVOY5zXchRCV8oCYkcq8kH0g%40mail.gmail.com



This intent message was generated by Chrome Platform Status.

Theodore Olsauskas-Warren

unread,
Apr 19, 2022, 6:54:24 AM4/19/22
to blink-dev, jbr...@chromium.org
Hi Team,

Have there been any changes since the conclusion of the previous experiment?

Thanks,

Theo.

Jeremy Roman

unread,
Apr 21, 2022, 6:33:58 PM4/21/22
to Theodore Olsauskas-Warren, blink-dev
On Tue, Apr 19, 2022 at 6:54 AM Theodore Olsauskas-Warren <sau...@google.com> wrote:
Hi Team,

Have there been any changes since the conclusion of the previous experiment?

There have been some bug fixes and tweaks on the margins, but the API surface hasn't changed substantially since the previous experiment.

Yoav Weiss

unread,
May 10, 2022, 8:41:50 AM5/10/22
to Jeremy Roman, blink-dev
On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman <jbr...@chromium.org> wrote:

Contact emails

jbr...@chromium.org, kenji...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html

https://wicg.github.io/nav-speculation/prefetch.html


Summary

Flexible syntax for defining what outgoing links are eligible to be prepared speculatively before navigation. Enables access to additional enhancements, such as use of a private prefetch proxy, where applicable.


So IIUC, this intent is for shipping cross-origin prefetch? Where have y'all landed on the question of cache partitioning? Which partition is storing this prefetched resource?
 

This is limited to the "prefetch" action, and does not include "prerender". The Chrome setting (extended preloading) which allows any site to request use of the private prefetch proxy and was previously mentioned on intents for this feature, is currently disabled for policy reasons but can be exposed via Finch as part of a launch, if approved.


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/611 https://github.com/w3ctag/design-reviews/issues/721


https://github.com/WICG/nav-speculation/issues/160 which seems like something we'd want to resolve before shipping.
Are y'all considering this new syntax?
Would it make sense to run this by your OT participants and/or partners? Web developers in general?
 

TAG review status

First is complete, second is pending.


Risks



Interoperability and Compatibility


Which of the 24 issues open on the repo is relevant for this intent? Can you highlight those that may impact future compat and interop?
 


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/620)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2022-March/032158.html)


Web developers: Some positive signal from a developer using the feature, and from a developer operating a site that is prefetched using this feature.


It'd be good to externalize such feedback if at all possible. Any links?
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cbVXw9nEo4zVwhGz_W65kfg0neYDqW3sMQC%2BYNzX6kfg%40mail.gmail.com.

Jeremy Roman

unread,
May 10, 2022, 2:40:09 PM5/10/22
to Yoav Weiss, blink-dev
On Tue, May 10, 2022 at 8:41 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman <jbr...@chromium.org> wrote:

Contact emails

jbr...@chromium.org, kenji...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html

https://wicg.github.io/nav-speculation/prefetch.html


Summary

Flexible syntax for defining what outgoing links are eligible to be prepared speculatively before navigation. Enables access to additional enhancements, such as use of a private prefetch proxy, where applicable.


So IIUC, this intent is for shipping cross-origin prefetch? Where have y'all landed on the question of cache partitioning? Which partition is storing this prefetched resource?

It is isolated from any existing cache partition, and if the user does not then navigate to the prefetched resource it is not stored further.

This is limited to the "prefetch" action, and does not include "prerender". The Chrome setting (extended preloading) which allows any site to request use of the private prefetch proxy and was previously mentioned on intents for this feature, is currently disabled for policy reasons but can be exposed via Finch as part of a launch, if approved.


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/611 https://github.com/w3ctag/design-reviews/issues/721


https://github.com/WICG/nav-speculation/issues/160 which seems like something we'd want to resolve before shipping.
Are y'all considering this new syntax?
Would it make sense to run this by your OT participants and/or partners? Web developers in general?

The reason I don't think so is that this intent includes only more basic rules which supply a list of URLs, and extending the syntax to allow developers to select URLs from the links in the page is a future enhancement, albeit one I'm personally excited about. I don't expect that choices about how to express such selectors to cause compatibility issues with plain list-of-URLs rules.


TAG review status

First is complete, second is pending.


Risks



Interoperability and Compatibility


Which of the 24 issues open on the repo is relevant for this intent? Can you highlight those that may impact future compat and interop?

It's intended that such issues be labelled with speculation-rules or prefetch (indicating they affect one of the two pieces this would ship) and affects-compat. At the moment, the only such issue is this one, which I believe is resolved as to prefetch. Looking again, any followup discussion (e.g. regarding subresources in prerenders) fit better in another issue, so I've closed that one.

This issue is not so labelled, though it's marginal and arguably could be. There is some ongoing discussion (which might become a whatwg/html issue shortly) connected to it about when user agents should observe modification and removal. While I would like to resolve this shortly, I expect the practical change to be relatively small and if anything in the direction of providing somewhat stronger guarantees rather than weaker ones.

Most of the issues are with respect to either other features or enhancements which are likely to evolve in a way that is compatible with this.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/620)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2022-March/032158.html)


Web developers: Some positive signal from a developer using the feature, and from a developer operating a site that is prefetched using this feature.


It'd be good to externalize such feedback if at all possible. Any links?

I'll ask.

Yoav Weiss

unread,
May 11, 2022, 3:45:18 AM5/11/22
to Jeremy Roman, blink-dev
On Tue, May 10, 2022 at 8:40 PM Jeremy Roman <jbr...@chromium.org> wrote:
On Tue, May 10, 2022 at 8:41 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman <jbr...@chromium.org> wrote:

Contact emails

jbr...@chromium.org, kenji...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html

https://wicg.github.io/nav-speculation/prefetch.html


Summary

Flexible syntax for defining what outgoing links are eligible to be prepared speculatively before navigation. Enables access to additional enhancements, such as use of a private prefetch proxy, where applicable.


So IIUC, this intent is for shipping cross-origin prefetch? Where have y'all landed on the question of cache partitioning? Which partition is storing this prefetched resource?

It is isolated from any existing cache partition, and if the user does not then navigate to the prefetched resource it is not stored further.

OK, thanks!
 

This is limited to the "prefetch" action, and does not include "prerender". The Chrome setting (extended preloading) which allows any site to request use of the private prefetch proxy and was previously mentioned on intents for this feature, is currently disabled for policy reasons but can be exposed via Finch as part of a launch, if approved.


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/611 https://github.com/w3ctag/design-reviews/issues/721


https://github.com/WICG/nav-speculation/issues/160 which seems like something we'd want to resolve before shipping.
Are y'all considering this new syntax?
Would it make sense to run this by your OT participants and/or partners? Web developers in general?

The reason I don't think so is that this intent includes only more basic rules which supply a list of URLs, and extending the syntax to allow developers to select URLs from the links in the page is a future enhancement, albeit one I'm personally excited about. I don't expect that choices about how to express such selectors to cause compatibility issues with plain list-of-URLs rules.

Oh, OK. Good to know!

Daniel Bratell

unread,
May 12, 2022, 12:27:00 PM5/12/22
to Yoav Weiss, Jeremy Roman, blink-dev

LGTM1

/Daniel

Yoav Weiss

unread,
May 12, 2022, 12:30:16 PM5/12/22
to Daniel Bratell, Jeremy Roman, blink-dev
LGTM2

Mike Taylor

unread,
May 12, 2022, 1:36:26 PM5/12/22
to Yoav Weiss, Daniel Bratell, Jeremy Roman, blink-dev
LGTM3

Kevin McNee

unread,
Sep 28, 2022, 10:51:46 AM9/28/22
to blink-dev, Mike Taylor, Jeremy Roman, blink-dev, Yoav Weiss, Daniel Bratell
Bug fix PSA: An upcoming change [1] will have the implementation match the spec in terms of referrer policy [2].

The prefetch request will now be sent with the referring document's referrer policy and the resulting Referer. We also apply the restriction to acceptable referrer policies. Previously, the behaviour was as if the referring document had "no-referrer" as its policy.
LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Kevin McNee

unread,
Dec 6, 2022, 2:23:07 PM12/6/22
to blink-dev, Kevin McNee, Mike Taylor, Jeremy Roman, blink-dev, Yoav Weiss, Daniel Bratell
PSA: The implementation of the acceptable referrer policy restriction, mentioned previously, was overly strict. As of this CL, it only applies to cross-site prefetches.

Jeremy Roman

unread,
Dec 6, 2022, 8:37:56 PM12/6/22
to Kevin McNee, blink-dev, Mike Taylor, Yoav Weiss, Daniel Bratell
We would like to ship this Speculation Rules (prefetch) on desktop (Windows, Mac, Linux, ChromeOS) in M110 and are seeking API owner approval to do so.

Deltas since the original approved intent (for Android) are noted below.

TAG review links are unchanged, and we're continuing to engage with TAG as they respond. We still have no signal on Mozilla and WebKit standards positions, though we can ping them again if API owners would like.

Debuggability has improved, in that prefetches now appear in the Network panel and a preloading status panel is in development.

Much of the code has migrated from //chrome to //content, and we expect this refactored code to be in use for stable users, when M110 reaches stable.

In addition, speculation rules itself has shipped on desktop as part of Prerender2 (intent to ship), so what this ships is the prefetch functionality specifically, including use of the same private prefetch proxy as is used on Android under similar rules.

I assume this requires 3xLGTM again, but if not, please advise. :)

LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Kevin McNee

unread,
Dec 7, 2022, 5:31:12 PM12/7/22
to blink-dev, Jeremy Roman, blink-dev, Mike Taylor, Yoav Weiss, Daniel Bratell, Kevin McNee
Follow up to yesterday's PSA: We're aware of a case that relied on the bug to be able to use cross-site prefetching. This CL emulates the originally shipped behaviour for cases where the prefetch attempt would be rejected by the restriction to acceptable referrer policies. Instead of treating this as a bug fix, we'll reintroduce the correct behaviour as part of the intent for the referrer_policy key feature.

LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Rick Byers

unread,
Dec 7, 2022, 6:19:11 PM12/7/22
to Kevin McNee, Mike Taylor, blink-dev, Jeremy Roman, Mike Taylor, Yoav Weiss, Daniel Bratell
It sounds to me like there is no change on the key risks evaluated by API owners, and there's no indication to me that API owner approval was limited just to Android support. I don't think we have the process well defined in cases like this, but we have other examples where API owners have approved a feature that has rolled out slowly over a similar length period. So personally I think you should consider your prior LGTMs to still hold for extending to desktop. Maybe give +Daniel Bratell, +Yoav Weiss and +Mike Taylor a day or two to object if they disagree and would like to go through a new round of formal approvals. 

From a process perspective, if we do want to do a full new round of approvals then ideally we'd have a new chromestatus entry and new thread (but that seems like an awful lot of overhead to me). Otherwise the tooling breaks -  we can't track the approvals separately, and this thread doesn't show up as something that needs action by the API owners.

Regardless, I'm supportive of extending to desktop - so you have my LGTM1 if you need it.

Rick

LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61c67609-3335-4fa4-8040-489d156eaf91n%40chromium.org.

Mike Taylor

unread,
Dec 7, 2022, 6:57:32 PM12/7/22
to Rick Byers, Kevin McNee, Mike Taylor, blink-dev, Jeremy Roman, Yoav Weiss, Daniel Bratell
I'm also supportive - LGTM2 (and no need for a new intent).

Yoav Weiss

unread,
Dec 7, 2022, 10:36:25 PM12/7/22
to Mike Taylor, Rick Byers, Kevin McNee, Mike Taylor, blink-dev, Jeremy Roman, Daniel Bratell
LGTM3

Aside: we should really define in the process that it's fine to reuse old intents for platform expansions, and ensure that our tools deal with it properly..
Reply all
Reply to author
Forward
0 new messages