Re: [clipboard] Semi-Trusted Events Alternative
Not quite :) Check the list of events - mousemove isn't included: http://www.w3.org/TR/html5/browsers.html#allowed-to-show-a-popup I was just going by where I¹ve seen pages pop up windows, and I¹ve seen pages that pop up windows just by moving the mouse across them. If you see that again, please report a bug to your browser vendor so it can be properly analysed. Keeping in mind that Flash has had similar policies for a while Isn¹t Flash limited to a region of the page? Not necessarily. For example, it's trivial to make a transparent Flash thingy that follows your mouse when you move it to catch any clicks. And I suppose that¹s the answer here too, someone will write an extension to block a page from modifying or reading the clipboard and I¹ll just use that. Although that doesn¹t help on mobile browsers that don¹t allow extensions. On the timeline of a spec and its implementations, I'm almost certain you'll have a choice of mobile browsers with extension support when this spec is widely implemented in full detail ;). Now, security/usability is a matter of trade-offs and balances. It's valuable to try to imagine all sorts of abuse that might occur, but it's also a bit like thinking of all the bad things that *might* happen if you left the house. Most of us still go outside many times a week. -Hallvord
Re: [clipboard] Semi-Trusted Events Alternative
On 16 sept. 2014, at 02:36, Brian Matthews (brmatthe) brmat...@cisco.com wrote: And again what about the naïve user that doesn’t even know what an extension is or read somewhere that they’re “bad”, or will even understand what happened when their wife/husband/parent/child finds http://insert unsavory domain of your choice in their clipboard or browser history? There's a zillion such pollution that can happen today. - Popups are an example (if private browsing is not on): they pollute the history - An easy example is the download (with content-disposition not being inline) of random files (e.g. executables, pictures, pdfs) when you navigate to a site. This happens at really poor sites in an unintentional way. The poorness of the site is the users' experience. This function can positively affect people that employ a website that is sane and offers the function of copying an element of the site (e.g. with a button in a rollover…). Using websites that are not sane can happen, but generally, one tends to go away from them! The whole web has grown this way. paul
Re: [clipboard] Semi-Trusted Events Alternative
We did some user research on this feature when we were building our most recent flagship product a few years back. Our users' reactions to a sane site enhancing their clipboard data were unanimously delighted rather than upset/offended/horrified. As Hallvord said, sites have been able to do this for 5+ years using Flash and it hasn't caused any issues/uproar that I've heard of since they fixed the security model to Flash 10 to match what has been proposed here: the clipboard injection is only allowed in direct response to a user's click/keyboard action. (In Flash 10, the Flash developer could inject custom contents into the user's clipboard at any time... bad idea.) Sincerely, James Greene Sent from my [smart?]phone On Sep 16, 2014 4:30 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: a page can wipe out my entire clipboard history if I move my mouse over it. Not quite :) Check the list of events - mousemove isn't included: http://www.w3.org/TR/html5/browsers.html#allowed-to-show-a-popup I agree that all the concerns you listed are real. I recall an article I've seen about a court case against a teacher because a school computer was infected with malware and happened to display some porn during this teacher's class. I think this was in the U.S. or UK, so even the countries we tend to think have the most developed legal systems have problems with basic tech literacy! It's a sad fact that the web is implemented in such an imperfect world..and we should definitely keep that in mind. However, I hope that checking the list of events will help - the policy has more limitations than you seem to think. I still think that the popup precedent gives us reason for some optimism - it also shows that if an aspect of web technology is abused and causes nuisance, browser vendors will step up to implement limitations. I think in the long run, this is also the case with clipboard APIs - we're spec'ing something trying to balance the usability and trust issues, if we get it right we've enabled some more functionality for web apps without too much nuisance and abuse - if we get it wrong, we probably have to revisit this and lock it down with site whitelists and such. Keeping in mind that Flash has had similar policies for a while and some site put weird stuff on my clipboard hasn't been a frequent complaint so far (and AFAIK hasn't been needed as defence in court yet), I think and hope we're shipping a reasonable and balanced policy here. -Hallvord
Re: [clipboard] Semi-Trusted Events Alternative
a page can wipe out my entire clipboard history if I move my mouse over it. Not quite :) Check the list of events - mousemove isn't included: http://www.w3.org/TR/html5/browsers.html#allowed-to-show-a-popup I was just going by where I¹ve seen pages pop up windows, and I¹ve seen pages that pop up windows just by moving the mouse across them. I can¹t remember where so can¹t provide examples. However, even if we assume that was something else (browser bug, user error :-) ), the fact that just clicking anywhere on a page is enough to allow the page to stuff something in my clipboard is concerning. Keeping in mind that Flash has had similar policies for a while and some site put weird stuff on my clipboard hasn't been a frequent complaint so far (and AFAIK hasn't been needed as defence in court yet), I think and hope we're shipping a reasonable and balanced policy here. Isn¹t Flash limited to a region of the page? That is, the Flash clipboard copier can¹t catch a click anywhere on the page, just in the region the Flash script is running in. Or can a page have a transparent Flash that covers the whole page? I run with FlashBlock so I don¹t know a lot about all the things Flash can do. And I suppose that¹s the answer here too, someone will write an extension to block a page from modifying or reading the clipboard and I¹ll just use that. Although that doesn¹t help on mobile browsers that don¹t allow extensions. Brian
Re: [clipboard] Semi-Trusted Events Alternative
On 9/16/14, 5:22 AM, James M. Greene james.m.gre...@gmail.commailto:james.m.gre...@gmail.com wrote: We did some user research on this feature when we were building our most recent flagship product a few years back. Our users' reactions to a sane site enhancing their clipboard data were unanimously delighted rather than upset/offended/horrified. Two comments: First, I’m not worried about sane sites (well, not as much :-) ). If all we had to worry about were sane sites we wouldn’t need popup blockers, URL filters, malware blockers, noscript, etc. Second, did you mention to your users some of the negative possibilities? If not, I’d suggest that they weren’t upset/offended/horrified simply because they didn’t think of the downsides. Brian
Re: [clipboard] Semi-Trusted Events Alternative
On Sun, Sep 14, 2014 at 5:54 AM, Dale Harvey d...@arandomurl.com wrote: websites can already trivially build editors that use copy and paste within the site itself, the entire problem is that leads to confusing behaviour when the user copies and pastes outside the website, which is a huge use case of the clipboard in the first place I'm not sure I fully follow your argument. So let me provide two options that I think we have. 1. Forbid any attempts at reading directly from the clipboard, no matter if the data there came from the current origin or not. Thereby keeping the API consistent. 2. Allow reading data from the clipboard at any time if the data there originated from the current origin. Thereby making the API as helpful as possible for the case when data is copied within a website. Are you saying that you think the consistency of option 1 is more important than the ease-of-use of option 2? The only thing that I'd worry about is that having websites handle within-website copying themselves rather than go through the clipboard API is that it can very easily create edgecases that are easy to miss. For example, how does the website detect if the user overwrites the contents of the clipboard by copying data from another location? Or if the OS has features like a clipboard manager which allows you to keep a history of clipboard contents and paste old values (I believe Windows used to enable this). / Jonas
Re: [clipboard] Semi-Trusted Events Alternative
[Responding to several messages about pasting data from same origin here]
- Original Message -
From: Jonas Sicking jo...@sicking.cc
* paste: we allow reading clipboard contents if the paste event is not
synthetic and not triggered from a document.execCommand('paste') call
I think we should also allow reading data that was copied from the
same origin. That way a website can build an editor which has full
copy/paste capabilities as long as you are only editing within that
website.
It's an interesting idea that partly fixes the main drawback with the current
proposal: that to read clipboard contents, paste must be triggered from the
browser's own UI, not the website's. The current proposal makes it possible for
a website to create a Copy button it its UI, and it will just work when
clicked, but to create an equivalent Paste button the site must be
white-listed and allowed to read all clipboard content.
However, this suggestion does add yet some more complexity...
From: Dale Harvey d...@arandomurl.com
websites can already trivially build editors that use copy and paste within
the site itself
Indeed, I've seen pretty high profile online editors with a cloud
clipboard-labelled feature. However, I don't think this is user friendly or
understandable eventually. If you copy something from the app to the cloud
clipboard, then copy something from your desktop word processor to the system
clipboard, then try to paste - what do you expect to paste? Most users would
expect the content from the word processor. The clipboard works precisely
because it is ONE global place for exchanging all sorts of content. AFAIK, the
experimental cloud clipboard disappeared again from the app that was using it
(though I don't remember where I saw this, and I may be wrong about it being
removed again).
From: Jonas Sicking jo...@sicking.cc
I'm not sure I fully follow your argument. So let me provide two
options that I think we have.
1. Forbid any attempts at reading directly from the clipboard, no
matter if the data there came from the current origin or not. Thereby
keeping the API consistent.
The spec and reality is currently a bit more liberal than that :) - we give any
script access to data regardless of origins when it's pasted from the browser's
trusted UI (Ctrl-v, Edit Paste, Right-click Paste et al). The only
question is whether and how we can safely enable sites creating their own paste
UI, allowing said UI to trigger paste with document.execCommand().
2. Allow reading data from the clipboard at any time if the data there
originated from the current origin. Thereby making the API as helpful
as possible for the case when data is copied within a website.
So, I'm not yet sold on this suggestion. As I said already it's interesting -
but it adds complexity to security/privacy-sensitive programming logic, and it
might add layers of confusion for users. The paste button worked fine a moment
ago, why doesn't it work now??. Copying from tab A worked fine and I could
paste, copying from tab B fails??.
I believe the simple yes/no choice of a trust/grant privileges UI is easier to
understand, and if you're going to type in/edit text on a website in the first
place chances are that it's a site you trust. So my gut feeling is that the
complexity/usability cost is too high for what this extra rule would buy us.
I'm still open to arguments though - perhaps especially if list members can
come up with sites that have editors with cut/paste UI, sites where members of
this list would want to allow the paste UI to work for reading same-origin
content off the OS clipboard, but would NOT want to trust the site with full
read access to their clipboards - and where lots of people might feel the same
way..
-Hallvord
Re: [clipboard] Semi-Trusted Events Alternative
On Mon, Sep 15, 2014 at 1:42 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: It's an interesting idea that partly fixes the main drawback with the current proposal: that to read clipboard contents, paste must be triggered from the browser's own UI, not the website's. The current proposal makes it possible for a website to create a Copy button it its UI, and it will just work when clicked, but to create an equivalent Paste button the site must be white-listed and allowed to read all clipboard content. I'm not suggesting any whitelists. I'm just suggesting that all websites can, without any user gestures, read data from the clipboard if that data originated from the website itself. / Jonas
Re: [clipboard] Semi-Trusted Events Alternative
On Sep 15, 2014, at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Sep 14, 2014 at 5:54 AM, Dale Harvey d...@arandomurl.com wrote: websites can already trivially build editors that use copy and paste within the site itself, the entire problem is that leads to confusing behaviour when the user copies and pastes outside the website, which is a huge use case of the clipboard in the first place I'm not sure I fully follow your argument. So let me provide two options that I think we have. 1. Forbid any attempts at reading directly from the clipboard, no matter if the data there came from the current origin or not. Thereby keeping the API consistent. 2. Allow reading data from the clipboard at any time if the data there originated from the current origin. Thereby making the API as helpful as possible for the case when data is copied within a website. Are you saying that you think the consistency of option 1 is more important than the ease-of-use of option 2? Doing 2 would mean that we’ll be changing the semantics of copy and paste. It would be extremely confusing for users IMO. It’s also incompatible with conventions on a lot of operating systems. - R. Niwa
Re: [clipboard] Semi-Trusted Events Alternative
On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com wrote: [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events Anne wrote: The default action of a synthetic paste event is to insert any data passed to the event constructor, if that data is suitable for the event target. If the data type is not suitable for the event target, data must not be inserted. Seems wrong. Why is that still in the editor's draft? Quite simply because I had not yet gotten around to removing it - I had reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=25825 to not forget about the issue though. Unlike you, I'm not hired and paid to work on specs, so even though it's a tiny spec and nowhere near Hixie-like volumes of feedback, I still need to get other tasks out of the way and find some time to do spec work. Anyway, let me announce that both the synthetic events causing real actions and the semi-trusted events are now gone from the spec. I hope I also managed to fix all the related tests. (And BTW, the test suite is on its way into web-platform-tests, pending this review: https://critic.hoppipolla.co.uk/r/2584 ) We should probably publish another snapshot while we're at it. -Hallvord
RE: [clipboard] Semi-Trusted Events Alternative
-Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com wrote: [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events The default action of a synthetic paste event is to insert any data passed to the event constructor, if that data is suitable for the event target. If the data type is not suitable for the event target, data must not be inserted. Seems wrong. Why is that still in the editor's draft? Dispatching synthetic events should not cause actions. -- http://annevankesteren.nl/ I agree. Why are synthetic events causing actions?
RE: [clipboard] Semi-Trusted Events Alternative
-Original Message- From: Perry Smith [mailto:pedz...@gmail.com] As a side note: I would change isTrusted to fromUserAgent to make it more honest. Folks are somewhat foolish to trust their browsers and all the plugins. e.g. people unwittingly trust flash. I would remove trust from the names of things. semi-trusted seems worse to me. Reminds me of slightly-pregnant. Its either one or the other. It appears to me that isTrusted and semi-trusted are really trying to say the user has not been fooled. Which brings me back to my original question. What, precisely, are we afraid the user has been fooled into doing? Thank you for your time, Perry I agree with this. 'Semi-trusted' seems like a misnomer. We need a way to understand that a user intended to copy/cut/paste for the given site. The argument that there is precedent here doesn't really seem to hold. Plugins have historically been a source of security issues, so saying that plugins allow this behavior doesn't really help. I still think we should try to figure out a model where the user knows what they're doing (like input type=file). Authors use that object because it's the way to get to files. If an 'input type=clipboard' were the way to get to the clipboard, wouldn't authors use it? Surely we can come up with ways to style it to match website design without losing the clear intention of giving clipboard access.
Re: [clipboard] Semi-Trusted Events Alternative
On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com wrote: [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events The default action of a synthetic paste event is to insert any data passed to the event constructor, if that data is suitable for the event target. If the data type is not suitable for the event target, data must not be inserted. Seems wrong. Why is that still in the editor's draft? Dispatching synthetic events should not cause actions. -- http://annevankesteren.nl/
Re: [clipboard] Semi-Trusted Events Alternative
If this is really the case, it seems that separating Copy from Paste would be proper. The spec sort of distinguishes them (but this should probably be spelled out in detail): per the current spec text, copy/cut can be triggered from any trusted or semi-trusted event, while paste is only allowed if the UA is explicitly configured to allow it. But I should explain this better in the spec - especially because I keep forgetting about this myself ;) I very much agree: it seems like much of the discussion slowing down progress on this spec and subsequent implementations is a concern over unauthorized programmatic access to read the user's clipboard (i.e. synthetic `paste`) but that is NOT part of the spec, nor would I want it to be. That functionality is also NOT supported in Flash: you can still only read the clipboard contents while handling a user-initiated `paste` operation into a Flash UI component. The main desired functionality that is really driving this spec is the synthetic/programmatic `copy` operation. Looking at ZeroClipboard's [1][2] usage statistics provides plenty of evidence that this feature is both increasingly desired by developers [3][4][5] and frequently used by consumers [6]. [1]: ZeroClipboard home page: http://zeroclipboard.org/ [2]: ZeroClipboard repo: https://github.com/zeroclipboard/zeroclipboard/ [3]: Public websites using ZeroClipboard number well over 30,000: https://github.com/zeroclipboard/zeroclipboard/wiki#websites-using-zeroclipboard [4]: ZeroClipboard currently has 3000+ stars on GitHub. [5]: ZeroClipboard averages more than 1000 installs per week via NPM, which is only one of many ways/systems by which developers can get ZeroClipboard: https://www.npmjs.org/package/zeroclipboard [6]: GitHub usage statistics (as of March 2014) for the ZeroClipboard click-to-copy buttons indicate an average of 35,000+ clicks per day. Sincerely, James M. Greene http://greene.io/
Re: [clipboard] Semi-Trusted Events Alternative
(Replying to both Ben's and Ryosuke's mails)
Ben wrote:
Semi-trusted events in the Clipboard API spec [1] are a potential solution
to an important problem- sites should be able to use the same infrastructure
(clipboard events) with their own triggers (button with execCommand('paste')
as browser initiated clipboard operations (like user presses control+v or
uses the context menu's 'paste' option). However, I don't really know if
'semi-trusted' events are the solution. Users will almost certainly be using
the keyboard or mouse with websites, so requiring an event to originate from
keyboard or mouse doesn't seem to make them trusted at all. I know there has
been some discussion of removing them from the spec [2]. What is the status
of that?
The intention here would be removing it from the spec but instead referencing
something equivalent in other specs, so the implemented functionality would be
equivalent.
Ryosuke wrote:
Users are going to click on somewhere in the page while browsing. I don’t
see how, selecting a line of text, clicking on a hyperlink, or pressing the
down arrow key to scroll etc… could lead to indicate the user’s intention
to expose the clipboard/pasteboard’s content to the web page.
It's not a perfect solution, but in reality this is the current state and has
been for several years, for the millions of users who enable Flash.
Implementors who want to give the user more obvious control over this mechanism
should implement a per-site permission for reading the clipboard and add a
non-obtrusive confirmation prompt that appears on a site's first attempt to do
execCommand('paste'). The natural follow-up question is if we do a per-site
permission thingy, why have semi-trusted events at all?, and the answer at the
moment is for Flash feature parity which might not be a very good reason.
Ben wrote:
As an alternative to semi-trusted events, perhaps we should have something
similar to input type=file? Perhaps a new input type that must display a
localized word for cut, copy, or paste, and must not be occluded by
any other element, could trigger real, trusted clipboard events? I'm not
sure how this would work, but it seems worth a discussion at least.
Authors apply a lot of weird and creative hacks to style input type=file. I
don't think we can mandate a specific look for an element and expect authors to
use it.. :-/ It's an interesting suggestion and would for example make it
possible to prompt the user earlier with a do you want to let this site read
the clipboard-type question. However, if that's our goal, we should rather aim
for a more generic request functionality approach, something like
navigator.desiredFunctionality('paste', 'gps', 'device camera')
or similar. But thanks for re-booting the discussion!
-Hallvord
Re: [clipboard] Semi-Trusted Events Alternative
Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid. Can someone explain that to me? I surfed around a bit but did not find any articles except pages talking about users pasting content they got from the web directly into a terminal window. Is that the concern? As a side note: I would change isTrusted to fromUserAgent to make it more honest. Folks are somewhat foolish to trust their browsers and all the plugins. e.g. people unwittingly trust flash. I would remove trust from the names of things. semi-trusted seems worse to me. Reminds me of slightly-pregnant. Its either one or the other. It appears to me that isTrusted and semi-trusted are really trying to say the user has not been fooled. Which brings me back to my original question. What, precisely, are we afraid the user has been fooled into doing? Thank you for your time, Perry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [clipboard] Semi-Trusted Events Alternative
On Sat, Jul 26, 2014 at 9:19 AM, Perry Smith pedz...@gmail.com wrote: Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid. Can someone explain that to me? Its a point of data egress. You don't want sensitive information from one program scraped and egressed by another. The first program could be a browser and the second program could be malware. In this case, the malware looks for data placed on the clipboard by the browser (and hopes to get a username, password, sensitive document, etc). Or, it could be another program with the browser scraping the data and hauling it off to a site. Jeff
Re: [clipboard] Semi-Trusted Events Alternative
On Jul 26, 2014, at 8:26 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jul 26, 2014 at 9:19 AM, Perry Smith pedz...@gmail.com wrote: Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid. Can someone explain that to me? Its a point of data egress. You don't want sensitive information from one program scraped and egressed by another. The first program could be a browser and the second program could be malware. In this case, the malware looks for data placed on the clipboard by the browser (and hopes to get a username, password, sensitive document, etc). Or, it could be another program with the browser scraping the data and hauling it off to a site. I thought about that. So it is not so much the Copy and Paste operations as much as being able to get the content of the clipboard. ? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [clipboard] Semi-Trusted Events Alternative
On Sat, Jul 26, 2014 at 9:34 AM, Perry Smith pedz...@gmail.com wrote: On Jul 26, 2014, at 8:26 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jul 26, 2014 at 9:19 AM, Perry Smith pedz...@gmail.com wrote: Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid. Can someone explain that to me? Its a point of data egress. You don't want sensitive information from one program scraped and egressed by another. The first program could be a browser and the second program could be malware. In this case, the malware looks for data placed on the clipboard by the browser (and hopes to get a username, password, sensitive document, etc). Or, it could be another program with the browser scraping the data and hauling it off to a site. I thought about that. So it is not so much the Copy and Paste operations as much as being able to get the content of the clipboard. ? Yes, I believe so. The clipboard is a shared resource with little to no restrictions. One of the check boxes on a security evaluation is how a program handles the clipboard and copy/paste (or at least the ones I used when doing security architecture work). Its one of those dataflows that could be part of a higher then expected data sensitivity, like a single sign-on password. Also, data egress may have been a bad choice. In this case, I think its more about data collection. Its hard to stop a web browser from opening a socket ;) Two addition clipboard features that would be nice are: (1) a one shot copy/paste: delete the password from the clipboard after retrieving it from he password manager and pasting it into a password box; and (2) timed copy/paste: expire the data after 10 seconds or so. Both should allow the legitimate use cases, and narrow the window for the abuse cases. Jeff
Re: [clipboard] Semi-Trusted Events Alternative
On Jul 26, 2014, at 9:09 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jul 26, 2014 at 9:34 AM, Perry Smith pedz...@gmail.com wrote: On Jul 26, 2014, at 8:26 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jul 26, 2014 at 9:19 AM, Perry Smith pedz...@gmail.com wrote: Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid. Can someone explain that to me? Its a point of data egress. You don't want sensitive information from one program scraped and egressed by another. The first program could be a browser and the second program could be malware. In this case, the malware looks for data placed on the clipboard by the browser (and hopes to get a username, password, sensitive document, etc). Or, it could be another program with the browser scraping the data and hauling it off to a site. I thought about that. So it is not so much the Copy and Paste operations as much as being able to get the content of the clipboard. ? Yes, I believe so. The clipboard is a shared resource with little to no restrictions. One of the check boxes on a security evaluation is how a program handles the clipboard and copy/paste (or at least the ones I used when doing security architecture work). Its one of those dataflows that could be part of a higher then expected data sensitivity, like a single sign-on password. Also, data egress may have been a bad choice. In this case, I think its more about data collection. Its hard to stop a web browser from opening a socket ;) Two addition clipboard features that would be nice are: (1) a one shot copy/paste: delete the password from the clipboard after retrieving it from he password manager and pasting it into a password box; and (2) timed copy/paste: expire the data after 10 seconds or so. Both should allow the legitimate use cases, and narrow the window for the abuse cases. If this is really the case, it seems that separating Copy from Paste would be proper. As a web application implementor, I am much more worried about Copy than Paste. I want to allow the user to quickly move something into the clipboard. In the times I have been frustrated, it has never been about Paste. If Copy is not the problem, it would help me if it was split out. Off topic slightly: my current technique is to have a UI element that selects the content and then the user has to do the Copy from the OS menu (two steps instead of one). This is not horribly bad since there is usually a mouse / menu way to do this as well as a keyboard short cut method. The ick factor is mostly due to existing expectations. But it is relatively close to what most applications do. Rarely is it the case that an application provides a UI element that moves some piece of unselected text into the clipboard. Perhaps what we have is what we want. Jeff's two suggestions seem like a good idea in any case. We always have Flash lurking in the shadows that no one is really going to ever fix. The problem I see with it is the clipboard is not owned by the browser. Its a system resource. In that sense, it would seem like features the OS would want to implement. Last… if we are only concerned about Paste, then perhaps we should focus on a trusted receiver rather than a trusted and semi trusted events -- although I think that is going to be just as weak. Perry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [clipboard] Semi-Trusted Events Alternative
On Jul 22, 2014, at 3:17 PM, Ben Peters ben.pet...@microsoft.com wrote: Semi-trusted events in the Clipboard API spec [1] are a potential solution to an important problem- sites should be able to use the same infrastructure (clipboard events) with their own triggers (button with execCommand(‘paste’) as browser initiated clipboard operations (like user presses control+v or uses the context menu’s ‘paste’ option). However, I don’t really know if ‘semi-trusted’ events are the solution. Users will almost certainly be using the keyboard or mouse with websites, so requiring an event to originate from keyboard or mouse doesn’t seem to make them trusted at all. I know there has been some discussion of removing them from the spec [2]. I agree. Users are going to click on somewhere in the page while browsing. I don’t see how, selecting a line of text, clicking on a hyperlink, or pressing the down arrow key to scroll etc… could lead to indicate the user’s intention to expose the clipboard/pasteboard’s content to the web page. I, as an user, certainly wouldn’t expect that to happen. As an alternative to semi-trusted events, perhaps we should have something similar to input type=”file”? Perhaps a new input type that must display a localized word for “cut”, “copy”, or “paste”, and must not be occluded by any other element, could trigger real, trusted clipboard events? I’m not sure how this would work, but it seems worth a discussion at least. I think the challenge here is that the input=file brings up a dialog to choose a file whereas copy/paste doesn’t typically show such an UI and guaranteeing that the element isn’t occluded is that easy to determine for user agents. On the other hand, if we added a new element that’s guaranteed to be displayed on top of all other elements (e.g. like a dialog element) then that might work. - R. Niwa
