153868 - [RFE] allow privileged access to clipboard from scripts

Status: REOPENED

(Core :: XUL, enhancement)

Description

[Martin Kutschker]

It would be nice to be able to access the clipboard (for simple types like text)
without the need of having XPConnect privs.

I guess it is ok (securitywise) to have a (remote) app paste text or the current
selection to the clipboard. The same is probably true for copying from the
clipboard. Though this could be risk if people copy passwords around.

There needs to be an API for this (eg new JS classes or new properties of
window) and perhaps a new priv set: ClipboardRead, ClipboardWrite,
UnviversalClipboardAccess.

Comment 1

[Alfonso Martinez]

related to bug 79787 ?

Comment 2

[Martin Kutschker]

This bug is certainly related to bug #79787. But that bug is about clipboard
helper interfaces.

A possible implentation for this bug is to provide a JS wrapper for
nsIClipbordHelper or better the proposed extended nsIClipbordHelper. The point
is you would still need XPConnect privs to use nsIClipbordHelper.

Comment 3

[David Bradley]

Would it not be a security risk to open up access to the clipboard without some
security restrictions? Wide open access would allow a nefarious website to read
and send back what ever was in the clipboard without the user's knowledge.

Comment 4

[Dan Rosen]

dbradley: you're welcome to take bug 79787, if you like. I'm certainly not doing
anything with it. But my recommendation would be not to allow unprivileged
access to read from or write to the clipboard from script -- that could very
well be a security issue.

Perhaps an alternative solution to the problem with remote XUL apps (bug 133695)
is to create a clipboard work-alike whose access is restricted to a domain. In
other words, a "protected" clipboard that only one remote XUL app (or group of
apps) could use. This would make for an interesting DOM extension!

Comment 5

[Phil Schwartau]

cc'ing Mitch on the security issue raised here -

Comment 6

[Martin Kutschker]

Ad #3:

David, you are probaby right. I thought that Java allowed clipboard access, but
it doesn't (insigned, that is). I still don't worry about pasting to the
clipboard, though. It comes in handy (for the user) if you develop a small
online utility to provide a way to copy the apps "calculations" to the clipboard.

Ad #4:

Dan, your idea is interesting, but in what way would the access restricted to
what apps? If I cannot copy the clipboard's content accross all apps the feature
is of very limited use.

Sum up:

How about, unprivileged paste/write, but special privileged copy/read?
UnviersalXPConnect is just to broad.

Comment 7

[David Bradley]

This isn't an XPConnect issue. It needs to be moved to a more appropriate
component such as what ever component owns the clipboard logic. 

Comment 8

[Phil Schwartau]

That would be XP Toolkit/Widgets, I believe. Reassigning - 

Comment 9

[jag (Peter Annema)]

I would hate to think that a site can erase my clipboard contents. If not a
security hole it's at least an annoyance.

Recommend WONTFIX.

Comment 10

[Martin Kutschker]

David (#3) and Peter (#9) raise security issues. I agree that there is certainly
one with copying *from* the clipboard. There is a potential annyoing factor for
pasting *to* the clipboard.

OTOH, it's a pity you need the unnecessary broad UniversalXPConnect priv just to
paste a simple text to the clipboard. That's why I suggested the following new
privs:

ClipboardRead, ClipboardWrite, UnviversalClipboardAccess

As really unpriviledged access is unlikely to happen I change the subject to
reflect this. Will creating new privs still belong to the XPToolkit/Widget
component?

Comment 11

[jag (Peter Annema)]

Not quite sure. Mitch, where'd this go and who decides these things?

Comment 12

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 13

[Jaroslav Zaruba]

What about allow user to set his own security policies?

allow cookies for following sites:
...
enable clipboard management for following sites:
...
remmeber passwords for following sites:
...

Comment 14

[Wayne Mery (:wsmwk)]

*** Bug 331319 has been marked as a duplicate of this bug. ***

Comment 15

[Wayne Mery (:wsmwk)]

*** Bug 338868 has been marked as a duplicate of this bug. ***

Comment 16

[De Meyer]

I'm a web designer, and I encountered a problem with the security of copy/paste in Firefox with one of my clients not allowing her to edit her own web page from a CMS that uses HTMLArea. She was ready to switch back to IE until I solved it for her. 

However, I think it's way to complicated now for normal people to make these changes. There's apugin, but that one doesn't work and it's nonstandard. There should be a built-in GUI for users to allow copy/paste for the web page they're on. 


I quote Micah Wolfe stated in Bug 331319: 

"...Given(!) me an option to allow once, allow always, etc... Similar to how Firefox
behaves with popups. Certainly there has to be some better way to handle this..."

I agree with that. We need an easy GUI to enable copy paste for a given site, perhaps in the same vein as the message that appears for the popups, or otherwise in the edit  > preferences > security or edit > preferences > content.

I also agree with Jaroslav Zaruba that people should be allowed to set their own security policies in a convenient way.