Intent to Ship: Clipboard API: Svg

[Darwin Huang]

Contact emails

m...@chromium.org, huang...@chromium.org, dsl...@google.com

Explainer

https://docs.google.com/document/d/1Rx7gi01avpRRNYKSpp3U4WQdjery0H0IkX2XxDtfZ8I/edit#

Specification

The list of mime types supported by the async clipboard API isn’t currently specified anywhere. The list of mime types supported by datatransfer is specified here: https://w3c.github.io/clipboard-apis/#mandatory-data-types-x 

There are also efforts to improve this specification here: https://github.com/w3c/editing/issues/305 

Design docs

https://docs.google.com/document/d/1jq8QSCQRdNy99rnPusmW8is62c22PVuq-Sk-tMT2tRk/edit (internal)

Summary

Adds image/svg+xml support to the Async Clipboard API. The current implementation of the Async Clipboard API only supports text/plain, image/png, and text/html. SVG images are popular due to their ability to encode images in a space efficiently and their ability to maintain image quality even when zooming in.

Blink component

Blink>DataTransfer

Search tags

clipboard, svg

TAG review

N/A. This is a minor addition, and the supported mime types are left up to the user agent. See “Specification” section of this intent.

Risks

Interoperability and Compatibility

There is some interoperability risk because chrome will be the first browser to support the SVG format on the clipboard. There haven't been any public signals from other browsers but there also haven't been any negative signals, and this is a specified part of the clipboard, so should improve our matching of the implementation with the specification.

Gecko: No signal

WebKit: No signal

Web developers: Positive

Ergonomics

The risk is no higher than any of the other formats in the Clipboard API.

Activation

The feature is relatively easy to access. All one must do is specify the new format type as an argument.

Security

Similarly to HTML, SVG can contain malicious content. SVG is an XML based format, so it can contain javascript. We use the same sanitizer that HTML uses to remove script tags and other javascript that can be embedded in other elements.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://docs.google.com/document/d/1lZDkgiwVRsUVTjCQRcwWd6Le8W3gzVOsnrEFyehf-Sc/edit

Flag name

chrome://flags/#enable-experimental-web-platform-features 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1110511

Sample links

https://gilded-petalite-frost.glitch.me/

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5125790490427392

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/uZIHh4zMS94/m/MOVBHIAGAgAJ

This intent message was generated by Chrome Platform Status.

--

- Darwin Huang

[Yoav Weiss]

On Sat, Jul 3, 2021 at 2:55 AM Darwin Huang <huang...@chromium.org> wrote:

Contact emails

m...@chromium.org, huang...@chromium.org, dsl...@google.com

Explainer

https://docs.google.com/document/d/1Rx7gi01avpRRNYKSpp3U4WQdjery0H0IkX2XxDtfZ8I/edit#

Specification

The list of mime types supported by the async clipboard API isn’t currently specified anywhere. The list of mime types supported by datatransfer is specified here: https://w3c.github.io/clipboard-apis/#mandatory-data-types-x 

There are also efforts to improve this specification here: https://github.com/w3c/editing/issues/305 

What's the feature detection story here? Is one needed?

 

Design docs

https://docs.google.com/document/d/1jq8QSCQRdNy99rnPusmW8is62c22PVuq-Sk-tMT2tRk/edit (internal)

Summary

Adds image/svg+xml support to the Async Clipboard API. The current implementation of the Async Clipboard API only supports text/plain, image/png, and text/html. SVG images are popular due to their ability to encode images in a space efficiently and their ability to maintain image quality even when zooming in.

Blink component

Blink>DataTransfer

Search tags

clipboard, svg

TAG review

N/A. This is a minor addition, and the supported mime types are left up to the user agent. See “Specification” section of this intent.

Risks

Interoperability and Compatibility

There is some interoperability risk because chrome will be the first browser to support the SVG format on the clipboard. There haven't been any public signals from other browsers but there also haven't been any negative signals, and this is a specified part of the clipboard, so should improve our matching of the implementation with the specification.

Gecko: No signal

WebKit: No signal

