Support for reading custom MIME types from the clipboard about clipboard-apis HOT 11 CLOSED

Proposal: https://docs.google.com/document/d/1sMcajoYAQ_M_VOIn1RLokG1sVB7skjoeviqt9aZOcDk/edit

Basically, document the Pickle format so that native apps can extract custom data types.

from clipboard-apis.

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, 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. 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).

from clipboard-apis.

We're going to change WebKit's behavior in STP42 to match more or less what Firefox & Chrome are doing. There are two issues with exposing custom types and letting websites write arbitrary custom types.

1. Other applications in the system tends to place privacy sensitive information such as the location of the device & user's full name and local file paths into the system clipboard. This means that letting websites read data of an arbitrary type is a privacy concern.
2. Other applications in the system are not equipped to deal with potentially harmful content being placed into the system clipboard. e.g. image decoders of a photo editing app isn't designed to defend itself against from decoding a malicious content in the system clipboard. This means that letting websites write data of an arbitrary type is a security concern.

from clipboard-apis.

I'm about to change WebKit's behavior to restrict the access.

from clipboard-apis.

@rniwa just edited my previous comment to clarify that access to custom MIME types is something we'd actually want to have! :)

from clipboard-apis.

Well, unfortunately, for privacy & security reasons, we're about to restrict that.

from clipboard-apis.

@rniwa that's why this issue is only about reading. @danburzo covered the diff between read & write in the original summary here.

from clipboard-apis.

Even then 1 applies. And gating that on a permission still leaves the user with a choice they're not really equipped to make.

from clipboard-apis.

We were actually using the access to json data in Safari - for Adobe XD and from Sketch. Chrome/Firefox filters all available json on the clipboard. What are the security implications here, and it's essentially a text data transfer format. The more limited the clipboard becomes, the less web apps can interop with native applications for legitimate use cases.

from clipboard-apis.

Raw Clipboard Access proposal is also related:
https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md

from clipboard-apis.

Web custom format support has been shipped in Chromium. Please refer to this issue for any additional concerns/feedback

from clipboard-apis.