Consistent opt-out and reporting for interventions

[RByers]

The intervention design guidelines say that interventions should be "avoidable" and "transparent". But in practice this has been pretty ad-hoc per intervention and some have done better than others.

Talking with @ojanvafai, we think we should move to a model where almost all interventions can be easily disabled (at least temporarily) by a single mechanism (such as feature policy), and their activity reported via a common API.

There are some cases where an intervention is blocking actively malicious behavior, and an opt-out won't make sense. But those are typically restricted to cross-origin iframe scenarios (eg. ads that vibrate or navigate without the user tapping the ad).

See Ojan's recent BlinkOn talk for some more context.

[ojanvafai]

There's two types of opt-out we're considering. I think we'll need to ship both and decide on a case-by-case basis which form of opt-out applies best.

1. FeaturePolicy-based opt-out. This is a permanent-ish opt-out. For some of these cases, we might remove the opt-out in the future after a significant deprecation period.
2. An OriginTrial-based opt-out. These would be temporary (e.g. 6 month) opt-outs so that web authors have breathing room in fixing their sites and/or contacting us to inform us of use cases we hadn't considered.

For cases where we can get away with only the latter, that's still probably preferred as it minimizes complexity on the platform and maximizes quality user experience.

[igrigorik]

The origin trial approach is really nice as it discourages blanket (and long-term) opt-out from bad behaviors. How would we determine which intervention goes in which bucket?

[ojanvafai]

That's a good question.

One principle I'd like to use is whether the web currently provides the APIs necessary to fix your site. For example, pausing background tabs on desktop would have to be FeaturePolicy-based since we don't provide all the APIs needed to do the sorts of behaviors users expect on desktop (e.g. syncing your email, chat notifications, etc.).

I'm not sure if there's other criteria that make sense.

[Slayer95]

An opt-out for ignoring autocomplete="off" based on a Feature Policy header sounds great.

It would be tailored to the overwhelming majority of applications where some company Staff fills in only-ever-used-once customer information.

[nolanlawson]

I like the idea of an origin trial-based opt-out, because it's not something that we potentially have to bake into the web platform for all of eternity. It can give some sites breathing room while the ecosystem adjusts (e.g. "\<Foo Framework> v1.4 breaks with the intervention, \<Site Bar> needs some time to upgrade to \<Foo Framework> v1.5 which fixes the issue").

The downside is that the origin trial has to be managed by Google, and other vendors effectively can't take advantage until the trial expires (in additional to downsides already mentioned). But it seems to me like a reasonable compromise.

[travisleithead]

This is a funny thread... we provide a feature. It gets abused. We implement a mitigation (intervention). Now folks want a way to opt-out of the intervention. :) Next we'll need a way to opt-out of the opt-out!

I suspect that it would be bad to provide a general-purpose exposed-to-everyone way to opt-out (like Feature Policy). Rather, I suspect vendors may each offer a way for developers, individuals, or even organizations to opt-out (like origin-trials), but not give the general web a pass. For the general web, rather than opt-out, they should probably just apply a best-practice or fix the original reason for the intervention. The platform generally has the tools and notifications needed.

[ojanvafai]

I haven't talked to our team about this yet, but I suspect that Chrome would be happy to share our origin trial keys with other vendors so you could at least get the same opt-outs as Chrome. That's still managed by Google in the short-term, which is obviously not ideal.

The good news is that the way authors put origin trials on their pages is not vendor specific, so any vendor could setup an origin trial system and we could all swap keys or whatnot. In the long-term, I could imagine us all moving to a managed-by-the-W3C system or something like that. Doesn't seem worth investing in until there are multiple vendors that would benefit though.

Another option is that we could use FeaturePolicy directives that we remove after N months. The downside there is that we pollute feature policy with a bunch of temporary directives and we don't get email addresses for sites that break (which helps contacting them to understand their needs better). That doesn't seem like the end of the world though.

[johannhof]

(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)

As described in #72 we have somewhat moved on from categorizing changes as "interventions" vs. "non-interventions" so it probably doesn't make sense to develop a consistent opt-out strategy anymore. However, we are trying to ensure that the lessons learned here can be helpful to future efforts in deprecating or changing existing web platform features by updating documentation and guidelines as part of the archival process.