Raw Clipboard Access API

[hober]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Async Clipboard: Raw Clipboard Access
• Specification or proposal URL: https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md
• TAG design review URL: Raw Clipboard Access API w3ctag/design-reviews#406
• Mozillians who can provide input (optional): @smaug----

Other information

This was a topic during the Editing TF meeting at TPAC this year.

Related to, but distinct from #89

[annevk]

Getting informed consent for this seems really hard if not impossible.

I liked the idea we had at TPAC last year much better, standardizing a web clipboard wrapper format (a type that can encompass all other types) that native apps could opt into using if they wanted to interoperate with the web and were willing to deal with the risks.

[smaug----]

Yeah, that is what I'd like too.
Understanding that copy-pasting could end up attacking native applications (and thus the whole system) can be really hard - even if permission was asked.

[ekr]

@annevk @smaug---- so it sounds like we are leaning towards Harmful?

[garykac]

For reference, in last year's conversations, we referred to that as documenting the Pickle format:

• Support for reading custom MIME types from the clipboard w3c/clipboard-apis#46 (comment)
• Async Clipboard - Pickling Custom Data

I don't believe it was discussed any further than that.

[smaug----]

During discussions at TPAC Microsoft expressed their interest on pickle format too.
But I don't know if they have an opinion on the raw access API itself.

[noncombatant]

Regarding

I liked the idea we had at TPAC last year much better, standardizing a web clipboard wrapper format (a type that can encompass all other types) that native apps could opt into using if they wanted to interoperate with the web and were willing to deal with the risks.

Gary and Darwin were talking about supporting a "Mark Of The Web" (MOTW) for the clipboard, so that native apps could opt in to looking at that. It sounds roughly equivalent to this, and I thought they had decided to specify it as part of this API. If so, that might satisfy this part of your concern?

There would (with either form of the idea) still remain the problem that the apps that would be updated to opt in to checking the wrapper/MOTW are also the apps that are actively maintained, and arguably less likely to be be or remain vulnerable to malicious clipboard data. We'd still worry about unmaintained apps that are both vulnerable and in wide use.

[dway123]

Here's the mark of the web explainer. We are indeed still interested in exploring this, especially as it could help provide extra protection for raw clipboard access, and sentiment seemed mostly positive at TPAC.

Regarding pickling, this has indeed been suggested as a potential alternative, but we would like to ensure that web applications can interoperate with existing native applications via the clipboard. Is there a way to extend pickling to allow this? My understanding is that through pickling, both web and native applications would have to implement these new formats in order to interoperate.

[annevk]

For the web pickling is seamless (i.e., it looks as if you are reading/writing your (MIME type, data) from/to the clipboard), for native it is not (i.e., you have to pickle/de-pickle your (MIME type, data) when doing so). This means that over time native can attack the web, but the web can only attack native if native opts in.

MOTW seems strictly less secure as native would have to be actively updated to look for it as you point out.

[dway123]

Yes, I agree that pickling on the web introduces less complexity for web application code. That said, is there a way to extend pickling to allow web applications to interoperate with existing native applications? If so, this could certainly be a good, viable solution to the use case we're trying to solve.

I've summarized some thoughts regarding pickling in my explainer, including why we did not propose it over Raw Clipboard Access, despite its benefits.

[annevk]

As also discussed at last year's TPAC both Apple and Mozilla expressed various security concerns with "interoperating" with existing native applications, as the user agent cannot tell "interoperating" apart from attacks and end users cannot either.

And as for adoption timelines, it will take at least a year for new APIs to be adopted by multiple browsers and be useful to target by web developers. I strongly doubt that native would be the bottleneck there.

[BoCupp-Microsoft]

During discussions at TPAC Microsoft expressed their interest on pickle format too.
But I don't know if they have an opinion on the raw access API itself.

At TPAC this year I expressed MSFT interest in the raw clipboard API.

My intuition is that there are enough opportunities to enhance the security of the clipboard experience to make this safe.

@gked and I are following up with our Windows Clipboard team and our own security experts so we can better understand how we'd mitigate the threats created by this API. We can share our findings and/or concerns here when we have them.

[smaug----]

Travis expressed interest on pickling.

[martinthomson]

My suggestion: defer. Once we have more info on pickling, we can reassess.

[annevk]

I think the proposal as-is (i.e., raw clipboard access without pickling) is harmful for reasons stated upthread. Pickling is an alternative that might work, but would indeed need to be independently evaluated once it’s more of a thing.

[martinthomson]

Right. I'm happy with either harmful and that explanation or defer if we have broad agreement that some form of wrapping is necessary.

[dbaron]

I'm also worried about the ability to read the contexts of the clipboard -- it's not clear to me how the current proposal protects that. In the past we've considered things that allowed web pages to access the contents of the clipboard to be security vulnerabilities -- and for good reason, since users sometimes copy-paste things like passwords, authentication tokens, etc. It's not clear to me that this proposal for reading the contents of the clipboard gets sufficient user consent each time that happens... or that if it did, developers would still consider it worth using.

[DavidMulder0]

As an interested industry party just want to note that the current status quo is that applications make the user install extensions/plug-ins/add-ons to get access to the clipboard. Looking at my current extension list I have at least 3 extensions (1 for Google Docs, 2 for commercial software) whose primary purpose is to give a web application access to the user's clipboard. Anything which will stop the user from installing those will improve security, as those are over reaching far more than necessary.

As far as pickling, our main concern is the ability to read the raw content from the clipboard on a button click. Is there any chance that Mozilla would consider having a different position on read than on write?

As far as 'continuous awareness', maybe worth considering showing the user a notification (or similar UI element) anytime the clipboard is read. This would be similar to how Android always notifies the user when his location is accessed. This ensures that an application will be quickly called out on any malicious behavior.