Hi Stephen,,any update on this intent? On Tue, Oct 1, 2024 at 12:10 PM Vladimir Levin <vmp...@chromium.org> wrote:
> > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NEvrHOd6Ti4vUsEUcBuCYncd%2BMB-q7Rnu4i3FqBPYjAA%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/CAOMQ%2Bw81A33J2ya7PR9unFYZse4ooCGxXU6Zmipjdh%3DfT_xFgA%40mail.gmail.com.
