- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sat, 5 Jun 2010 18:36:25 -0700
- To: L.David Baron <dbaron@dbaron.org>
- Cc: Tim Berners-Lee <timbl@w3.org>, W3C TAG <www-tag@w3.org>
On Jun 4, 2010, at 7:27 PM, L. David Baron wrote: > On Wednesday 2010-06-02 16:22 -0700, Roy T. Fielding wrote: >> While I support the notion of not messing with the cut buffer >> for UI sanity (i.e., allowing this is a browser bug), I think >> it is pointless to argue about this tool as a legitimate means >> of copy control. > > I don't think it's reasonable to expect browsers to enforce user > expectations on copying given a "malicious" Web page. There are a > large number of ways to hide text, such as positioning it offscreen, > using a very small font size, making it alternate content for a > small image, positioning other content on top of it, etc. And we > certainly still want to allow copying of text that's offscreen so > users can copy large pieces of text. Yes, I don't see a problem with copying what has been selected, even if it is difficult to see the entire selection. > The ability to manipulate what a user is copying is also important > for applications on the Web. If you're using a Web app like Google > Docs, you want copy to copy a useful representation, not the > internal representation that the editor uses. If you're copying > data from a spreadsheet that auto-formats numbers by inserting > commas every three digits in the displayed value, you may well want > to copy the value without the displayed commas that are not really > part of the data, just part of the display. No, actually, those are all incorrect. You want to copy the original with all of its marked-up richness, and then you want the paste function(s) to choose how to interpret that content based on the context in which it is pasted. > For some more examples, > see https://bugzilla.mozilla.org/show_bug.cgi?id=280959#c6 . Well, the person posting the bug seemed to understand that the smartness should be applied on the paste. So does at least some of the discussion. Allowing page-loaded javascript to add text to the cut buffer is an indirect security hole. The reason is because people do rely on content selection for things like copying examples from online manuals and help sites, and a seemingly harmless example on how to view a system property like sudo fs_usage can cause a lot of damage if ; sudo rm -rf /somewhere/valuable \n is surreptitiously added to the cut buffer. There may be other ways to trick a user into copying that text, but I suspect those other ways are all more detectable on a small selection than a script adding arbitrary text to the buffer. ....Roy
Received on Sunday, 6 June 2010 01:36:58 UTC