per discussion with kbr@, webgl interface doesn't have to worry about tainted canvas, because there is no API in that interface that could taint the canvas. In other words, this flag doesn't need to be applied to WebGL, it should be applied to 2D.

Re-opening this issue.
There is a misunderstanding about the purpose of this flag.  It has nothing to do with origin-cleanness, we just happened to implementit via the origin-clean flag for 2D canvas because doing it that way was practical. This flag is meant to prevent readbacks all the time because, among other things, readbacks can be used for fingerprinting.  This is true for WebGL too. For example, different GPU models and driver versions may have slightly different behaviors. These differences could be used to identify users who widh to browse anonymously.

 Issue 607575  doesn't provide enough background for people unfamiliar with the concept (like myself) to understand the motivation. Is this going to be a public-facing web API? Something exposed in Chrome's settings UI? Something turned on automatically in Incognito mode?

At first glance this changes the WebGL API's semantics significantly. Developers expect readPixels to work. The WebGL API does not allow tainting of the canvas ever, so the only pixels written to it were generated from the same origin as the top-level document. I'm concerned about the possibility of breaking WebGL content in workers, and in OffscreenCanvas scenarios.

Could someone please provide more motivation either here or in  Issue 607575  for changing the API in this way?

It is a command line option, it has existed for a very long time in WebKit. AFAICT we just forgot to apply it to WebGL when WebGL was created.

This is a "use at your own risk" feature. It is expected that many sites will not work normally when the option is used.  We should not worry about it from a standards perspective, IMHO.

Also the comment that describes the flag should be updated to be more general. It should not talk about origins or tainting.

https://cs.chromium.org/chromium/src/content/public/common/content_switches.cc?q=kDisableReadingFromCanvas&sq=package:chromium&type=cs&l=263

I rather think that the flag should be removed. What's the point of adding a never-tested option that will break web sites?

I think that before deciding whether to remove or improve this feature we should do a bit of research to determine whether it still presents significant advantages over "canvas blocker" chrome extensions.

The detailed explanation of this flag is written in  crbug.com/448332 . There are 3 different CLs to implement this flag.

Thanks for finding that. It is a lot more recent than I thought.

+mkwst

I'm dubious of the value of this flag especially given that it is expected that it will break large parts of the web.

Note fingerprinting issue in #2.

tnagel@: Perhaps this fits with your work?