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

@annevk Could you explain what & why other implementers would need to reverse engineer?

I'm going to lay out my assumptions below. Please react to anything that seems incorrect.

The idea behind data sanitization is prevent remote code execution vulnerabilities in native decoders. These vulnerability generally take advantage of insufficient input validation in a native decoder, so the sanitization would make sure that the browser only writes data that conforms to the expected input format.

The transcoding (should it be called re-encoding?) idea comes down to taking advantage of the fact that browsers already ship media processing libraries like libpng. So, instead of writing new sanitization code for each format to be written to the clipboard, a browser could use its existing libraries to decode the content produced by the page, then encode it again into the same format. The browser's libraries need to decode arbitrary content from the Web, so the decoders should already be secured against malicious input. Since the encoder ships with the browser, the encoder can be trusted to produce valid bytes.

So, other browsers shouldn't need to reverse-engineer anything. Chrome's transcoding / re-encoding logic is (modulo thread-hops):

```
const inputBytes = await ReadBytesFromBlob(inputBlob);
const decodedImage = PngDecode(inputBytes);
const safeBytes = PngEncode(decodedImage);
WriteImageToSystemClipboard(safeBytes);
```

Chrome currently calls into [Skia](https://skia.org/) for encoding/decoding images. The expectation is that other browsers would use the logic above, and have it call into their own media processing stack.

WDYT?

-- 
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-483589517