search

WICG / raw-clipboard-access

An explainer for the Raw Clipboard Access feature
Other
44 stars 11 forks source link

`raw: "mixed"`? #7

Open saschanaz opened 4 years ago

saschanaz commented 4 years ago

From TPAC 2019.

So it seems raw: true always turns off the sanitizer, but could a mixed situation be helpful, where the supported formats are still sanitized and only the unsupported ones gets the raw access?

Consider we have a bleeding edge great new image format and a web app wants to write that format into the clipboard. Because browsers do not support that format, the app will have to pass raw: true to workaround the problem. And then, because the new image format is super great, the browsers might add the support later.

A way to do mixed check, maybe raw: "mixed" or similar, might allow the same code to support the new format could become automatically more secure by future potential browser update adding the format support.

What do you think?

dway123 commented 4 years ago

Thank you for bringing this up at TPAC and following up, and sorry for the delayed reply.

A mixed situation could be useful, but mixing would significantly increase the complexity on the API side (and user agent implementation), where each representation or Blob in a ClipboardItem would have to be specified as raw: "true" or not.

This is especially true when mixing browser-specified and raw formats (ex. In X11, sanitized 'text/plain' corresponds to 'TEXT', 'STRING', 'text/plain', and 'UTF_STRING', so if a web app mixed raw 'TEXT' in this write with sanitized 'text/plain', then this raw 'TEXT' would override 'TEXT' but not 'STRING', 'text/plain', and 'UTF_STRING', which may be unexpected to web application authors).

This would also require partial redesign of ClipboardItem, as items are currently either a dictionary of format to Blobs (or DOMStrings), and neither of these formats has optional Clipboard-specific parameters. This could take the form of something like a ClipboardItemDataWithOptionsobject.

I think this API was mostly designed for use through:

  1. Native applications creating a web-application port or porting some functionality to the web, but still seeking interoperability with their existing native application.
  2. Use through libraries, which may implement this encoding/decoding.

That said, the W3C Clipboard API + Raw Clipboard Access proposal doesn't preclude mixing of raw and sanitized clipboard data, in the event that multiple ClipboardItems are implemented. This could be accomplished by having one ClipboardItem be raw: true, and another be raw: false.

So sorry, I don't think there's a planned way to allow raw: "mixed" within the scope of one ClipboardItem, and this does unfortunately mean that in the use case you mentioned, web application code would have to change more if the mentioned image format were to be worked around and later supported directly in a browser.