Re: [w3c/clipboard-apis] Support for reading custom MIME types from the clipboard (#46)

The implementation reason that Chrome doesn't allow unrestricted access to custom _native_ types is because merely reading a type requires registering an atom on both Windows and Linux. On Windows, the string is registered in an [internal atom table](https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053(v=vs.85).aspx), but there is no way to release this atom. Exhausting the internal atom table leads to systemwide DoS issues.

Similarly, on Linux, the target type of a selection is [also an atom](https://tronche.com/gui/x/xlib/events/client-communication/selection-request.html). Like Windows, there is no way to remove an atom from the atom table once registered. Chrome would like to avoid leaking arbitrarily large amounts of unrecoverable memory =)

As a result, Chrome never even investigated other security and privacy implications of allowing this. @rniwa, perhaps it'd be useful to document the issues on here as well?

Note that the clipboard API, as implemented in Chrome, still lets you write any custom MIME type you want: it's just that the resulting data is pickled in a custom way (i.e. it's not a 1:1 mapping with native clipboard types). The resulting data can still be read by anything on the web (or presumably any native app that wanted to parse the custom data itself).

-- 
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/46#issuecomment-338802700