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.