Since these were filed very recently, it might be good to give them some time to respond.

 

Web developers: Positive

Any links? 

Ergonomics

The risk is no higher than any of the other formats in the Clipboard API.

Activation

The feature is relatively easy to access. All one must do is specify the new format type as an argument.

Security

Similarly to HTML, SVG can contain malicious content. SVG is an XML based format, so it can contain javascript. We use the same sanitizer that HTML uses to remove script tags and other javascript that can be embedded in other elements.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://docs.google.com/document/d/1lZDkgiwVRsUVTjCQRcwWd6Le8W3gzVOsnrEFyehf-Sc/edit

Flag name

chrome://flags/#enable-experimental-web-platform-features 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1110511

Sample links

https://gilded-petalite-frost.glitch.me/

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5125790490427392

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/uZIHh4zMS94/m/MOVBHIAGAgAJ

This intent message was generated by Chrome Platform Status.

--

- Darwin Huang

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV4WLa-%2BCRVjTkc6%2B7V_1ok%2BF7mmT%3Daydy8PGCWtQt%3DMAvViQ%40mail.gmail.com.

[Anupam Snigdha]

TAG recently raised some concerns regarding user gesture requirement for async clipboard API access: https://github.com/w3c/clipboard-apis/issues/52#issuecomment-875709431

I think it would be nice to address this issue first before we ship any additional format support. This issue is also blocking Pickling format support in the async clipboard API: https://github.com/w3ctag/design-reviews/issues/636#issuecomment-875679203

-Anupam 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX0VHWDxv5X5q0wc%3DjVBhg8H4_0QB_pEs3SP%3Dbwb%2BiwPg%40mail.gmail.com.

[Anupam Snigdha]

Sorry for multiple replies.

> Similarly to HTML, SVG can contain malicious content. SVG is an XML based format, so it can contain javascript. We use the same sanitizer that HTML uses to remove script tags and other javascript that can be embedded in other elements.

This issue will probably affect the sanitization requirement for both html and svg.

[Gary Kačmarčík (Кошмарчик)]

Will raw clipboard access provide access to the unsanitized SVG data?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Bm%3DdJpDiwC8CGT3vGo2kW5WnogmSPxw%3DjWH70Ew0-t2xKQUmA%40mail.gmail.com.

[Anupam Snigdha]

From my understanding of the current Pickling API proposal, I don't think we have any restriction as to what kind of content web authors would be able to read/write to the clipboard.

If web authors want to write unsanitized SVG data, then that will be written to the clipboard without any sanitization or changes to the payload under a custom format.

However if we do support a sanitized version of SVG, then the proposal says that we will be inserting two formats for the same payload -- Unsanitized custom format and a sanitized SVG format. That way we also support the legacy apps that read/write "standard" sets of formats like html, plaintext etc.

[Darwin Huang]

(Responses to Yoav first...)

> Feature Detection

Yes. If the feature is not supported yet, the promise will reject with an error (per the spec).

> Time to respond for intents

Sure thing.

> Links for web developers interest

Sorry no, there's no links yet, as our partner hasn't expressed this interest publicly yet. I've reached out to them to see if they're interested in expressing this publicly though.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV4WLa-%2BCRVjTkc6%2B7V_1ok%2BF7mmT%3Daydy8PGCWtQt%3DMAvViQ%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX0VHWDxv5X5q0wc%3DjVBhg8H4_0QB_pEs3SP%3Dbwb%2BiwPg%40mail.gmail.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+unsubscribe@chromium.org.

[Darwin Huang]

(Responses to snianu / garykac)

> User Gesture requirement for SVG

SVG is one web-exposed, sanitized format, and adds minimal API surface, so I don't think we'd want to differ in how we treat SVG vs other formats, which also don't currently require user gesture.

> Sanitization requirement

For now, SVG is using the most conservative sanitization available, filtering out style and other tags to ensure things are secure, just in case. I'm aware you're working on allowing <style> tags in HTML again (in this CL), but I don't think this needs to block SVG shipping without style tags for now, as offering SVG without style tags should still be more useful than the status quo (of no SVG support). If partners and other developers report a strong need for style tags, we may later decide to have these conversations with security and add this support (bug).

