Yeah, it seems like that would mitigate most of the issues. At the very least, Chrome could introduce and respect a CSP flag on the iframed site that indicates it can be iframed but not with SVG filters. That wouldn't sacrifice backward compatibility but would at least allow sites to opt out of the behavior (and into extra security protection). (And I say "Chrome," not "browsers," because it's the only browser that satisfies the three prerequisites of the attack, one of which is adding SVG filters to iframes, as described in the site/paper).

On the other hand, it would be more effective in reverse, i.e. to require iframed sites to opt-in to allowing host sites to apply SVG/CSS filters to them. Sure, this would break backward compatibility. But who cares? What is the reason for the strong attachment to SVG filters on iframes? Is this a common use case? When is it beneficial?

For the other described prerequisites of the attack, like allowing embedding iframes with third-party cookies inside them, I understand the use case (although if we're being honest this is mostly because of Google wanting to retain YouTube tracking). But SVG filters on iframes? Really?

Does anyone know the use case for cross-site CSS/SVG filters and who would need even need it?