Re: [w3c/clipboard-apis] Make async clipboard APIs (read/write) to sanitize interoperably with setData/getData for text/html (#150)

Not entirely related, but I'll chime in about the state of image (PNG) sanitization to provide a +1 for updating the spec to make the sanitization process more explicit. The spec mentions that images should be ["safe"](https://w3c.github.io/clipboard-apis/#image-transcode), but (as you noted) is silent on the specifics of this sanitization, leading to inconsistencies across browsers.

Currently in Chrome, images are sanitized on both read and write. [Skia](https://skia.org/) is used to strip almost all metadata, retaining only what fits in an [`SkBitmap`](https://api.skia.org/classSkBitmap.html). This behavior is inconsistent with other major non-Chromium browsers, which do not sanitize images on read (see https://crbug.com/1177229). 

We've [proposed to change Chrome to only sanitize images on write](https://chromestatus.com/feature/5629962485760000) to align with other browsers. Note that this allows a site to read an unsanitized PNG directly from the system clipboard, so the "only sanitize on write" approach there is not acceptable for HTML data (and seems to be the opposite direction of what's being proposed above for HTML). In updating the spec to be more explicit about sanitization procedures (which I agree we should do) we'll have to spell out the process for each type we care about, since there is no prescriptive sanitization process that works for all types.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-910474145

Received on Wednesday, 1 September 2021 16:59:47 UTC