Heavy Ad Intervention

[johnivdel]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Heavy Ad Intervention
• Specification or proposal URL:
  • Explainer
  • HTML Spec PR: https://github.com/whatwg/html/pull/5885
  • WICG/Interventions proposal: https://github.com/WICG/interventions/issues/68
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1663203

Other information

The HTML spec PR does not spec the intervention explicitly, but adds a carve out which allows the intervention behavior.

[jesup]

bz and I (and IIRC Olli and Bas) had discussed letting pages limit the resources used by iframes within them (as opposed to the browser imposing a limit), by adding some constraints to the iframe when it's created, similar to other permission-based properties of iframes. We had considered the ability to limit CPU use and memory; we hadn't discussed network use.

Our general opinion was that this might be useful, but we had more important things to look at for performance at the time (about 1.75 years ago I think in Toronto).

[jkarlin]

Nice. Chrome has also looked into such frame-level policy limitations e.g., content size policy. We dropped it over concerns about x-origin side-channel leaks. However, for heavy ads, we can put strong limits on the number of interventions and add enough fuzzing that we're comfortable that the leak is small.

Note that we're also investigating adding memory to Heavy Ads down the road. Acquiring per-frame memory usage is a new capability for us.

[annevk]

As I noted in the PR, I think this is worth doing if the mechanism is general and can be shared across different use cases for unloading third-party documents. It's not entirely clear that is the case at the moment and the PR appears to have stalled.

[martinthomson]

@johnivdel, it's been a while since you looked at this. Is this still a going concern?

My reaction today is that this is probably not something that needs to be standardized. A user agent can choose to disable abusive content for any number of reasons. So while the reasons enumerated seem perfectly cromulent, I don't see these as being exhaustive. Or necessary to specify. Indeed, Firefox already pre-emptively disables iframe content from sites that have a history of similar forms of abuse. Does Chrome still feel like pursuing a standardized approach is worthwhole?

[annevk]

FWIW, I do think it's worth standardizing how "failure" happens. Especially if it happens after the moment you can pretend it was a network error.

[martinthomson]

That sounds right, though I think that many of these manifest as (pretend) network errors in Firefox, the sorts of interventions considered here would not fit that box. (I think having an iframe stop receiving time for processing is perfectly fine.) But that only motivates the question further.