jbr...@chromium.org, kenji...@chromium.org
https://github.com/jeremyroman/alternate-loading-modes/blob/main/triggers.md
https://jeremyroman.github.io/alternate-loading-modes/#speculation-rules
Speculation Rules is a flexible syntax for defining what outgoing links are eligible to be prepared speculatively before navigation. It enables access to additional enhancements, such as use of a private prefetch proxy, where applicable.
Participants in this trial can use this syntax to request prefetching of links they expect the user is likely to visit next.
This experiment is for a limited subset of the eventual behavior we envision for speculation rules, to test if they are useful for partners. The limitations are:
We only process rules being added; removal of rule sets is presently ignored.
We only accept "prefetch_with_subresources" rules. (We envision supporting other actions in the future.)
We only accept list rules. (Eventually we envision also supporting document rules based on selectors and/or URL patterns.)
We only accept same-origin URLs and do not follow redirects, except in the case of "anonymous-client-ip-when-cross-origin" noted below.
For the purpose of experimentation, rules which require "anonymous-client-ip-when-cross-origin" are accepted only from certain allow-listed Google origins (which are allowed to use Google's private prefetch proxy), and used only when it is enabled in Chrome. (We envision making this feature available to all origins in the future. See below for more details.)
We intend to provide more detailed documentation for both authors who would like to use this feature and site operators who would like to control the behavior of the private prefetch proxy.
We would like to run this experiment from M92 to M94 (inclusive).
In the short term, for reasons explained in the next paragraph, a single partner (a Google property) would be granted experimental access beginning in M91 (through the experiment period mentioned above, enabled retroactively using Finch) in order to experiment with the "anonymous-client-ip-when-cross-origin" option. We expect to gather some earlier feedback about the API and data about the potential benefits to the user experience, which will help give us better direction as we continue to develop this feature.
Because these navigations originate on a Google property, the Google private prefetch proxy, which Chrome uses to anonymize the client IP address, only serves encrypted requests which are already known to Google. Assuming that this experiment confirms that the user experience is greatly improved, we'd like to explore making this capability available more broadly. As such, we would like to proactively discuss with the community a proposal for a trust and opt-in model which would allow more origins leverage IP anonymization for prefetch traffic. If that sounds interesting to you, please voice your interest and share your thoughts or questions on the proposal.
https://github.com/w3ctag/design-reviews/issues/611
Pending
Gecko: No signal
WebKit: No signal
Web developers: Past success with <link rel=prefetch> and libraries like QuickLink, and discussion with some partners suggests interest in this space.
To gather feedback about the convenience of the Speculation Rules syntax, and to gather data about performance improvements for navigations that are prefetched, directly and via a private prefetch proxy (subject to the limitations mentioned above).
No significant technical constraints anticipated.
Chrome for Android (non-WebView) only, at present.
Eventually other platforms will be supported.
Not yet, but we have plans to.
The origin trial feature name will be SpeculationRulesPrefetch.
(This will require a cherry-pick to rename the origin trial feature in M91, which has already branched from main.)
https://bugs.chromium.org/p/chromium/issues/detail?id=1173646
https://chromestatus.com/feature/5740655424831488
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/1q7Fp3zpjgQ
Jeremy, thanks for the heads-up. I've a few questions:
Before the experiment is started, is it possible to address the concerns already raised by the community at https://github.com/buettner/private-prefetch-proxy/issues/7? Providing a side-channel to Google (and only Google) that enables it to learn users’ browsing history even though the user has explicitly opted-out of sync seems undesirable. Is it possible to avoid building this side-channel to be consistent with Chrome’s plans to actively clamp up the use of similar APIs by non-Google websites via privacy sandbox techniques?
Are there any bounds on how many links would be prefetched by the Google properties? I’m concerned that there are no incentives for Google properties to minimize the overhead of prefetching. Normally, that would not be a problem but in this case all the costs for prefetching are paid by the web developer and none by the initiator (aka Google properties). These costs include:
Paying for extra bandwidth and computation costs. It’s incorrect to assume that by default all web developers are willing to pay higher infrastructure costs.
Exposing the web server to significantly more abuse traffic that they have no visibility into due to misleading source IP addresses.
Risk of serving wrong geolocated content to the users and annoying them. This includes serving personalized content based on user’s location (e.g., which country and province the user is located in)
Serving content in the wrong language because of the misleading IP address which may appear to come from a different country or province. This is not a niche case. E.g., even google.com serves search results in different language based on the user's location (and not accept-language header), and again the languages can vary at the province level.
Incorrectly serving other geolocated content to users which may not be otherwise available to them due to licensing restrictions.
As part of this experiment, would it be possible to measure how many sites would be negatively affected by this?
In the detailed explanation there is a passage that mentions using user's past activity to speculate on which resources to pre-cache.I think this will be introducing a new side channel that would leak information on user history.If this is implemented already we should disable it or at least implement mitigations for it, if it is not we'd have to find a way to protect the user history from being probed this way.
Sorry for the slow reply! Most of the team was out Fri - Mon (the latter being a US holiday).
Jeremy, thanks for the heads-up. I've a few questions:
Before the experiment is started, is it possible to address the concerns already raised by the community at https://github.com/buettner/private-prefetch-proxy/issues/7? Providing a side-channel to Google (and only Google) that enables it to learn users’ browsing history even though the user has explicitly opted-out of sync seems undesirable. Is it possible to avoid building this side-channel to be consistent with Chrome’s plans to actively clamp up the use of similar APIs by non-Google websites via privacy sandbox techniques?
Yes, we’ll add an update on that thread with details for the experiment. Note that we do not join proxy logs with other data linked to your Google account. But before a full launch, we will address the issue in more depth.
In case it’s not clear, the concern is that doing an uncredentialed prefetch when the user has a cookie (and the response can’t be used) consumes user and publisher network bandwidth but does not provide any performance benefit to the user. From our experiment, we’ll better understand the trade-off between performance improvement and network cost, which will help us design a solution to mitigate the potential side-channel. E.g., if the added overhead is small, we can just always make the extra prefetches. If that would negatively impact user experience, we’ll need to design something more clever -- e.g., consider if the user has Sync enabled.
Are there any bounds on how many links would be prefetched by the Google properties? I’m concerned that there are no incentives for Google properties to minimize the overhead of prefetching. Normally, that would not be a problem but in this case all the costs for prefetching are paid by the web developer and none by the initiator (aka Google properties). These costs include:
Yes, there are bounds on how many links will be prefetched by Chrome. The incentive for Chrome is to protect Chrome users and publishers from large bandwidth increases, and more generally wasting bytes on prefetches that won't improve performance.
We expect to learn a lot more about these trade-offs during the course of our experiment.
Paying for extra bandwidth and computation costs. It’s incorrect to assume that by default all web developers are willing to pay higher infrastructure costs.
Exposing the web server to significantly more abuse traffic that they have no visibility into due to misleading source IP addresses.
Note that the proxy IP addresses map back to a Google domain via reverse DNS, and publishers can control traffic to their site by adding a traffic-advice file.
Risk of serving wrong geolocated content to the users and annoying them. This includes serving personalized content based on user’s location (e.g., which country and province the user is located in)
Serving content in the wrong language because of the misleading IP address which may appear to come from a different country or province. This is not a niche case. E.g., even google.com serves search results in different language based on the user's location (and not accept-language header), and again the languages can vary at the province level.
Incorrectly serving other geolocated content to users which may not be otherwise available to them due to licensing restrictions.
The proxy attempts to fetch from an IP as close to the user as possible. There may be sites that will experience geolocation issues on a small fraction of their page loads during the experiment, but if the user refreshes the page the site will load using the user’s IP. We will be tracking refresh rates and other signals closely during our experiment to detect these sites. With respect to geo-restricted content, note that images and video are not eligible for prefetching.
As part of this experiment, would it be possible to measure how many sites would be negatively affected by this?
We will track refresh rates and other metrics to understand the impact on both users and web developers. We would greatly appreciate feedback from publishers that think they may be impacted.
Sorry for the slow reply! Most of the team was out Fri - Mon (the latter being a US holiday).
On Thursday, May 27, 2021 at 12:10:40 PM UTC-7 privac...@gmail.com wrote:Jeremy, thanks for the heads-up. I've a few questions:
Before the experiment is started, is it possible to address the concerns already raised by the community at https://github.com/buettner/private-prefetch-proxy/issues/7? Providing a side-channel to Google (and only Google) that enables it to learn users’ browsing history even though the user has explicitly opted-out of sync seems undesirable. Is it possible to avoid building this side-channel to be consistent with Chrome’s plans to actively clamp up the use of similar APIs by non-Google websites via privacy sandbox techniques?
Yes, we’ll add an update on that thread with details for the experiment. Note that we do not join proxy logs with other data linked to your Google account. But before a full launch, we will address the issue in more depth.
In case it’s not clear, the concern is that doing an uncredentialed prefetch when the user has a cookie (and the response can’t be used) consumes user and publisher network bandwidth but does not provide any performance benefit to the user. From our experiment, we’ll better understand the trade-off between performance improvement and network cost, which will help us design a solution to mitigate the potential side-channel. E.g., if the added overhead is small, we can just always make the extra prefetches. If that would negatively impact user experience, we’ll need to design something more clever -- e.g., consider if the user has Sync enabled.
Are there any bounds on how many links would be prefetched by the Google properties? I’m concerned that there are no incentives for Google properties to minimize the overhead of prefetching. Normally, that would not be a problem but in this case all the costs for prefetching are paid by the web developer and none by the initiator (aka Google properties). These costs include:
Yes, there are bounds on how many links will be prefetched by Chrome. The incentive for Chrome is to protect Chrome users and publishers from large bandwidth increases, and more generally wasting bytes on prefetches that won't improve performance.
--
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/c146b31c-05c6-4bb4-92e8-59a48b3520e4n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d06114a1-16f1-4e08-93f0-69e26c5ff904n%40chromium.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/CACuR13dCOw61Wnii8F7aR6mLBycnpS8pp3g37D4-aGU2OKQzmQ%40mail.gmail.com.
The Intent* email template includes a “Debuggability” section, which is missing in this case. How will web developers be able to debug this new functionality through DevTools? See https://goo.gle/devtools-checklist for context.
Are these warning messages emitted to the DevTools console? This is an anti-pattern we are trying to limit. If the warning is something developers should act on, we should implement it as a warning in the Issues panel.
Anecdotally I've seldom noticed the issues tab being somewhere I look when my feature actively isn't working
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.