> Raw Clipboard Access

Raw Clipboard Access is not directly related to this SVG feature, and actually is no longer intending to ship. It launched in Dev Trials, and was blocked on outstanding security concerns. Recently, Snianu has since been working on another feature, pickling, which aims to advance the goals of Raw Clipboard (providing expanded access to clipboard formats) but in a safer way. I think his response details well how this SVG feature would interact with Pickling (they should play nicely, just as Pickling plays nicely with other existing formats like text/html and image/png)

[一丝]

> For now, SVG is using the most conservative sanitization available, filtering out style and other tags to ensure things are secure, just in case. I'm aware you're working on allowing <style> tags in HTML again (in this CL), but I don't think this needs to block SVG shipping without style tags for now, as offering SVG without style tags should still be more useful than the status quo (of no SVG support). If partners and other developers report a strong need for style tags, we may later decide to have these conversations with security and add this support (bug).

IMHO, SVG without <style> has no "soul". As a developer, I eagerly hope to support style tags when shipping.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV4WLa-%2BCRVjTkc6%2B7V_1ok%2BF7mmT%3Daydy8PGCWtQt%3DMAvViQ%40mail.gmail.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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX0VHWDxv5X5q0wc%3DjVBhg8H4_0QB_pEs3SP%3Dbwb%2BiwPg%40mail.gmail.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+...@chromium.org.

[Dedy Apriliyanto]

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV4WLa-%2BCRVjTkc6%2B7V_1ok%2BF7mmT%3Daydy8PGCWtQt%3DMAvViQ%40mail.gmail.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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX0VHWDxv5X5q0wc%3DjVBhg8H4_0QB_pEs3SP%3Dbwb%2BiwPg%40mail.gmail.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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Bm%3DdJpDiwC8CGT3vGo2kW5WnogmSPxw%3DjWH70Ew0-t2xKQUmA%40mail.gmail.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41e37835-6046-4d39-8b7f-118005ebfb47n%40chromium.org.

[Sean Voisen]

On Wednesday, July 7, 2021 at 1:30:51 AM UTC-7 yoav...@chromium.org wrote:

Web developers: Positive

Any links?

 

We have interest in using SVG support on the clipboard for web applications at Adobe. While this can be achieved to some extent by placing SVG content in text/plain, proper SVG support would definitely be preferable.

Cheers,

Sean

[Marijn Kruisselbrink]

API Owners: any further thoughts on this intent? Are there any open/pending questions for us?

[Alex Russell]

There's a recurring debate here about the stripping of inline style information; Sean, how much worse is it for styles to be stripped in your use-cases? If we wait for styles to be re-added (if they can be at all) to ship this, how much worse is that?

[Anupam Snigdha]

> For now, SVG is using the most conservative sanitization available, filtering out style and other tags to ensure things are secure, just in case. I'm aware you're working on allowing <style> tags in HTML again (in this CL), but I don't think this needs to block SVG shipping without style tags for now, as offering SVG without style tags should still be more useful than the status quo (of no SVG support). If partners and other developers report a strong need for style tags, we may later decide to have these conversations with security and add this support (bug).

Sorry for the delay in response.
The assumption that CSS styles lead to security vulnerabilities is predicated on the fact that async APIs directly mutate the DOM which it doesn't. Here is a much more detailed discussion on this subject in HTML sanitization CL: https://chromium-review.googlesource.com/c/chromium/src/+/3017109/comments/fde9ef2c_2a931157.

DataTransfer APIs provide unsanitized content which some may argue that it is for backward compatibility, but it provides more flexibility to the web authors to choose what is right for their model(which could have absolutely no relation with the CSS selectors, background url etc in the payload). 

We've had a number of bugs in Office related to the strict sanitization that reduces fidelity of copy-paste from native to web and vice versa. There are custom styles in the payload that Browsers don't understand and native Office apps use that to preserve style information when users copy content from web to native apps.

