Re: [w3ctag/design-reviews] Raw Clipboard Access API (#406)

> Re: security concerns and native exploits (@hober):
> 
> Raw clipboard access opens up a similar surface as Downloads, where data may touch legacy native surfaces without sanitization. We are interested in pursuing this approach despite more difficult security implications due to expressed demand, and we should be able to secure the Clipboard in a similar way as Downloads.

I don't find this a promising rationale; consider@othermaciej's [feedback](https://github.com/WICG/raw-clipboard-access/issues/3#issuecomment-529241116) on WICG/raw-clipboard-access#3:

> Downloads are one of the most dangerous features of the web platform, in terms of opportunities to escape the sandbox and install persistent malware. So saying this is just like downloads is not very encouraging!
> 
> Further, many defenses around downloads are not sensibly applicable to copy/paste, or would create a serious privacy problem if implemented. For example, opening a downloaded file requires an action in native API and creates an opportunity to prompt. But merely copying malformed data in an arbitrary format can already expose the system clipboard/pasteboard surface to security vulnerabilities. A prompt before copying is both an inadequate defense ("opening this downloaded file may be dangerous" is much more understandable than "copying this data to the pasteboard may be dangerous"), and a major usability hit. Download protection via Safe Browsing is done in a way that gives a central service (run by Google) information about anything downloaded ever. We at Apple are uncomfortable with giving Google that info about every download, but every copy operation would be that much worse! Downloads are generally from an enumerable set created up front. But copy/paste data is very personal, often user created, and it would not be appropriate to update info about it (even such info as hash, length, or what web app the user was using) to a central service.
> 
> Finally, "assume that our security teams can figure out similar solutions" is not an adequate security story for a new web API that presents serious security risk. The security defenses need to be spelled out and reviewed. There are many reasons to think that copying the approach of downloads would not be an adequate solution.

-- 
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/406#issuecomment-562249227