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 <bratel...@gmail.com>, +Yoav Weiss <yoavwe...@chromium.org> and +Mike Taylor <miketa...@google.com> 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 On Wed, Dec 7, 2022 at 5:31 PM Kevin McNee <mc...@chromium.org> wrote: > 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 > <https://chromium-review.googlesource.com/c/chromium/src/+/4086682> > 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 <https://chromestatus.com/feature/4694585584910336>. > > On Tuesday, December 6, 2022 at 8:37:56 p.m. UTC-5 Jeremy Roman wrote: > >> *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 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/cY68NkAqREg/m/tCgJaCKbAwAJ>), >> 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. :) >> >> On Tue, Dec 6, 2022 at 2:23 PM Kevin McNee <mc...@chromium.org> wrote: >> >>> PSA: The implementation of the acceptable referrer policy restriction, >>> mentioned previously, was overly strict. As of this CL >>> <https://chromium-review.googlesource.com/c/chromium/src/+/4077268>, it >>> only applies to cross-site prefetches. >>> >>> On Wednesday, September 28, 2022 at 10:51:46 a.m. UTC-4 Kevin McNee >>> wrote: >>> >>>> 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. >>>> >>>> [1] https://chromium-review.googlesource.com/c/chromium/src/+/3910832 >>>> [2] >>>> https://wicg.github.io/nav-speculation/prefetch.html#list-of-sufficiently-strict-speculative-navigation-referrer-policies >>>> >>>> On Thursday, May 12, 2022 at 1:36:26 p.m. UTC-4 Mike Taylor wrote: >>>> >>>>> LGTM3 >>>>> >>>>> On 5/12/22 12:29 PM, Yoav Weiss wrote: >>>>> >>>>> LGTM2 >>>>> >>>>> >>>>> On Thu, May 12, 2022 at 6:26 PM Daniel Bratell <bratel...@gmail.com> >>>>> wrote: >>>>> >>>>>> LGTM1 >>>>>> >>>>>> /Daniel >>>>>> >>>>>> >>>>>> On 2022-05-11 09:44, Yoav Weiss wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, May 10, 2022 at 8:40 PM Jeremy Roman <jbro...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On Tue, May 10, 2022 at 8:41 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman <jbro...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> jbro...@chromium.org, kenjibah...@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 >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> >>>>>>>>> >>>>>>>>> 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! >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> First is complete, second is pending. >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>> >>>>>>>> Which of the 24 issues >>>>>>>> <https://github.com/WICG/nav-speculation/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 >>>>>>> <https://github.com/WICG/nav-speculation/issues/133>, 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 <https://github.com/WICG/nav-speculation/issues/158> 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. >>>>>>> >>>>>>> >>>>>>>>> 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 >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Kpp6uJJRrqI/m/GTo_aF0qEQAJ>. >>>>>>>>> There is an ongoing early access program >>>>>>>>> <https://github.com/buettner/private-prefetch-proxy/issues/15> >>>>>>>>> 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 >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cKaJB=2gqs4n3om1esmucvoy5zxchrcv8ocykcq8k...@mail.gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> -- >>>>>>>>> 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+unsubscr...@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 >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cbVXw9nEo4zVwhGz_W65kfg0neYDqW3sMQC%2BYNzX6kfg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>> 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+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVcLV%3DpWo%2B0dbv027%3D-okgTtmQ7azCrBNsJsspmgTVByQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVcLV%3DpWo%2B0dbv027%3D-okgTtmQ7azCrBNsJsspmgTVByQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>> 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+unsubscr...@chromium.org. >>>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVLNKUNTFxFPwz_EatkxZOYO-oJwFnC%2BHBTVt4rXRtxxw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVLNKUNTFxFPwz_EatkxZOYO-oJwFnC%2BHBTVt4rXRtxxw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61c67609-3335-4fa4-8040-489d156eaf91n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8eU3h%3DiLSpUYMdfzr1dOzLsFYcDN2W8BvyrxpwX_iSAg%40mail.gmail.com.
