Contact emails
huang...@chromium.org, pwn...@chromium.org
Explainer
https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md
Design Doc
https://tinyurl.com/raw-clipboard-access-design
Spec
https://w3c.github.io/clipboard-apis/ (not yet updated to include Raw Clipboard Access)
TAG Review
https://github.com/w3ctag/design-reviews/issues/406
Summary
Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform.
Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.
This could be used by:
Online editors like Google Docs or Microsoft Office 365, copy/paste OpenOffice or Microsoft Word documents/spreadsheets/presentations (proprietary formats).
Figma or Photopea, to copy/paste PhotoShop/GIMP, GIFs, or RAW images, or already-supported formats with not-supported metadata (long tail of metadata).
Web Apps supporting “niche” types, like LaTeX, .ogg, etc (long tail of formats).
The existing Async Clipboard API’s re-encoding is still encouraged for use cases requiring only generic types, and easier to use as custom encoders/decoders would not be necessary, but raw clipboard access allows web applications with more specific or sophisticated clipboard support needs to meet those needs.
Motivation
Without Raw Clipboard Access:
Google Docs requires an extension in order to copy and paste content interoperable with Microsoft Office.
Some native applications may reverse-engineer Webkit and Blink’s pickling/custom clipboard formats (ex. "org.chromium.web-custom-data") to interoperate with the web, without requiring any permissions protections.
Web applications are generally limited to a small subset of formats, and are unable to interoperate with the long tail of formats. For example, Figma and Photopea are unable to interoperate with most image formats.
Risks
Interoperability and Compatibility
This feature is built on top of the Async Clipboard API. There is interoperability risk if no other browsers decode to implement.
Edge: No Signals.
Firefox: Negative Signals.
Safari: Negative Signals.
Web / Framework developers: Positive Signals (Figma, Photopea, and SketchUp).
Ergonomics
This feature will be used in tandem with the Blob API. As this API is fairly asynchronous and performant, and is capable of running on a background thread, this should not negatively impact performance.
Activation
This library is more complex to use, as a relatively low-level API. That said, this is intended for web applications with more complex needs, or through indirect use (via a library), so this complexity is necessary to allow low-level access.
Debuggability
Dedicated debugging support on DevTools is not required for this change.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5682768497344512
Requesting approval to ship?
No
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdfe0147-2f09-4dcf-88a0-e49ea8e962ad%40chromium.org.
I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)
https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#minimal-implementation-for-user-agents says that websites can only feature-detect this if the UAs that don't support it reject calls with {raw : true}. I think we usually want a way to feature-detect new features even if other UAs don't implement anything about them.
Thank you for the quick response.On Mon, Oct 7, 2019 at 2:34 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)In addition to a permission prompt, there are also the same guarantees that the async clipboard API is afforded to avoid abuse (secure context, active frame, as well as an asynchronous API that allows room to inject Safe Browsing checks, just like the Downloads and Native File System APIs have.
https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#minimal-implementation-for-user-agents says that websites can only feature-detect this if the UAs that don't support it reject calls with {raw : true}. I think we usually want a way to feature-detect new features even if other UAs don't implement anything about them.Sorry, I think that the explainer's wording wasn't too accurate. Feature detection could be accomplished by checking the `ClipboardItem` prototype for the `raw` property (which presumably would be `undefined` if not implemented, and `true`/`false` if implemented). The minimal implementation was more intended for Webkit as a more palatable fallback as they're not interested in implementing raw clipboard access. I've updated the section accordingly.
On Mon, Oct 7, 2019 at 6:35 PM Darwin Huang <huang...@chromium.org> wrote:Thank you for the quick response.On Mon, Oct 7, 2019 at 2:34 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)In addition to a permission prompt, there are also the same guarantees that the async clipboard API is afforded to avoid abuse (secure context, active frame, as well as an asynchronous API that allows room to inject Safe Browsing checks, just like the Downloads and Native File System APIs have.The first two aren't really defenses, but Safe Browsing might be.
On the Mozilla side we feel that this is not a permissions prompts users
can usefully evaluate, and hence that click-through rates are likely to
be high.
Of course the most useful thing there would be actual data on how users
respond to this prompt. Do you know whether any user studies have been
done on it, by any chance?
It seems like one coherent approach would be to attempt to reduce or
eliminate existing risks while not introducing new ones...
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/rkGWbui8B9A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/74da0061-11db-4912-b5a6-6d4d954c13f2%40chromium.org.