Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

On , Web Applications Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

>
> ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]
>
> http://www.w3.org/2008/webapps/track/issues/85
>
> Raised by: Charles McCathieNevile
> On product: Clipboard Operations
>
> What are the common security restrictions and considerations that should be listed in the clipboard apis spec?
>

I have thought thoroughly about this issue.

There are the following bad use cases, that I can remember currently:
- the user wants to copy/paste content from a webpage but the webpage is constantly setting the text on the clipboard as empty. Unfortunately, this already happens with pages using 3rd party plugins.
- a webpage that silently sniffs the clipboard to try to find sensitive data, like something that could resemble an email or a credit card number.

When I refer to system clipboard, I mean the clipboard that's shared between all applications and the user agent.
To cope with these cases I thought of having 3 levels of security regarding clipboard access:
- no access -> webpage cannot set nor get data from clipboard. This fixes most malicious use cases.
- write-only access -> webpage can write to system clipboard but can't read from it. Incidentally, the UA should store a secondary clipboard to which data is written and read freely by the webpage, but only write operations pass on to the system clipboard. This is good enough for applications that preprocess data and store it in the clipboard, while still giving the user full privacy over his system clipboard.
- full-access -> webpage has full access to system clipboard.

I don't think that the read-only case is feasible. If the user does not trust a page to write data, much less will he/she trust it to read.
It would be up to user agents to actually provide an UI to allow users to control this.

Cheers.

Received on Tuesday, 10 March 2009 09:19:10 UTC