I'm also supportive - LGTM2 (and no need for a new intent).
On 12/7/22 3:18 PM, Rick Byers wrote:
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 <mailto:bratel...@gmail.com>, +Yoav Weiss
<mailto:yoavwe...@chromium.org> and +Mike Taylor
<mailto: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
<mailto:jbro...@chromium.org>,
kenjibah...@chromium.org
<mailto:kenjibah...@chromium.org>
Explainer
https://github.com/WICG/nav-speculation/blob/main/triggers.md
<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/speculation-rules.html>
https://wicg.github.io/nav-speculation/prefetch.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/611>https://github.com/w3ctag/design-reviews/issues/721
<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
<https://github.com/mozilla/standards-positions/issues/620>)
WebKit: No signal
(https://lists.webkit.org/pipermail/webkit-dev/2022-March/032158.html
<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
<https://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
<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
<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
<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
<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/3b2cf1b7-49db-cb73-5db0-87f8d22fabd1%40chromium.org.