Having said that, I also agree with Darwin that this doesn't need to block SVG shipping without style tags for now, as offering SVG without style tags is still more useful than no support at all.

-Anupam

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/081c193e-b7d7-4eeb-872f-a3e64610fa64n%40chromium.org.

[Daniel Bratell]

My concern with style-less SVG is that it might result in useless content so that the feature becomes avoided rather than used. Most of the semantics in HTML is in the text, while most of the semantics in SVG is in location, size and colour, things that might be in CSS styles depending on the SVG author.

I do not know how often style-stripped SVGs are useless though, so I don't know how concerned I should be.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Bm%3DdJrYsm5mVpWUKhguRd-PgYbx1Otfa4rR%2BdjchAq6oDeuXA%40mail.gmail.com.

[Sean Voisen]

On Thursday, August 12th, 2021 at 12:22 PM, Alex Russell <sligh...@chromium.org> wrote:

There's a recurring debate here about the stripping of inline style information; Sean, how much worse is it for styles to be stripped in your use-cases? If we wait for styles to be re-added (if they can be at all) to ship this, how much worse is that?

Just so I'm clear, is the debate about stripping style attributes or style elements or both?

We would want at least one of those. Illustrator allows for exporting SVG with either, though by default (including when copying to clipboard) it uses style elements like so:

 

