5 ms·

Uh, you can tamper with the clipboard from JavaScript. That's why this works, and why it's a problem. You shouldn't be able to by default.

by tumult 16y ago

daleharvey 16y ago
you cant, these things employ tricks like a hidden textarea that gets focused and selected when ctrl+c gets keyed down (safari does have a copy / paste events), the same can happen on paste, flash also has access to write to the clipboard, sometimes. its buggy and annoying though. but it means 1. applications cant have copy paste buttons 2. if you have a special clipboard (googles cloud clipboard), you have 2 clipboards that can very easily become out of sync. preventing abuse of the clipboard by completely killing its functionality is like banning apples because someone chocked on one once, there are much simpler solutions (like firefoxs geolocation permission dialog)
- Kadin 16y ago
  I don't see why JS code running on a page in the browser should have access to my computer's local clipboard. That's a misfeature at best, and it's ripe for abuse. Web apps that really need access to the local clipboard should have to jump through some hoops in order to access it, just like they have to jump through hoops to access the local filesystem. Perhaps we could make those permissions persist, so that users wouldn't have to constantly authorize a particular site (like Google Docs) that they want to let access their clipboard, but it should definitely not be accessible to the world by default.
  - JadeNB 16y ago
    > That's a misfeature at best, and it's ripe for abuse. I'm with the group that despises this behaviour (although I think I can't quite manage to work up to outrage), but I'm puzzled by this. Since the (mis)feature has already been abused, I assume you're referring to possible worse future abuses; but I can't think of any. Could you clarify?
    - Kadin 16y ago
      I mean that the implementation is not a true feature, but a quasi-bug in disguise. This definition sums up my use of the term fairly well (http://encyclopedia2.thefreedictionary.com/misfeature http://encyclopedia2.thefreedictionary.com/misfeature): >A feature that eventually causes lossage, possibly because it is not adequate for a new situation that has evolved. Since it results from a deliberate and properly implemented feature, a misfeature is not a bug. Nor is it a simple unforeseen side effect; the term implies that the feature in question was carefully planned, but its long-term consequences were not accurately or adequately predicted... At some point, someone must have thought that allowing JavaScript access to the clipboard would be a neat idea. And on a whiteboard, it does seem like a neat idea. But in the extremely hostile environment of the Internet, where every feature will be abused in the most user-hostile ways possible, it is a liability rather than an asset. The Internet has a long history of such features: the ability of a page to spawn new windows, which led to popups, is the one of the most glaring to casual users, but Usenet's CANCEL messages and the ensuing Hipcrime debacle is IMO more to the point. The prevailing attitude when developing desktop operating systems, which provide tools to developers under the assumption that they will be reasonably careful with them ('with great power comes great responsibility'), fails completely on the Internet. On the desktop, you can assume that obviously flawed, hostile software will get eliminated by the market -- a few people might get burned, but then nobody will install it, problem solved. On the Internet, this doesn't work; if you release a browser with a "feature" that can be exploited to take advantage of users or even to merely annoy them, it will be used, and it won't just be used a few times, it will be used over, and over, and over ... until the feature is hardened or removed (e.g. the BLINK tag, early ActiveX). I am very concerned that the rush to provide desktop-application-like capabilities to web apps will open a huge can of worms in terms of the new avenues for abuse that it allows, and the overall effect of this -- when the abuse happens in spades, which it will -- will be to cause users to disable those features globally, and distrust web apps in general.
      - daleharvey 16y ago
        I explained above javascript does not have access to the clipboard, this abuse is possible because we can bind events to keypresses, should we ban that? the idea that users should implicitly trust desktop applications more than web based programs is silly, desktop applications havent been abused? users should know what the difference between a desktop application and a web one is? firefox geolocation / save password dialog, or chrome / iphone application install process are easy solutions to explicit permissions, the idea that the clipboard is off limits is silly.

Uh, you can tamper with the clipboard from JavaScript. That's why this works, and why it's a problem. You shouldn't be able to by default.

by tumult 16y ago

Uh, you can tamper with the clipboard from JavaScript. That's why this works, and why it's a problem. You shouldn't be able to by default.

daleharvey 16y ago

you cant, these things employ tricks like a hidden textarea that gets focused and selected when ctrl+c gets keyed down (safari does have a copy / paste events), the same can happen on paste, flash also has access to write to the clipboard, sometimes. its buggy and annoying though. but it means 1. applications cant have copy paste buttons 2. if you have a special clipboard (googles cloud clipboard), you have 2 clipboards that can very easily become out of sync. preventing abuse of the clipboard by completely killing its functionality is like banning apples because someone chocked on one once, there are much simpler solutions (like firefoxs geolocation permission dialog)

Kadin 16y ago
I don't see why JS code running on a page in the browser should have access to my computer's local clipboard. That's a misfeature at best, and it's ripe for abuse. Web apps that really need access to the local clipboard should have to jump through some hoops in order to access it, just like they have to jump through hoops to access the local filesystem. Perhaps we could make those permissions persist, so that users wouldn't have to constantly authorize a particular site (like Google Docs) that they want to let access their clipboard, but it should definitely not be accessible to the world by default.
- JadeNB 16y ago
  > That's a misfeature at best, and it's ripe for abuse. I'm with the group that despises this behaviour (although I think I can't quite manage to work up to outrage), but I'm puzzled by this. Since the (mis)feature has already been abused, I assume you're referring to possible worse future abuses; but I can't think of any. Could you clarify?
  - Kadin 16y ago
    I mean that the implementation is not a true feature, but a quasi-bug in disguise. This definition sums up my use of the term fairly well (http://encyclopedia2.thefreedictionary.com/misfeature http://encyclopedia2.thefreedictionary.com/misfeature): >A feature that eventually causes lossage, possibly because it is not adequate for a new situation that has evolved. Since it results from a deliberate and properly implemented feature, a misfeature is not a bug. Nor is it a simple unforeseen side effect; the term implies that the feature in question was carefully planned, but its long-term consequences were not accurately or adequately predicted... At some point, someone must have thought that allowing JavaScript access to the clipboard would be a neat idea. And on a whiteboard, it does seem like a neat idea. But in the extremely hostile environment of the Internet, where every feature will be abused in the most user-hostile ways possible, it is a liability rather than an asset. The Internet has a long history of such features: the ability of a page to spawn new windows, which led to popups, is the one of the most glaring to casual users, but Usenet's CANCEL messages and the ensuing Hipcrime debacle is IMO more to the point. The prevailing attitude when developing desktop operating systems, which provide tools to developers under the assumption that they will be reasonably careful with them ('with great power comes great responsibility'), fails completely on the Internet. On the desktop, you can assume that obviously flawed, hostile software will get eliminated by the market -- a few people might get burned, but then nobody will install it, problem solved. On the Internet, this doesn't work; if you release a browser with a "feature" that can be exploited to take advantage of users or even to merely annoy them, it will be used, and it won't just be used a few times, it will be used over, and over, and over ... until the feature is hardened or removed (e.g. the BLINK tag, early ActiveX). I am very concerned that the rush to provide desktop-application-like capabilities to web apps will open a huge can of worms in terms of the new avenues for abuse that it allows, and the overall effect of this -- when the abuse happens in spades, which it will -- will be to cause users to disable those features globally, and distrust web apps in general.
    - daleharvey 16y ago
      I explained above javascript does not have access to the clipboard, this abuse is possible because we can bind events to keypresses, should we ban that? the idea that users should implicitly trust desktop applications more than web based programs is silly, desktop applications havent been abused? users should know what the difference between a desktop application and a web one is? firefox geolocation / save password dialog, or chrome / iphone application install process are easy solutions to explicit permissions, the idea that the clipboard is off limits is silly.