The issue seems to be a feature request. Hence, marking it as untriaged for further inputs from dev team.

Thanks...!!

@rschoen@chromium.org

We typically call these "protective features" (at least ones that involve any sort of breaking change), "interventions".  See https://github.com/WICG/interventions/blob/master/README.md

Obviously we strive to minimize any sort of compat impact of interventions - see https://bit.ly/blink-compat, but there definitely are such cases.

It doesn't seem totally crazy to me to have a "disable interventions" option that can be set via site settings or per-site enterprise policy.  After all, we have that for pop-up blocker (one of our oldest interventions) - why not a single bucket for others?  This wouldn't necessarily apply to all interventions of course - maintaining and testing the disabled code path sometimes won't be worth the cost.

I think the main reason NOT to do this is that it reduces the motivation for fixing sites relying on bad practices. Eg. it's crazy how many sites still say "pop-up blockers must be enabled to use this site".  But I could see, this being a useful tool in smoothing over the intervention migration path.  For example, maybe most interventions would support this until at least two other major browser engines had also shipped with the change (i.e. the intervention is not really part of the design of the overall web until at least the majority of engines support it). That would still allow us to eventually delete the support for the 'disabled' path after developers could really expect consistency between Chrome and other browsers.

There would, of course, be a discoverability problem. We're certainly not going to prompt the user (like pop-up blocker does).  But at least then user forums could say "go into site settings and set interventions to disabled for this site".  We could perhaps even collect some aggregated/anonymous metrics on which sites have interventions disabled the most and work to better understand if there's something better we could do for those sites.

Moving to Internals>FeatureControl for lack of a better label.  This is definitely "intervention infrastructure".

chasej/dknox/ojan - thoughts?  

I like the idea of user opt-out in principle. I think I'd want us to:
- Have a time limit on how long we allow it for a given intervention (e.g. 12 months). This means the web doesn't need the technical debt forever, sites still have to fix themselves, and the Chrome UI doesn't need that complexity forever.
- Measure the sites that users are opting out of for a given intervention so we can find them and address them.
- (Maybe) have an opt-out per intervention so we can do better tracking of which interventions are breaking which sites.

In particular, I think it's useful in the way you suggest that sites could add help documentation while they fix themselves. It also allows users to escalate issues to us through the bug tracker, but still use critical sites in the meantime.

Why have a specific time limit instead of an interop limit like I proposed?  Eg. if all the major browsers ship it in 3 months, then I really doubt we still need the opt-out.  On the other hand, if after 5 years Chrome is the only one shipping the behavior, then we potentially screwed up and should consider undoing it - right?  I like the idea of having some pressure on us to follow through on open interventions - right now we have quite a few that are in limbo waiting for other implementor interest before we fully spec them.

Regarding opt-out per intervention, I wouldn't want us to have to add new UI for each intervention, but perhaps we could automate it somehow?  I doubt users would really reason about it though - probably just cargo-cult that turning off all interventions occasionally helps fix a broken site.

Oh, I missed the interop thing. Yeah, I just want some reasonable way of not being stuck with them forever. Although, honestly, anything longer than a year and we're unlikely to really followup, no?

Our particular use case is educational software, where communicating to large school districts midyear new policy settings changes (where IT staff is severely limited) or implementing mitigations for these "interventions"is a non-trivial effort.  Autoplay was a recent example where our digital instruction autoplays video and autoplay (a reasonable feature for an educational product) but required dedicated time to analyze and remediate during an active school year.  Having some such switch, even to buy additional time to remediate (or communicate to 1000's of understaffed schools) would be a very beneficial thing.

One this I'd also like to note, specifically with regards to "fixing sites relying on bad practices", specifically with regards to the Autoplay Policy Changes (https://developers.google.com/web/updates/2017/09/autoplay-policy-changes), is that this new protective feature affects legitimate use cases as well as bad practices. How is it considered bad practice for a website to be unable to autoplay video and audio in an iframe (served from the same domain, as part of the application), after the user has already subsequently interacted with the page and enabled autoplay in the parent window. This seems very heavy-handed, and with the decision last week to no longer implement the gesture delegation API, it seems as though this is intentionally introduce a breaking change that doesn't allow developers to opt-out (or rather enable autoplay) programmatically for legitimate use cases.

To achace:

For the scenario in #8, it sounds like a user option or enterprise policy to opt out wouldn't help much, as either require effort from schools/school district (communication vs configuration). Is that interpretation correct?

If so, would a website-controlled opt-out work? For example, sending a special HTTP header or meta tag to ask Chrome to disable the intervention?

General comments:
I think we should consider some combination of interop limit and time limit. I agree there should be some kind of forcing function on following up on interventations. If major browsers ship quickly, that could be faster than websites can reasonably make the necessary changes. Given various release cycles, is it feasible for all major browsers to ship in 3 months? I didn't think so, in which case a time-limited opt-out could be useful to allow websites to stage any implementations changes to the later of major browser shipping the intervention.

For now, marking as available because I think we should provide some kind of infrastructure for intervention opt-outs. We can continue to debate what form that should take.

The user option or enterprise policy does help, we use those today, however they frequently change and there is one per intervention feature.  The request here is for a one switch for all interventions which would vastly simplify messaging we have for our customers (one switch versus a large number) and the steps to take to remedy.

HTTP header or meta tag also would be attractive but I suspect more susceptible to abuse.  The grant by the user to disable (via a central flag / control) for a given site seems more explicit and safer in my opinion. 

What is the process to move this forward / prioritize it?