In this case it's because Chrome supports a relatively obscure use case (GPU-accelerated CSS filters on a cross-origin iframe), it's not really a bug or a vulnerability in the browser.
At the point where you're rasterizing, the distinction between same-origin and cross-origin is not necessarily present. It's possible this just works because it happened to work, and nobody ever went out of their way to implement it.
i.e. the display list for the page has some boxes for iframes, and those boxes are identical to the rasterizer regardless of what origin they're from, so it happily applies filters to all of the iframes.
You seem knowledgeable on this. Why is only chrome supporting this feature and other browsers aren’t? Was this feature pushed by the chrome team?
As for your second point, how is this not a vulnerability in the browser? The security intent is clear, a page should not be able to inspect an iframe. I can’t take a screenshot and read the pixels of the iframe. The fact the chromium supports a published standard is irrelevant. The browser exposes information it is not supposed to and is vulnerable to attack.
The intent of the css feature was not to allow reading iframe pixels. If that cannot be avoided, then the feature is insecure and any browser implementing it has a vulnerability. If it can be avoided then chrome has an insecure implementation.
I don't have any reason to believe that the Chrome team pushed for this use case specifically. In the past when I experimented with SVG filters their feature support was already very different across Trident Edge, Chrome, and Firefox, as was their implementation (hardware accelerated vs not). SVG filters are very powerful and also very slow, and not necessarily constant-time, so they're a good target if you're trying to execute a timing attack. (For whatever reason, my old JSIL project actually happened to use SVG filters to accelerate a specific use case...)
I think it would be fair to call it an oversight that Chromium allows cross-origin use of the features involved in this attack, but it doesn't really feel like a vulnerability in the traditional sense to me - everything is working as intended/specified AFAIK. It just happens to expose a timing attack. The reality is that tons of things are potential timing attacks and if every single feature that might get used for one was disabled in advance the web platform would be pretty useless.
There are various constraints you could apply to make attacks like this harder - i.e. limiting filter stacks to say 4 items, limiting use of filters cross-origin - but I find it understandable that such things didn't happen. This functionality is probably also quite old so it's possible nobody was taking timing attacks quite as seriously back then.
> The reality is that tons of things are potential timing attacks and if every single feature that might get used for one was disabled in advance the web platform would be pretty useless.
I feel like the web platform would be much more useful if I didn't have to constantly worry about drive-by attacks leveraging bugs in a giant stack of "web technologies" that are only getting more complex with each passing year.
Interesting points. However, I think the reasons are much simpler: why wouldn't you want accelerated CSS in your browser, including cross-origin iframes?
Browsers have been making use of GPUs for a long time. It's faster than the CPU and saves battery
Yes, between the device with hardware accelerated rendering and the device without, the user is likely going to prefer the former because software implementations are much slower and much more power-hungry. Thankfully SVG/CSS filters aren't used a ton on the web but usage has probably crawled up over time - I know many websites now use CSS blur filters.
