LGTM3
On 6/30/23 9:10 PM, Rick Byers wrote:
LGTM2
In addition to Yoav's comments I'll also add that it makes sense to me
if WebKit and Gecko don't want this. They each have a lot more
flexibility in how they avoid unload handlers, and WebKit already just
doesn't fire them when they don't want to. Chromium's enterprise
customer base means we need to take a more careful and measured
approach to reducing reliance on unload handlers, and given the
positive experience we've heard from partners for this feature in OT,
I think we must ship it despite the lack of alignment with other engines.
Ideally we succeed in deprecating unload over the next few years then
we can delete this policy. The important thing for long-term Interop
risk is that the engines are aligned on wanting to deprecate unload.
We just aren't aligned on the most effective path for doing so in our
respective environments.
On Fri, Jun 30, 2023, 3:51 a.m. Yoav Weiss <yoavwe...@chromium.org> wrote:
LGTM1
On Fri, Jun 30, 2023 at 9:27 AM 'Fergal Daly' via blink-dev
<blink-dev@chromium.org> wrote:
Contact emails
fer...@chromium.org, kenjibah...@chromium.org
Explainer
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md
Specification
https://github.com/whatwg/html/pull/7915
IMO, it's fine to approve this based on this PR, even if it hasn't
landed yet, given the browser positions below.
Design docs
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md
Summary
This feature allows pages to disable the running of
unload event handlers. The goals are: - allow sites
that have removed all unload handlers to not regress
(i.e. accidentally adding new ones) - allow sites to
“remove” (skip) unload handlers (e.g. if updating the
code is infeasible, or if they have nondeterministic
chains of third parties and would rather not risk the
BFCache benefits over unload handlers in third party
code). Unload event handlers are problematic for
various reasons and prevent use of BFCache on Desktop
(see
https://web.dev/bfcache/#never-use-the-unload-event).
This is the first step to deprecating and removing
unload handlers.
Blink component
Blink>PermissionsAPI
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI>
TAG review
https://github.com/w3ctag/design-reviews/issues/738
TAG review status
Pending
Risks
Interoperability and Compatibility
3rd-party frames that rely on unload may not work as
expected when navigating away. This is solvable by the
frame authors by use of alternatives to unload and is
unlikely to impact users. See detailed discussion.
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code
/Gecko/: Negative
(https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132)
FF objects to this similar to sync-xhr and
document-domain providing a way to cause cross-origin
interference with script. Explainer addresses this
(https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code)
At a recent TPAC meeting with Mozilla people present,
no negative feedback was received. Request for formal
position is here
https://github.com/mozilla/standards-positions/issues/691
/WebKit/: Negative
(https://github.com/WebKit/standards-positions/issues/127)
Concerned that embedders gain a way to turn off a
code-path in the embedded frame.
I think it's important to continue those discussions with other
vendors and try to eventually bring them on board, but at the same
time, I agree with your position that we need to put users first.
Unload events are causing real performance harm today, and we
should at least give top-level site owners the ability to stop
that harm, even if created by their third-parties.
I haven't seen in the above discussions any concrete threats or
attacks enabled by this cross-origin interference. And as you say,
we already have similar policies around sync-XHR and document.write.
/Web developers/: Positive Private discussions with
devs are positive. Sites that have made efforts to
remove all unload handlers want to use this to prevent
accidental returns. Also some providers of 3rd-party
iframes which have content outside of their control
(e.g. ad network) want to guarantee themselves to be
unload-free.
https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1130401722
Also
positive feedback about using this to deny unload as a
source of security problems.
https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1222973324
/Other signals/: TAG review is here but has no
feedback on the API itself.
https://github.com/w3ctag/design-reviews/issues/738
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?
none known
Debuggability
When this header is present, attempts to add an unload
event handler will result in an error on the console
(just as would happen for any other Permissions Policy
violation).
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, Android,
and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
DevTrial instructions
https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/permissions-policy-unload.md
Flag name on chrome://flags
enable-experimental-web-platform-features
Finch feature name
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://crbug.com/1324111
Launch bug
https://crbug.com/1357927
Estimated milestones
Shipping on desktop 115
OriginTrial desktop last 112
OriginTrial desktop first 107
DevTrial on desktop 107
Shipping on Android 115
OriginTrial Android last 112
OriginTrial Android first 107
DevTrial on Android 107
Shipping on WebView 115
OriginTrial webView last 112
OriginTrial webView first 107
Anticipated spec changes
Open questions about a feature may be a source of
future web compat or interop issues. Please list open
issues (e.g. links to known github issues in the
project for the feature specification) whose
resolution may introduce web compat/interop risk
(e.g., changing to naming or structure of the API in a
non-backward-compatible way).
https://github.com/whatwg/html/pull/7915 although it's
unclear that we can ever spec this.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5760325231050752
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkvhEtVOkvW4iXCbMf5a84ypGjD4arZtpS%3D0Okx6BPDdQ%40mail.gmail.com
Ready
for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/38Dpu-uhwFc
Intent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkOeqfqZ0PtzUDdowXbBuMp4oYS%3DQ%2BSQCogY%2BkBpGAYXQ%40mail.gmail.com
Intent to Extend Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e69_hiyb60B9h6d88ccuoDavYnqDg89LUkgcG6iozfD8e0w%40mail.gmail.com
Intent to Ship:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e69_hiyb60B9h6d88ccuoDavYnqDg89LUkgcG6iozfD8e0w%40mail.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/CAAozHLkuNkx7%3DBfiG2wXsu%2BqqoOb-WD6YN4gxJN%2BuTogT%3DmE3A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkuNkx7%3DBfiG2wXsu%2BqqoOb-WD6YN4gxJN%2BuTogT%3DmE3A%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/CAL5BFfWCDUGeGYy42L7EbG7qyfrc%2BQJ7_mRywphyyAkg-Nv6tA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWCDUGeGYy42L7EbG7qyfrc%2BQJ7_mRywphyyAkg-Nv6tA%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/CAFUtAY9pAije6Udz3xiyz_3LakrCUCbFh8pRR-%2BhUMxwfdzXcg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9pAije6Udz3xiyz_3LakrCUCbFh8pRR-%2BhUMxwfdzXcg%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/8c37e9b8-f19f-507d-7352-b1b4caaa1fc7%40chromium.org.
