Intent to Deprecate and Remove: non-origin-clean ImageBitmap serialization and transferring

Skip to first unread message

Yutaka Hirano

Nov 19, 2019, 12:36:11 PM11/19/19
to blink-dev, Anne van Kesteren

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

WPT tests: serialization, transferring

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?

Yes (M-80).

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.

Anne van Kesteren

Nov 20, 2019, 9:49:05 AM11/20/19
to Yutaka Hirano, blink-dev
On Tue, Nov 19, 2019 at 6:36 PM Yutaka Hirano <> wrote:
> 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.

Mozilla is definitely supportive of simplifying this setup if
possible. Our bug for this is if that helps.
I'm rather curious what the meaning of this note is however. What are
the remaining holes you are thinking of here?

Yutaka Hirano

Nov 20, 2019, 10:03:44 AM11/20/19
to Anne van Kesteren, blink-dev
Assume we remove the feature on M80.

A web developer can persist a non-origin-clean ImageBitmap with IndexedDB on M79.
Starting from M80 we are going to raise exceptions when the web developer tries to load such ImageBitmaps from the database, but the block will be implemented in the renderer.
So, the situation will be similar to a note in the current proposed PR:

To truly protect against sidechannel attacks implementations should avoid transmitting serialized.[[BitmapData]] to the surrounding agent's agent cluster under the above conditions.

ImageBitmaps serialized with M80 or later will be OK, because we won't allow serializing non-origin-clean ImageBitmaps.

Yoav Weiss

Nov 27, 2019, 12:12:31 AM11/27/19
to Yutaka Hirano, Anne van Kesteren, blink-dev

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
To view this discussion on the web visit

Mike West

Nov 27, 2019, 12:55:01 AM11/27/19
to Yoav Weiss, Yutaka Hirano, Anne van Kesteren, blink-dev

Chris Harrelson

Nov 27, 2019, 1:43:21 AM11/27/19
to Mike West, Yoav Weiss, Yutaka Hirano, Anne van Kesteren, blink-dev

Yutaka Hirano

Dec 17, 2019, 3:44:01 AM12/17/19
to Chris Harrelson, Mike West, Yoav Weiss, Anne van Kesteren, blink-dev
I took a look at stable numbers and they looked good.
I see

So far both counters are less than 0.001% of the PageVisits counter

with Chrome 79 stable. We don't need to change our mind I think.
Reply all
Reply to author
0 new messages