On Thu, Sep 19, 2024 at 9:48 PM Stephen Chenney <schen...@chromium.org> wrote:
> Reply to the spec concerns inline ... > > On Thu, Sep 19, 2024 at 12:15 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> 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. >> > > Yes, the spec on tainting is a mess and not very clear at all. I > will happily create an issue and try to get the spec updated. > > 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. >> > > I agree that we can be explicit about what makes an SVG image same vs. > cross origin. It's basically recursive in that an SVG is same origin if it > only references same-origin image content, and then we have the special > foreignObject rules where a foreignObject is same-origin if the SVG is > referenced via a data URI (and blob when this intent ships) but not when > referred to by a URL. Part of the confusion arises because it's the SVG > spec that talks about SVG in a non-interactive context which basically > means "when used in an img tag". > > It may be that we need to also update the information at the > "updating-the-image-data-img-req-2" link above, because it says nothing > about what to do when the <img> src is not a regular URL, but is instead a > data URI or blob. It may be covered someplace, but I couldn't find it while > researching this email. > > >> >>> >>> >>> 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. >>> >> This changes the tainting and does not add functionality, right? Or is this adding a new ability? > >>> >>> *Gecko*: Shipped/Shipping >>> >>> *WebKit*: No signal >>> >> It's worthwhile to file a WebKit position here since we will start to deviate from that behavior. > >>> >>> *Web developers*: Strongly positive The bug has developers complaining >>> about the lack of this feature. Stack Overflow also has questions about it. >>> >> (https://issues.chromium.org/issues/41054640 is the bug (from below)) > >>> >>> *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/CAGsbWzTaP3M3E0NFdbtFJRgwKi0zOE2J6g%3DjgL5juTQQ3jiG8g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzTaP3M3E0NFdbtFJRgwKi0zOE2J6g%3DjgL5juTQQ3jiG8g%40mail.gmail.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/CADsXd2NEvrHOd6Ti4vUsEUcBuCYncd%2BMB-q7Rnu4i3FqBPYjAA%40mail.gmail.com.
