Seems like a good idea! On Thu, Sep 19, 2024 at 4:55 AM Chromestatus < ad...@cr-status.appspotmail.com> wrote:
> Contact emails schen...@chromium.org > > Explainer None > > Specification > https://html.spec.whatwg.org/multipage/canvas.html#security-with-canvas-elements I spent some time looking into the specification situation for this change, to understand how the interop problem might have arisen. Unfortunately, the current spec is a bit of a mess. The only information on whether an <img> will taint the canvas is given by https://html.spec.whatwg.org/#the-image-argument-is-not-origin-clean , which says that it's tainted if "image's current request <https://html.spec.whatwg.org/#current-request>'s image data <https://html.spec.whatwg.org/#img-req-data> is CORS-cross-origin <https://html.spec.whatwg.org/#cors-cross-origin>". The definition of "image data" is not clear, but at least some parts of the spec assume that it is a response <https://fetch.spec.whatwg.org/#concept-response>. A response is a generic fetch-level concept and doesn't have any SVG-specific notions, like foreignObjects. I think at the very least we should open a spec issue about this. It would be helpful to explain how the tainting is implemented in Chromium (and maybe other browsers, if you have that info) so we can see where the mismatch is between spec and implementation. It would also be ideal if we could add some sort of spec patch, even if it's a hack on top of unsteady foundations, to capture this behavior for everyone. One idea might be to add something near https://html.spec.whatwg.org/#updating-the-image-data:img-req-data-2 like > If the resource obtained is an SVG image meeting [X conditions], then it must be considered as CORS-cross-origin, even if the fetch response was CORS-same-origin. Does this sound reasonable to you? I don't want to throw up roadblocks on a small change that will improve developers' lives. But I think we can multiply our impact here by doing a bit more work to straighten out the ecosystem for everyone. And it might get some good discussion from WebKit as well. > > > Summary > > The ability to use an <img> element with an SVG source in a HTML canvas > drawImage operation has long been supported by all browsers, but the canvas > tainting behavior varies across platforms. All browsers taint the canvas > when the SVG source includes a foreignObject tag and is referenced via a > HTTP URI scheme. When the same SVG is referenced through a data URI all > browsers agree not to taint the canvas. However, when a blob URI is used > both Chromium (before this change) and WebKit taint the canvas, but Gecko > does not. When this feature is shipped Chromium's behavior will match that > of Gecko, allowing a wider range of SVG content to be used in canvas > drawImage calls without tainting. > > > Blink component Blink>Canvas > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECanvas> > > TAG review None > > TAG review status Not applicable > > Risks > > > Interoperability and Compatibility > > The feature adds functionality and has no interop risk. We align with > Gecko with this change, and begin to differ from WebKit. > > > *Gecko*: Shipped/Shipping > > *WebKit*: No signal > > *Web developers*: Strongly positive The bug has developers complaining > about the lack of this feature. Stack Overflow also has questions about it. > > *Other signals*: > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > No. The change makes HTML canvas image read-back slightly more permissive > but otherwise has no impact. > > > Debuggability > > None > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? Yes > > All platforms support the underlying functionality. We are changing the > tainting behavior, not the underlying mechanisms. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? Yes > > The CL that enables the feature will include comprehensive canvas tests. > Existing tests cover the various privacy concerns, such as ensuring the SVG > content is indeed non-interactive. > > > Flag name on chrome://flags None > > Finch feature name None > > Non-finch justification > > The code change adjusts tainting behavior, which is a state flag on the > HTML canvas context. Testing confirms that the existing behavior is > maintained, and the new behavior allows more permissive behavior. > > > Requires code in //chrome? False > > Tracking bug https://issues.chromium.org/issues/41054640 > > Measurement No explicit plan though we could add UseCounters to see how > often the change hits. > > Availability expectation Available in Chromium-based browsers and Gecko. > No idea when it might be available in WebKit. > > Adoption expectation I expect sites to transition from Data-URI to > Blob-URI for this use case. I would expect it to happen as sites update or > look for performance improvements. > > Adoption plan No explicit plan. > > Non-OSS dependencies > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > No. > > Estimated milestones > Shipping on desktop 131 > Shipping on Android 131 > Shipping on WebView 131 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > No change. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5196074156032000?gate=5159222329999360 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > 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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66eb300e.2b0a0220.28f9c2.0061.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66eb300e.2b0a0220.28f9c2.0061.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_H%2BEQs24z2N%3D_9Rqt0Hp55SDXfEH_8hBDdWTp%3D35tVfA%40mail.gmail.com.