<style>.cls-1{fill:url(#radial-gradient);}.</style>

If both were to be sanitized away then the feature would be of more limited value for our use cases.

Sean

[Mike West]

LGTM1.

I think it's important that we address the TAG's concerns about gesture requirements and other mechanisms which might reduce the surprise associated with some uses of the clipboard API, but I agree with Darwin that shipping SVG support doesn't need to block on that conversation. That said, I'd encourage y'all to engage more closely with those questions. Marijn, you and +Victor Costan are on an internal thread on that topic that we should follow up on.

Regarding style, this intent is the most conservative approach to sanitization, which has been approved by the security team. Ideally, we could find a way to allow style safely via the sanitization API work that's underway separately, as Anne suggested on Mozilla's standards position thread. I also note that Apple's response on https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html seems generally positive.

-mike

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ROV74N4YKJX4uMRed9RUNCnyIQZRvzrLTepnhYugKwDseaZMB4Yq8Hhhlno99XIQqDTKpaAYmUdIR3D5oHat9ySM2I9HdmAVsAvfQRdNKBs%3D%40voisen.org.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DetF5YyNUVt8%3D%2BpHOXnAMRXLd9TPG2Cxyv-TXLqQdXh4g%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ROV74N4YKJX4uMRed9RUNCnyIQZRvzrLTepnhYugKwDseaZMB4Yq8Hhhlno99XIQqDTKpaAYmUdIR3D5oHat9ySM2I9HdmAVsAvfQRdNKBs%3D%40voisen.org.

--
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+unsubscribe@chromium.org.

[Alex Russell]

LGTM3 with the caveat that we should only flip this flag to ship if big customers like Sean's team are able to use this successfully to minimally cover their needs.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ROV74N4YKJX4uMRed9RUNCnyIQZRvzrLTepnhYugKwDseaZMB4Yq8Hhhlno99XIQqDTKpaAYmUdIR3D5oHat9ySM2I9HdmAVsAvfQRdNKBs%3D%40voisen.org.

--
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+unsubscribe@chromium.org.

[一丝]

Unfortunately, three LGTMs obtained here did not ship. Can anyone re-continue this process?

With Keynote 13.1 supporting the SVG format, this API seems to be the only way to copy and paste SVGs into Keynote in a browser.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ROV74N4YKJX4uMRed9RUNCnyIQZRvzrLTepnhYugKwDseaZMB4Yq8Hhhlno99XIQqDTKpaAYmUdIR3D5oHat9ySM2I9HdmAVsAvfQRdNKBs%3D%40voisen.org.

--
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+...@chromium.org.

[Chris Harrelson]

Thanks for the interest! I agree it would be good to ship this if possible.

On Tue, Oct 31, 2023 at 1:22 AM 一丝 <yio...@gmail.com> wrote:

Unfortunately, three LGTMs obtained here did not ship. Can anyone re-continue this process?

With Keynote 13.1 supporting the SVG format, this API seems to be the only way to copy and paste SVGs into Keynote in a browser.

Could you test with the experimental-web-platform-features chrome flag turned on, and see if it works as intended for copy and paste from Keynote?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44f418ae-c0b4-4e59-8083-bbb43517da29n%40chromium.org.

[Anupam Snigdha]

Thanks Chris!

cc'ing estade@.

I think Darwin and Victor are not working on clipboard anymore so this feature was stalled.

Recently another bug was opened (https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where support for copying/pasting svg images is needed. More discussions: https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313

Since this I2S was LGTM'd with the caveat that Adobe is able to use this format, and I'm not sure if there is any update on that, is it possible to reconsider this I2S if there are other customers like Keynote and Cleanshot X interested in this feature?

cc'ing Josh as well to see if there were any internal discussions with Adobe for SVG image support. Thanks!

-Anupam

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-4qajXkv5mi_XzvWwCmyeU-YGEAKFzo1u6s0GaK%2B18w%40mail.gmail.com.

[Chris Harrelson]

Hi,

From my perspective, you still have 3 LGTMs to ship from the API owners. However, please fill out the cross-functional reviews for privacy, security, etc that have been added to the process since this intent was created. If that doesn't seem possible with your existing chromestatus entry, let me know or just create a new one and I'll LGTM it after those reviews have started.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Bm%3DdJpTYBs0Mos%3Dmm%2B73z_w%3D1B5nt2VCV5O0%3D3d2hx0h7g%2BiQ%40mail.gmail.com.

[Evan Stade]

My understanding is that SVG support got lost in a personnel shuffle and that we would like to ship it in theory. This comment has some more context, the takeaways being that:

• we need to be more sure of the implementation
• we need partner confirmation, i.e. addressing "LGTM3 with the caveat that we should only flip this flag to ship if big customers like Sean's team are able to use this successfully to minimally cover their needs."

No one has done that outreach as of yet.

-- Evan Stade

[Chris Harrelson]

On Thu, Feb 1, 2024 at 2:43 PM Evan Stade <est...@chromium.org> wrote:

My understanding is that SVG support got lost in a personnel shuffle and that we would like to ship it in theory. This comment has some more context, the takeaways being that:

• we need to be more sure of the implementation
• we need partner confirmation, i.e. addressing "LGTM3 with the caveat that we should only flip this flag to ship if big customers like Sean's team are able to use this successfully to minimally cover their needs."

From my perspective the LGTMs are no longer caveated. I think there is enough evidence of demand to just do it.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS_fGhHCrfAqfutFA_NvR_HbDD8neWs9mwbGrCfgoCZPHg%40mail.gmail.com.

[Thomas Steiner]

Regarding developer interest, there's definitely some false positives in there, but a quick GitHub search demonstrates that quite a few developers attempt to write `image/svg+xml` onto the clipboard. (Including my own app, SVGcode).  

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_VgWcBprV8sdeCjnusLzuM1-C-6TDLXXuGHd%3D2S8VXaA%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Anupam Snigdha]

I've made some changes to address the loss of styles and other formatting issues during write. During read, if the authors have added `image/svg+xml` to the `unsanitized` list, then the SVG image content is returned without any strict processing by the browser. By-default, read processes the `image/svg+xml`using the strict HTML fragment parser that inlines the styles and strips out certain tags that may be security sensitive.

I have started the privacy/security reviews for this change. Thanks!

-Anupam

---

From: Thomas Steiner <to...@google.com>
Sent: Friday, February 2, 2024 12:45 AM
To: Chris Harrelson <chri...@chromium.org>
Cc: Evan Stade <est...@chromium.org>; Anupam Snigdha <snianu.m...@gmail.com>; 一丝 <yio...@gmail.com>; blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; svo...@gmail.com <se...@voisen.org>; pwn...@chromium.org <pwn...@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; huang...@chromium.org <huang...@chromium.org>; mk...@chromium.org <mk...@chromium.org>; Joshua Bell <jsb...@chromium.org>; Anupam Snigdha <sni...@microsoft.com>; chris...@chromium.org <chris...@chromium.org>; etien...@chromium.org <etien...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

 

[Anupam Snigdha]

Gentle ping.. Received signoffs for all review gates for this feature.

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Monday, February 12, 2024 10:37 AM
To: Thomas Steiner <to...@google.com>; Chris Harrelson <chri...@chromium.org>
Cc: Evan Stade <est...@chromium.org>; Anupam Snigdha <snianu.m...@gmail.com>; 一丝 <yio...@gmail.com>; blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; svo...@gmail.com <se...@voisen.org>; pwn...@chromium.org <pwn...@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; huang...@chromium.org <huang...@chromium.org>; mk...@chromium.org <mk...@chromium.org>; Joshua Bell <jsb...@chromium.org>; chris...@chromium.org <chris...@chromium.org>; etien...@chromium.org <etien...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

 

[Chris Harrelson]

My LGTM still stands, and have recorded it in the tool.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA2PR00MB09859E328A8EB23C2D8487B6CF552%40SA2PR00MB0985.namprd00.prod.outlook.com.

[Daniel Bratell]

LGTM

Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS still apply, but this still seems ready to ship.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_70VcfmFf13-Wd9Z%2BFaGBncLCkTWCj2X-JEcoZteDCjQ%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM

Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS still apply, but this still seems ready to ship.

/Daniel

On 2024-02-23 19:14, Chris Harrelson wrote:

My LGTM still stands, and have recorded it in the tool.

On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev <blin...@chromium.org> wrote:

Gentle ping.. Received signoffs for all review gates for this feature.

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Monday, February 12, 2024 10:37 AM
To: Thomas Steiner <to...@google.com>; Chris Harrelson <chri...@chromium.org>
Cc: Evan Stade <est...@chromium.org>; Anupam Snigdha <snianu.m...@gmail.com>; 一丝 <yio...@gmail.com>; blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; svo...@gmail.com <se...@voisen.org>; pwn...@chromium.org <pwn...@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; huang...@chromium.org <huang...@chromium.org>; mk...@chromium.org <mk...@chromium.org>; Joshua Bell <jsb...@chromium.org>; chris...@chromium.org <chris...@chromium.org>; etien...@chromium.org <etien...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

 

I've made some changes to address the loss of styles and other formatting issues during write. During read, if the authors have added `image/svg+xml` to the `unsanitized` list, then the SVG image content is returned without any strict processing by the browser. By-default, read processes the `image/svg+xml`using the strict HTML fragment parser that inlines the styles and strips out certain tags that may be security sensitive.

I noticed that the tests here are marked as "tentative". Is the sanitizer part of this specified? 

[Anupam Snigdha]

 I noticed that the tests here are marked as "tentative". Is the sanitizer part of this specified? 

Since there is no consensus on the clipboard sanitization, the tests are marked as tentative for now. We had discussions in the past to standardize the sanitization process (in the context of HTML), but were not able to get consensus from other browser vendors.

With the new Sanitizer API, hopefully we can standardize the sanitization process and make it consistent for all formats in the clipboard.

---

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>
Sent: Tuesday, February 27, 2024 1:06 PM
To: Daniel Bratell <brat...@gmail.com>
Cc: Chris Harrelson <chri...@chromium.org>; Anupam Snigdha <sni...@microsoft.com>; Thomas Steiner <to...@google.com>; Evan Stade <est...@chromium.org>; Anupam Snigdha <snianu.m...@gmail.com>; 一丝 <yio...@gmail.com>; blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; svo...@gmail.com <se...@voisen.org>; pwn...@chromium.org <pwn...@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; huang...@chromium.org <huang...@chromium.org>; mk...@chromium.org <mk...@chromium.org>; Joshua Bell <jsb...@chromium.org>; chris...@chromium.org <chris...@chromium.org>; etien...@chromium.org <etien...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>

[Yoav Weiss (@Shopify)]

On Tue, Feb 27, 2024 at 10:18 PM Anupam Snigdha <sni...@microsoft.com> wrote:

 I noticed that the tests here are marked as "tentative". Is the sanitizer part of this specified? 

Since there is no consensus on the clipboard sanitization, the tests are marked as tentative for now. We had discussions in the past to standardize the sanitization process (in the context of HTML), but were not able to get consensus 

Oh my.. 

While consensus does seem elusive in this case, do you think it'd be possible to specify what we're shipping here, even if we can't standardize it right away?

[Anupam Snigdha]

We're using the same sanitizer that HTML format uses to produce a fragment with styles inlined. This is also the same sanitization process used in paste operation(ctrl+V).

---

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>

Sent: Tuesday, February 27, 2024 1:30 PM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: Daniel Bratell <brat...@gmail.com>; Chris Harrelson <chri...@chromium.org>; Thomas Steiner <to...@google.com>; Evan Stade <est...@chromium.org>; Anupam Snigdha <snianu.m...@gmail.com>; 一丝 <yio...@gmail.com>; blink-dev <blin...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; svo...@gmail.com <se...@voisen.org>; pwn...@chromium.org <pwn...@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; huang...@chromium.org <huang...@chromium.org>; mk...@chromium.org <mk...@chromium.org>; Joshua Bell <jsb...@chromium.org>; chris...@chromium.org <chris...@chromium.org>; etien...@chromium.org <etien...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>

[Yoav Weiss (@Shopify)]

On Tue, Feb 27, 2024 at 10:40 PM Anupam Snigdha <sni...@microsoft.com> wrote:

We're using the same sanitizer that HTML format uses to produce a fragment with styles inlined. This is also the same sanitization process used in paste operation(ctrl+V).

OK, so that's the one specified in https://github.com/w3c/clipboard-apis/issues/150?

[Anupam Snigdha]

The exact steps of the sanitization process isn't specified anywhere since it's very fluid and also subject to change based on the outcome of the Sanitizer API proposal. Since the HTML format already uses this sanitizer, we decided to use it for SVG format as well. This was also proposed by the security team: https://docs.google.com/document/d/1jq8QSCQRdNy99rnPusmW8is62c22PVuq-Sk-tMT2tRk/edit?disco=AAAAGzUW4fQ

---

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>

Sent: Tuesday, February 27, 2024 1:53 PM

[Yoav Weiss (@Shopify)]

LGTM3

It's really not great that the sanitization steps are not specified, but given that this is simply extending where the HTML sanitization steps apply, I guess this doesn't significantly increase our tech debt on that front. 

How hard would it be to specify the sanitization steps we implemented for both HTML and SVG on top of the Sanitizer API?

[Anupam Snigdha]

Thank you for all the LGTMs!

How hard would it be to specify the sanitization steps we implemented for both HTML and SVG on top of the Sanitizer API?

I think once we have support for clipboard sanitization in the Sanitizer API, it should be fairly easy to specify that in the clipboard spec. Webkit is totally opposed to it, but Firefox position is neutral to positive, so we need support from Firefox to add this to the official clipboard API spec.

-Anupam

---

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>

Sent: Wednesday, February 28, 2024 11:08 AM

[Yoav Weiss (@Shopify)]

On Thu, Feb 29, 2024 at 2:17 AM Anupam Snigdha <sni...@microsoft.com> wrote:

Thank you for all the LGTMs!

How hard would it be to specify the sanitization steps we implemented for both HTML and SVG on top of the Sanitizer API?

I think once we have support for clipboard sanitization in the Sanitizer API, it should be fairly easy to specify that in the clipboard spec. Webkit is totally opposed to it, but Firefox position is neutral to positive, so we need support from Firefox to add this to the official clipboard API spec.

You don't need consensus in order to specify something, you need it in order to standardize it.

What that means in practice is that you could create a specification that monkey patches the clipboard and defines the sanitization steps Chromium has implemented.

Then once we have support, we'd be able to move this specification from directly into the Clipboard API spec.