META: Are interventions really necessary?

[RByers]

In the README and linked presentation we argue for the need for interventions to place more limits on the negative user impact of ads and other 3rd party components. In particular, most of the Google web platform team believes that frustration due to these user experience issues is a big part of what has fueled the adoption of ad blockers and movement in some areas to native mobile applications, and that being vigilant on the user's behalf is essential to a healthy web ecosystem (the way the rise of pop-up blockers was in the early 2000s).

/cc @ojanvafai @KenjiBaheux to correct me if any of the above is inaccurate.

But this is certainly far from uncontroversial and open to debate, and a healthy thing to be debated in this forum. Let's use this issue to share links, data and other arguments on the meta issue of whether "interventions" should even be a thing.

Since this is a complex topic with decades of history, I'd suggest that links to other thoughtfully written documents/presentations (like those above) will be more effective in structuring the debate here than long-winded dialog (which I'm sure could quickly expand into a massive conversation thread few people will bother to read). But this is a public un-moderated forum, so all (respectful) comments are welcome.

[RByers]

One thing I think we can all agree on is that there are still opportunities we should pursue to substantially reduce the pain caused by interventions. See #44 for a couple ideas.

[RByers]

@rjgotten suggests having a browser-defined whitelist of sites to opt-in to interventions. That's an interesting idea. We've strongly opposed white-lists for beneficial behavior as we don't want to disadvantage the long tail of small sites relative to the most popular sites. But maybe the inverse (disadvantaging popular sites) is tolerable? The white-list would have to be fairly large and not granular (eg. origins not individual pages). This could be really confusing for developers - eg. their site works fine in their staging environment but breaks as soon as it's deployed to their main domain. And, for Chrome, we'd want to be extremely transparent about how the list is constructed and how to get off it (eg. once a release we could crawl the home pages of the top 1M sites on a low-end phone and record the origins who don't meet the RAIL performance guidelines). Given how long the long tail of the web is, the benefit would be limited and so couldn't apply to all interventions (eg. we couldn't prevent vibrating ads this way). But still, may be worth considering? @tdresser

[tdresser]

If we have a consistent opt out, I'm inclined to think the whitelist approach is going to cause more confusion than it solves, for the reasons you've mentioned above. Having site behavior potentially change drastically due to minor performance changes, aligned to Chrome releases, forces developers to be extremely vigilant about regular testing.

The opt-out approach should be easy for authors to implement and reason about.

[TheLarkInn]

After reviewing some of the commentary and discussion in regards to passive event listeners and the new opt out functionality, I believe that there maybe it would be beneficial to create an agreed upon threshold or ratio for when a breaking change/intervention is acceptable.

For example if data suggests that an intervention would only break 10% of existing websites, then it is "justifiable break" for the betterment of the 90% who see significant performance increases.

[patrickkettner]

In a somewhat similar vein, IE and Edge have the concept of the CV (compat view) list, which would cause certain sites to be forced rendered in specific versions of IE (or just IE in general, in the case of Edge). It can greatly ease user issues with broken websites, but it can be difficult to manage and greatly reduce the pressure on developers to update.

Having a whitelist of sorts can work, we do see movement in the sites on the list. But without timelines and/or constant pestering to get folks off the list, the effectiveness is greatly reduced.

I am a big fan of the work ojan and rick are doing, and have yet to disagree with any of the choices that have been made.

[rektide]

What really makes me super sad about interventions is that they are limiting so many creative uses of the web.

If I want to create a social application like Friend Finder on the web, where I can geolocate my friends on demand, previously I could create a web application & have me & my friends leave it running, & have the server tell various friends to geolocate on demand as I ask for them.

Now this is impossible (as of Chrome 64). Now I HAVE to build a mobile application, on each & every platform. Because now, like an ever increasing amount of the web, there is a User Gesture Required, and my website is not afforded respect or autonomy to try to use the APIs available.

This is a critical, & tragic, & awful clusterfuck of a disaster up for the web, both in terms of stuff already built but even more so with regards to trying to make the web a competitive & interesting & rich platform where innovation can happen & new things can be developed. This is setting the clock back decades on the future, with no sign of recovery. It is an absolute shitshow, & the prevailing winds seem to be to lock down more & more, to basically make all new capabilities have this monstrous limitation.

I'm not opposed to interventions. I'm adamantly opposed to the strict, absoluteist application of them. We need some way to loosen things up, some way to allow applications to a more creative, open space to play in. We need a more trusted operation mode, where this insane Fear Uncertainty & Doubt paranoia worms that have eatten everyone's brains out can be turned down & de-fanged some, & where a creative, interesting web is again possible.

[Seirdy]

On the other hand, the popularity of browser extensions that exist solely to globally alter and restrict page behavior indicates that perhaps users do want some intervention. Content filtering and website themes come to mind.

Websites should be robust enough to handle difficult-to-predict alteration, as this flexibility was part of Web content standards from the beginning.

[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)

I think the past years have shown that browser interventions play an important role in improving the user experience on the web and that there is enough interest from user agents to make these changes, but with #72 we've arrived at the conclusion that the interventions repository itself (vs. evolving the web platform directly through the respective standards venues) might be somewhat unnecessary now.