On Thu, Oct 10, 2024 at 6:36 AM Stephen Chenney <schen...@chromium.org> wrote:
> I'm waiting on the potential security issue to be sorted out on WHATWG. > I'll ping the issue today to try and get resolution at least on the > question of whether it's really a problem. > Sounds good. > Should I set the intent back to an earlier phase or remove the request for > API Owner review? > No need - we can wait. Just checking in to make sure you're not blocked on us, thanks! > > Cheers, > Stephen. > > On Wed, Oct 9, 2024 at 11:32 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> 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/CAGsbWzRTtucr8_6sXef6nsh3uyXzF%3DOnNcDUJ3-q-RHk1UQVkA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRTtucr8_6sXef6nsh3uyXzF%3DOnNcDUJ3-q-RHk1UQVkA%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%2Bw-PF5MkxsUV%3DU8TOZqUruBe6Y%2BmXzA9QH8dHpHEGLSmLw%40mail.gmail.com.
