Primary eng (and PM) emails
ImageBitmap can contain data from cross-origin images not verified with the CORS logic. We call such ImageBitmap objects as “non-origin-clean” ImageBitmaps. ImageBitmap is serializable and transferable, but we are proposing to raise errors when web developers are trying to serialize or transfer an non-origin-clean ImageBitmap.
We are developing Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) for unblocking APIs such as memory measurement APIs. The basic idea is that we are going to “isolate” a renderer process so that resources not verified by CORS (or CORP) logic cannot enter the process. We call such a process as “cross-origin isolated” process. Non-origin-clean ImageBitmap is data we need to prevent from entering into an cross-origin isolated process.
Hence we would like to disallow serialization and transferring non-origin-clean ImageBitmap.
Interoperability and Compatibility Risk
Firefox: Supported, positive to removal
Safari: Supported, no signals
Alternative implementation suggestion for web developers
Origin-clean ImageBitmaps remain serializable and transferrable. Web developers can create an origin-clean ImageBimap by creating from an image verified with CORS.
Usage information from UseCounter
I added use-counters (NonOriginCleanImageBitmapSerialization and NonOriginCleanImageBitmapTransfer) in M79, so we have data from beta, not from stable.
So far both counters are less than 0.001% of the PageVisits counter. Here is the detailed data (sorry, for Googlers only).
Entry on the feature dashboard
Requesting approval to remove too?
We would like to unblock the memory measurement API in the future (M82 or later). But I think it’s good to remove this sooner because otherwise an attacker can get an non-origin-clean ImageBitmap and stores it to the indexeddb in M80 and sniff the contents with the memory measurement API in M82 (Note: even when this feature is removed, an attacker can sniff data with some nice tricks if he/she can have the data enter into the process. The critical part for security is the serialization part, not the deseriazation part).
It is true that an attacker can do the same thing with M79 and M82, but I think having one milestone lessens the security risk considerably.
I will follow up with the M80 stable numbers, and if the numbers are problematic I will revert the removal change and merge it to M80.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6F5OdsvsXo3ivErEvPYiU2WyDQ_p4_R8PvHi3RgAVYNfQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjDyOeQcxsgK%3D9-HQPU4gVxkxSpx9nTgghEPN4OfxjJEA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dex%2Bsex%2B7hLA4vpyHXv0AmKmku-SQf78kaLi4wgVBQdyg%40mail.gmail.com.