Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also, clipboard data access. With Opera's switch to chromium, Firefox was the last browser without programmatic access to the clipboard[0] (though as usual MSIE has a non-standard implementation) so you had to listen for the paste event and post-process whatever garbage had been dumped in your paste area (and of course couldn't access high-level media types)

[0] Opera, as far as I remember, has neither clipboard access nor a "paste" event, the POS.



So can a website read a users clipboard, and if yes, how can we disable this "feature"?


> So can a website read a users clipboard

Yes and no, the website can access clipboard data specifically when you're pasting as a user-triggered operation (C-v/M-v or "Paste" from a contextual menu) (that is the clipboard data is only accessible from the `paste` event).

This allows an application to access alternative representations (the clipboard can store multiple representations of the same data e.g. text and html and image and whatever, and the application can then pick the most appropriate — or all of them) and to pre-process clipboard data before inserting it programmatically. Very useful with e.g. RTE. Arbitrary clipboard access most definitely isn't allowed.

See http://www.w3.org/TR/clipboard-apis/#pasting-html-and-multi-... for security and privacy considerations.

> if yes, how can we disable this "feature"?

In firefox, probably by going to about:config and setting `dom.event.clipboardevents.enabled` to `false`. In webkit and MSIE (which have had the feature for ages) I have no idea.


In Firefox, it seems like you can only catch Clipboarddata on input boxes still

    document.body.addEventListener("paste", function(e){
        console.log("paste event fired") 
    })
In Chrome, this will fire when you paste, in Firefox it will not.


It might be restricted to focusable/editable components, e.g. a `contenteditable` block should work.


Yep, you're correct

http://jsbin.com/odupog/1/edit

Either way, should alleviate some of the privacy concerns, as you can only get ClipboardData from elements where "paste" has a visible effect.


No, not unless you initiate a paste operation manually (literally, as in by hitting ctrl-v or etc.)

This is one of the ways that pasting images from your clipboard into, say, an image hosting site can work.

I had a difficult time finding fuller explanations of the capabilities - mostly because there isn't a standard API across browsers yet - but here[1] are the relevant Safari docs.

There's also a working draft[2] from the W3C for a standardized API.

[1] http://developer.apple.com/library/mac/documentation/AppleAp...

[2] http://www.w3.org/TR/clipboard-apis/


Thanks, it's just brought back memories of IE6 where a website could arbitrarily read user clipboard without notice


What?! Are all those companies still using IE6 (and, consequently, holding back progress for the rest of us) aware of this massive security hole?


Hey, it's a feature. We can "fund" the time spent on IE6 workarounds by selling data obtained from paste buffers.


Companies using IE 6 have many more security problems than clipboard access.


At this point of time IE6 is a wide open door, something as trivial as reading your paste isn't that big of a deal in comparison.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: