Re: [w3ctag/design-reviews] Async Clipboard - image/delayed content (#350)

1. We need transcoding to prevent remote code execution (RCE) vulnerabilities in native decoders from being exercised. File download has slightly different threats to be concerned about. For example, a user will be able to see that the file was downloaded (on the bottom downloads bar), and to see the name of the file before executing it (which is what may lead to these RCE vulnerability being exercised). In contrast, the Async Clipboard API may access data fairly silently after permission is granted, so a user may be caught off guard when pasting data outside Chrome if the data placed on the clipboard was not expected. With transcoding, this data is still guaranteed to be safe, even with user permission.

2. The developer doesn't have controls over transcode quality, which means this has parity with the existing clipboard API (and many other web platform APIs regarding images). As transcoding doesn't reduce/affect image fidelity, this shouldn't be a concern. 

Regarding layering and use with related parts of the web platform, `<canvas>`, `<HTMLElement>`, `streams`, `DOMString`, and many other types were recommended as potential `ClipboardItemDataType`s. Blobs are simply just the first implemented ClipboardItem type, as they’re able to represent a large variety of different Clipboard Types, and browsers are free to implement other representations as resources allow. 

Additionally, as image/png (through blob) is the first type being added, this means that, as shown in the [web platform tests](https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/clipboard-apis/async-write-image-read-image-manual.https.html), the API, when manipulating image/png, can interact with other APIs supporting image/png, such as ImageBitmap (shown [here](https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/clipboard-apis/async-write-image-read-image-manual.https.html)). However, this API isn’t dependent on ImageBitmap, so that [browsers](https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap#Browser_compatibility) don’t need to implement ImageBitmap (or similarly, [Streams](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API#WritableStream), which also only has partial support across browsers), as a prerequisite for implementing this API.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/350#issuecomment-490303016