Re: Intent to implement and ship: document.execCommand(cut/copy)
We enabled native copy-to-clipboard on github.com today for Firefox Nightly
visitors. The copy buttons no longer use a Flash widget in Nightly or Chrome!
Thanks so much for working on this, Ehsan.
David
On Wednesday, May 6, 2015 at 7:42:23 PM UTC-6, Ehsan Akhgari wrote:
On 2015-05-06 2:51 PM, Mike Taylor wrote:
Hey David,
On 5/6/15 13:09, dgra...@github.com wrote:
Although IE 11 supports this API as well, we have not enabled it yet.
The browser displays a popup dialog asking the user for permission to
copy to the clipboard. Hopefully this popup is removed in Edge so we
can start using JS there too. I just haven't had a chance to test with
it yet.
Thanks for mentioning this--I suspect other sites would also fall back
to Flash if our UX is similarly annoying.
Thanks David, this is really helpful. I also agree that showing UI for
this feature decreases the usability to a degree that the Flash
alternative may be preferred.
Right now, there isn't a reliable way to feature detect for this API
in JS. We use user agent detection instead, just for this feature. Any
suggestions here would be much appreciated.
You can use the document.queryCommandSupported()[1] or
document.queryCommandEnabled()[2] APIs to check for support.
So technically queryCommandSupported is the right way to feature detect
this. Note that currently our implementation of queryCommandSupported
is buggy and it returns true for all of the command names that we know
of, including cut, copy and paste. Over in
https://bugzilla.mozilla.org/show_bug.cgi?id=1161721, we'll fix our
implementation so that we return true for cut and copy and false for
paste. So in Firefox, you'd be able to feature detect like this:
function isSupported() {
return document.queryCommandSupported(copy)
!document.queryCommandSupported(paste);
}
Chrome's implementation of this function is affected by
https://code.google.com/p/chromium/issues/detail?id=476508, but it
seems like it is getting fixed. I have not tested IE's implementation
of queryCommandSuported yet.
Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Mon, May 25, 2015, at 11:04 AM, Ehsan Akhgari wrote: On 2015-05-23 5:02 AM, Jesper Kristensen wrote: Very nice, I am looking very much forward to using this. It would be nice of you could also support paste. I agree that it is more sensitive, so maybe you could go with a user prompt in that case? The prompts as implemented in IE are horrible, but I think there could be many better ways of doing it. Here is one way I have thought of how a prompt could look like, since you only allow it in relation to user interaction, you could make a prompt that looks like a context menu for the element the user interacted with, using a single word describing the action. I have implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure Mozilla UX people could come up with better ways to do this. (My mockup has a prompt for all three actions, but you could do it for paste only) Handling paste is a difficult topic, and I definitely don't have a good answer yet. Additionally, the 'paste' event from the spec already works, which seems like it provides pretty useful functionality for webapps. The user can use Ctrl+V or Edit-Paste or whatever existing UI mechanism the browser has to trigger a paste, and the page can handle the event to do something useful with the pasted data. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-26 10:42 AM, Jesper Kristensen wrote: Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek: Additionally, the 'paste' event from the spec already works, which seems like it provides pretty useful functionality for webapps. The user can use Ctrl+V or Edit-Paste or whatever existing UI mechanism the browser has to trigger a paste, and the page can handle the event to do something useful with the pasted data. The same can be said about cut and copy. I don't think it will work for my use case. Here is my use case: I have a web application that allows the user to upload tabular data. Users most often prepare the data in Excel or other spreadsheet applications before uploading the data. My application supports a CSV file upload, but it is slow to use, since you have to copy the section you which to upload into a separate spreadsheet, save it as a file, go into the web application and find the same file, upload it, and then delete the temporary file. You also get issues with character encoding when saving as CSV from Excel. As a quicker solution the web application allows the user to copy-paste the relevant section of their excel file into the web application, which takes much fewer steps. However users often need to paste large amounts of data (millions of cells), which will make the browser freeze while it tries to render the pasted text in the textarea. It would be much faster if I could just present a Paste data or Upload from clipboard button, which could load the data from the clipboard directly into a JavaScript string without first trying to render it. I feel that doing this by handling the paste event on a text area would be a confusing user experience, since you would have a visible text area that would not work when you type into it, and it looks like you would see your text when you paste, but you won't. So I believe I need to trigger the paste event when the user clicks a button in order to do this. People have used tricks with invisible text areas for other similar use cases. One example that comes to my mind is some editor widgets which place a transparent text area where the current caret should be in order to paint the caret and also receive an input event when the user types a character, but of course this is a gross hack at best... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-26 10:42 AM, Jesper Kristensen wrote:
It would be much faster if I could just present a Paste data or
Upload from clipboard button, which could load the data from the
clipboard directly into a JavaScript string without first trying to
render it. I feel that doing this by handling the paste event on a text
area would be a confusing user experience, since you would have a
visible text area that would not work when you type into it, and it
looks like you would see your text when you paste, but you won't. So I
believe I need to trigger the paste event when the user clicks a button
in order to do this.
Your use case is the intended use of the paste event and doesn't require
a separate button.
The following, for example, pastes only the first letter of the text on
the clipboard:
input onpaste=this.value =
event.clipboardData.getData('text/plain')[0]; event.preventDefault()
What you can't do though is have two separate types of pastes, such as a
normal Paste and a Paste Without Formatting type of option, although you
could workaround this with a toggle that needs to be clicked first.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek: Additionally, the 'paste' event from the spec already works, which seems like it provides pretty useful functionality for webapps. The user can use Ctrl+V or Edit-Paste or whatever existing UI mechanism the browser has to trigger a paste, and the page can handle the event to do something useful with the pasted data. The same can be said about cut and copy. I don't think it will work for my use case. Here is my use case: I have a web application that allows the user to upload tabular data. Users most often prepare the data in Excel or other spreadsheet applications before uploading the data. My application supports a CSV file upload, but it is slow to use, since you have to copy the section you which to upload into a separate spreadsheet, save it as a file, go into the web application and find the same file, upload it, and then delete the temporary file. You also get issues with character encoding when saving as CSV from Excel. As a quicker solution the web application allows the user to copy-paste the relevant section of their excel file into the web application, which takes much fewer steps. However users often need to paste large amounts of data (millions of cells), which will make the browser freeze while it tries to render the pasted text in the textarea. It would be much faster if I could just present a Paste data or Upload from clipboard button, which could load the data from the clipboard directly into a JavaScript string without first trying to render it. I feel that doing this by handling the paste event on a text area would be a confusing user experience, since you would have a visible text area that would not work when you type into it, and it looks like you would see your text when you paste, but you won't. So I believe I need to trigger the paste event when the user clicks a button in order to do this. /Jesper Kristensen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-23 5:02 AM, Jesper Kristensen wrote: Very nice, I am looking very much forward to using this. It would be nice of you could also support paste. I agree that it is more sensitive, so maybe you could go with a user prompt in that case? The prompts as implemented in IE are horrible, but I think there could be many better ways of doing it. Here is one way I have thought of how a prompt could look like, since you only allow it in relation to user interaction, you could make a prompt that looks like a context menu for the element the user interacted with, using a single word describing the action. I have implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure Mozilla UX people could come up with better ways to do this. (My mockup has a prompt for all three actions, but you could do it for paste only) Handling paste is a difficult topic, and I definitely don't have a good answer yet. Prompting for paste has two issues: 1. I'm not sure if we can express a useful message allowing the user to make a good decision, since explaining the risk would be difficult. It will also be an annoying prompt since we would have to show it every time that the page wants to paste, since the contents of the clipboard may be different. (It may be OK to persist a permission for websites served from secure origins without undermining the user's security, but still, the problem of asking the user a meaningful question to them remains to be solved.) 2. The synchronous nature of the execCommand API mandates a modal prompt, which is terrible for user experience, so we would probably need some kind of an out of band permission request. But that may make the permission prompt less obvious since the website may call into the out-of-band permission requesting API at a time that is unrelated to the user trying to paste, which will make it even less obvious what the page is asking for. On the question of the specific form the prompt would take, I'm very hesitant to overlay something on top of the content, since web developers typically hate it when the browser does that, as they may have specific requirements and needs over what appears in the content area. But that is probably a relatively easier issue to solve than the above two problems. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-23 5:02 AM, Jesper Kristensen wrote: It would be nice of you could also support paste. Ehsan Akhgari writes: Handling paste is a difficult topic, and I definitely don't have a good answer yet. Prompting for paste has two issues: 2. The synchronous nature of the execCommand API mandates a modal prompt, which is terrible for user experience, so we would probably need some kind of an out of band permission request. A synchronous API would be a problem for pasting even without the prompt, unless perhaps pasting data only from within the same process. Fetching the clipboard from another application, or process, is an intrinsically asynchronous operation. Attempts have been made, with varying degrees of success, to dress up the asynchronous fetch as a synchronous operation. DataTransfer usage may have the luxury of being able to pre-fetch the data in all formats before dispatching the event referencing the DataTransfer, which despite the inefficiencies can provide a synchronous API. I'm not familiar with execCommand, but sounds like even that would not be possible. We shouldn't expose any more asynchronous operations in synchronous APIs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Very nice, I am looking very much forward to using this. It would be nice of you could also support paste. I agree that it is more sensitive, so maybe you could go with a user prompt in that case? The prompts as implemented in IE are horrible, but I think there could be many better ways of doing it. Here is one way I have thought of how a prompt could look like, since you only allow it in relation to user interaction, you could make a prompt that looks like a context menu for the element the user interacted with, using a single word describing the action. I have implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure Mozilla UX people could come up with better ways to do this. (My mockup has a prompt for all three actions, but you could do it for paste only) /Jesper Kristensen Den 05-05-2015 kl. 23:51 skrev Ehsan Akhgari: Summary: We currently disallow programmatic copying and cutting from JS for Web content, which has relied on web sites to rely on Flash in order to copy content to the clipboard. We are planning to relax this restriction to allow this when execCommand is called in response to a user event. This restriction mimics what we do for other APIs, such as FullScreen. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012662 Link to standard: This is unfortunately not specified very precisely. There is a rough spec here: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands and the handling of clipboard events is specified here: https://w3c.github.io/clipboard-apis/. Sadly, the editing spec is not actively edited. We will strive for cross browser interoperability, of course. Platform coverage: All platforms. Target release: Firefox 40. Preference behind which this will be implemented: This won't be hidden behind a preference, as the code changes required are not big, and can be easily reverted. DevTools bug: N/A Do other browser engines implement this: IE 10 and Chrome 43 both implement this. Opera has adopted this from Blink as of version 29. Security Privacy Concerns: We have discussed this rather extensively before: http://bit.ly/1zynBg7, and have decided that restricting these functions to only work in response to user events is enough to prevent abuse here. Note that we are not going to enable the paste command which would give applications access to the contents of the clipboard. Web designer / developer use-cases: This feature has been rather popular among web sites. Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. Cheers, ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Sat, May 23, 2015 at 5:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: And that is exactly the point I have been trying to make. The potential for abuse definitely exists today, with Flash. And so far we have no evidence that this is an issue in practice today. At the very least, by allowing web developers to use the API implemented in the browser engine, we will have some chance of reacting to this abusive behavior becoming a problem in practice in the future, but if we hamper the user experience by doing things such as displaying a prompt, Web developers will just continue to use Flash at least on desktop where it's widely available, and we wouldn't have a good way to react to this problem if it proves to be a practical issue. Therefore, I remain unconvinced that we need to display a prompt for this API. I think this is completely correct. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-20 9:41 PM, t...@bocoup.com wrote: I am not sure if this is the right avenue to raise concern (again) over not requiring a prompt. It seems that user action here implies that a user intended on having their clipboard destroyed intentionally. (Like requesting a SHA from GitHub). No, I never meant to imply that. The only level of protection that we're implementing is to make it impossible for the page to do this when it's not being interacted with (for example, if you have the page open in the background.) However, I created a very basic demo here: http://jsfiddle.net/azgugmjb/3/ that shows how easy (in Chrome 43) it is to abuse the user action. I really hope this shines some light on the potential for real world abuse. The user action in my demo is simply highlighting text. The use of `.select()` prevents the user from actually using the system keybinding for copying and will inject into their clipboard something other than what they intended. Yes, but you could construct a similar test case for copying something through Flash by for example placing a transparent Flash movie in front of that text and simulate the visual selection yourself, or rendering the text in the Flash movie itself, etc. And that is exactly the point I have been trying to make. The potential for abuse definitely exists today, with Flash. And so far we have no evidence that this is an issue in practice today. At the very least, by allowing web developers to use the API implemented in the browser engine, we will have some chance of reacting to this abusive behavior becoming a problem in practice in the future, but if we hamper the user experience by doing things such as displaying a prompt, Web developers will just continue to use Flash at least on desktop where it's widely available, and we wouldn't have a good way to react to this problem if it proves to be a practical issue. Therefore, I remain unconvinced that we need to display a prompt for this API. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
I am not sure if this is the right avenue to raise concern (again) over not requiring a prompt. It seems that user action here implies that a user intended on having their clipboard destroyed intentionally. (Like requesting a SHA from GitHub). However, I created a very basic demo here: http://jsfiddle.net/azgugmjb/3/ that shows how easy (in Chrome 43) it is to abuse the user action. I really hope this shines some light on the potential for real world abuse. The user action in my demo is simply highlighting text. The use of `.select()` prevents the user from actually using the system keybinding for copying and will inject into their clipboard something other than what they intended. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote: On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Hmm, what would that prevent against though? A web page could just use the normal DOM APIs to destroy the user data (e.g., something like the contents of a blog post the user is writing in a blogging web app). Is this what you had in mind? Sorry I wasn't clear. *Both* cut and copy have the impact of *clearing* the previous clipboard data (on typical platforms). Thus if the user had say, cut a bunch of text from another application (like a text editor), and then switched to a browser window, gotten distracted and clicked something, it is *possible* the page could select text, do a cut/copy, and blow away that bunch of text from the other application. Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 08:00, Tantek Çelik wrote: Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Given that most text-editing applications have undo (if you used cut originally), this strikes me as a low-level web page annoyance on a par with auto-playing irritating music. Although perhaps a little less discoverable as to the cause. I doubt this will be an issue in practice - as the page doesn't get to see the data its deleting, doing so would be pure vandalism, not worthy of an attacker who was trying to actually accomplish something. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 10:51 AM, Gervase Markham g...@mozilla.org wrote: On 06/05/15 08:00, Tantek Çelik wrote: Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Given that most text-editing applications have undo (if you used cut originally), ^^^ desktop assumption. Most (nearly all?) text editing applications and/or applications with editable text fields on *mobile* DO NOT have undo. this strikes me as a low-level web page annoyance on a par with auto-playing irritating music. ^^^ disagreed - no data loss with auto-playing irritating music, just potential embarrassment / emotional annoyance. Although perhaps a little less discoverable as to the cause. Very. Also the silent nature of this vulnerability means user might not notice until long after damage is done. I doubt this will be an issue in practice Perhaps. I might conclude similarly, yet I thought this was worth raising as possible justification for enabling only in secure connections. Also this is a good concrete test-case of our blog post and indication of direction re: features and secured connections. - as the page doesn't get to see the data its deleting, doing so would be pure vandalism, not worthy of an attacker who was trying to actually accomplish something. Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. Though I can understand why there might be some resistance, we don't find out much if we don't ask. I'm going to propose that we at least raise the question with other browsers about restricting this feature to secure contexts. The answer might help inform us on whether pursuing the deprecation plan as outlined is feasible. Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. It would be a shame if the deprecation plan was spoiled simply because features that were considered too useful got exemptions. In this case, I'd say timing would be a valid reason for an exemption. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. I think this is the strongest argument for doing this. Though I can understand why there might be some resistance, we don't find out much if we don't ask. Precisely. The upside: we try out aspects of our proposed policy with very little risk. The possible downside: we get negative feedback from developers, and end up delaying the broader support (whether http or other fewer restrictions) by one release. Given how long people have already waited for this, is this potential delay really that harmful? Especially in exchange for the upside. I'm going to propose that we at least raise the question with other browsers about restricting this feature to secure contexts. This is a reasonable next step. The answer might help inform us on whether pursuing the deprecation plan as outlined is feasible. Exactly, we get to start trying out parts of the plan at relatively low risk. Like a drill of sorts. Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. Based on the arguments presented in this thread, I have been convinced of this too (tangible but small). Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote: Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Note that we're changing that: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. I like this idea. Although I wonder if users will understand what is happening. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 13:32, Jonas Sicking wrote: Like Ehsan, I don't see what advantages limiting this to https brings? In some ways, that depends on what we decide to define new features to mean, and the release date of this feature relative to the date we settle on in the announced security plan [1] of Setting a date after which all new features will be available only to secure websites. If we use the example definition of new features to mean features that cannot be polyfilled, then this would qualify. Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. [1] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 3:00 AM, Tantek Çelik wrote: On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote: On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Hmm, what would that prevent against though? A web page could just use the normal DOM APIs to destroy the user data (e.g., something like the contents of a blog post the user is writing in a blogging web app). Is this what you had in mind? Sorry I wasn't clear. *Both* cut and copy have the impact of *clearing* the previous clipboard data (on typical platforms). Thus if the user had say, cut a bunch of text from another application (like a text editor), and then switched to a browser window, gotten distracted and clicked something, it is *possible* the page could select text, do a cut/copy, and blow away that bunch of text from the other application. Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Thanks for the clarification! I have actually already considered this, and I don't think this is a problem that we need to deal with, at least until we have some evidence that it is an actual problem in the wild. Two points to note here: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. Let's look at some of the suggestions in this thread: * Directly promoting the user is a horrible user experience, and given that it is practically impossible to describe what we're asking for them (many users may not even know what a clipboard is, since it has never been exposed in a user-facing way in any OS that I've seen at least), and also because it could be an annoying and pointless question to ask: Would you like website X to be able to copy text so that you can paste it elsewhere? Why would I not want to allow that? Where is the Whatever Button?. :-) * Having a permissions for this is a similarly horrible user experience for similar reasons to prompting, except that we show the permission UI at different times than the prompt UI. Also, if the permission is granted by default, this does very little to protect any of our users anyway. * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. * It may be argued that this attack has not been possible through Web APIs so far, so we should now do something about it now that the implementation is moving from Flash to the browser engine. I think that's a very theoretical view of the world, and is quite insufficient if we believe that this is a real issue worth addressing. Also, a variation of this attack has been possible through the clipboard events on the Web without Flash for a while now. For example, if you press your mouse cursor in a text area and without selecting anything, press Cmd+C, you would typically expect for the contents of the clipboard to remain unchanged. It is possible for a web app to put arbitrary data on the clipboard in that case (and again, with this feature, we have seen no evidence of abuse in the wild so far.) * At least on desktop where Flash is widely available, the real value of this API is giving people a good incentive to move away from using Flash. If the Web alternative is an API that doesn't work in some cases (be it because the user said no to a prompt, disabled a permission, or if the web page is served from a non-secure origin), people will keep using Flash for this, and that eliminates most of the
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 1:08 PM, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. Sure, but this argument doesn't really work in the present tense where Flash has actually not gone away, and is _the_ standard way for copying text to the clipboard. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:36, Tom Schuster wrote: I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. Which is why we wouldn't overwrite the clipboard until the permission was granted :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 13:13, Gervase Markham wrote: On 06/05/15 18:36, Tom Schuster wrote: I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. Which is why we wouldn't overwrite the clipboard until the permission was granted :-) Well, that makes it scantly better than a doorhanger, which is what Martin was objecting to (and I agree with him). The model that we really want here is this thing happened, click here to undo it rather than this think is about to happen, but won't unless you take additional action. I think this position is pretty strongly bolstered by Dave Graham's message about GitHub behavior: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. Basically, requiring the extra step of requiring the user to click on an okay, do it button is high enough friction that the function loses its value. In any case, we should have a better technical exploration of the assertion that restoring a clipboard isn't possible in all cases before we take it as given. A cursory examination of the OS X clipboard API leads me to believe that this would be trivially possible (I believe we can just store the array of pasteboardItems from the NSGeneralPBoard off somewhere so that they can be moved back if necessary). I'd be a little surprised if this weren't also true for Linux and Windows. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hey David, On 5/6/15 13:09, dgra...@github.com wrote: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet. Thanks for mentioning this--I suspect other sites would also fall back to Flash if our UX is similarly annoying. Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated. You can use the document.queryCommandSupported()[1] or document.queryCommandEnabled()[2] APIs to check for support. [1] https://developer.mozilla.org/en-US/docs/Web/API/Document/queryCommandSupported [2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 19:38, Adam Roach wrote: action. I think this position is pretty strongly bolstered by Dave Graham's message about GitHub behavior: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. Is that popup one time only per site, or every time? Basically, requiring the extra step of requiring the user to click on an okay, do it button is high enough friction that the function loses its value. Yeah, I can see that. OK. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote: Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Hi Tantek, This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? If news/media websites are likely to use the clipboard as an ad space, why aren't we seeing that happening now? Remember that this is already possible using flash. But to my knowledge this is not a big problem on the web today. Even on websites that already take the performance hit of initiating the flash plugin. Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config about:config, privacy.trackingprotection.enabled). I definitely think it'd be cool if we had tracking-protection like mechanisms to auto-block various APIs on websites that are bad actors. For example it'd be cool to completely disable the ability to open popups, even from user actions, on websites that use other user interactions as an opportunity to create popups. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. We also need to make a browser that people want to use. This means not regressing the UX compared to what came before, or being markedly worse than other browsers. Adding prompt/permissions UI in this case seems like it is just going to be yet another papercut that will annoy more people than will be pleased because we prevent some rogue website having an unwanted interaction with the clipboard. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:49, Martin Thomson wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turnerdo...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this toabout:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way: https://www.dropbox.com/s/c0sbknrlz4pbybk/Screenshot%202015-05-06%2011.33.42.png?dl=0 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:02 AM, Ehsan Akhgari wrote: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. Well... Did Flash offer sites a way to to this without user interaction? I don't know for sure, but I assumed it had to be invoked by a user action... I remember a couple of popular URL shortener sites using Flash for this, and they always required a conspicuously-extra click on a copy to clipboard button. (Entering full-screen had the same requirement too, IIRC.) I think the web sites do have an incentive to not annoy users claim is dubious too. Some sites certainly do, but we still see widespread annoyance/abuse of features like popups, onbeforeunload traps, playing unexpected audio in background tabs. And some legit sites (eg wendys.com / t-mobile.com) kind of abuse geolocation by prompting for it on every page upon page load. This isn't such a severe problem that we have to completely solve it right away, but I'd hate to see us painted into a corner where we have no options for mitigating abuse or giving our users control. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. One off-the-cuff thought would be to place some reasonable restrictions on the usage (tab must be in foreground, maybe in response to a user interaction), and perhaps provide some (fairly subtle) UI indication of when it's invoked. That at least gives the user a chance to see a clearer cause/effect. Or, along the vein of retroactively revoking permissions -- just keeping a usage log somewhere. That at least enables motivated/SUMO users to be able to discover what site is causing the problem, and then either revoke it off or stop going there. Seems like kind of an interesting idea that would scale to other seldomly-abused permissions... Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:49, Martin Thomson wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
This is great news!
At GitHub, we have support in place for this feature in Chrome already. If you
use a Canary build to visit the site, the copy buttons use the native JS
`execCommand('copy')` API rather than Flash.
Although IE 11 supports this API as well, we have not enabled it yet. The
browser displays a popup dialog asking the user for permission to copy to the
clipboard. Hopefully this popup is removed in Edge so we can start using JS
there too. I just haven't had a chance to test with it yet.
Right now, there isn't a reliable way to feature detect for this API in JS. We
use user agent detection instead, just for this feature. Any suggestions here
would be much appreciated.
It's exciting to see native copy-to-clipboard coming to Firefox. We'll follow
along in Bugzilla and enable it on github.com when it's ready!
David
On Tuesday, May 5, 2015 at 3:52:45 PM UTC-6, Ehsan Akhgari wrote:
Summary: We currently disallow programmatic copying and cutting from JS for
Web content, which has relied on web sites to rely on Flash in order to
copy content to the clipboard. We are planning to relax this restriction
to allow this when execCommand is called in response to a user event. This
restriction mimics what we do for other APIs, such as FullScreen.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012662
Link to standard: This is unfortunately not specified very precisely.
There is a rough spec here:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands
and the handling of clipboard events is specified here:
https://w3c.github.io/clipboard-apis/. Sadly, the editing spec is not
actively edited. We will strive for cross browser interoperability, of
course.
Platform coverage: All platforms.
Target release: Firefox 40.
Preference behind which this will be implemented: This won't be hidden
behind a preference, as the code changes required are not big, and can be
easily reverted.
DevTools bug: N/A
Do other browser engines implement this: IE 10 and Chrome 43 both implement
this. Opera has adopted this from Blink as of version 29.
Security Privacy Concerns: We have discussed this rather extensively
before: http://bit.ly/1zynBg7, and have decided that restricting these
functions to only work in response to user events is enough to prevent
abuse here. Note that we are not going to enable the paste command which
would give applications access to the contents of the clipboard.
Web designer / developer use-cases: This feature has been rather popular
among web sites. Sites such as Github currently use Flash in order to
allow people to copy text to the clipboard by clicking a button in their UI.
Cheers,
--
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hi Tantek, On 5/6/15 10:59, Tantek Çelik wrote: Since we have no legacy to deal with, we can start conservative, and wait for web developer feedback, and iterate accordingly. We're behind IE10 and Chrome 43 in implementing this feature [1], so at some level there will be existing content we need to deal with. Interoperability with how they behave would be a win. Ideally, whatever we do to protect our users can make it back to Hallvord to spec and other implementers to match, otherwise Flash-for-clipboard-access won't be going anywhere. [1] http://updates.html5rocks.com/2015/04/cut-and-copy-commands -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. On Wed, May 6, 2015 at 7:33 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote: Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Note that we're changing that: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. I like this idea. Although I wonder if users will understand what is happening. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:22, James Graham wrote: On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. We also need to make a browser that people want to use. This means not regressing the UX compared to what came before, or being markedly worse than other browsers. Adding prompt/permissions UI in this case seems like it is just going to be yet another papercut that will annoy more people than will be pleased because we prevent some rogue website having an unwanted interaction with the clipboard. Oh, sorry, this is about https. On desktop sites will just use flash rather than https. On mobile they are at least as likely to not support clipboard operations in Firefox as switch to https. Again, users will just get the impression that Firefox is a slightly worse browser, for relatively little gain. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 6:48 PM, Tantek Çelik wrote: On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. I think this is the strongest argument for doing this. FWIW I don't really understand why this question turned into us looking for projects as a test bed for the HTTP deprecation plans. I still don't think you've demonstrated why this is a problem in practice, and why restricting this API to TLS and leaving the possibility to leverage Flash to *literally* achieve the same result on HTTP is an improvement. Though I can understand why there might be some resistance, we don't find out much if we don't ask. Precisely. The upside: we try out aspects of our proposed policy with very little risk. The possible downside: we get negative feedback from developers, and end up delaying the broader support (whether http or other fewer restrictions) by one release. Given how long people have already waited for this, is this potential delay really that harmful? Especially in exchange for the upside. What is it that you're actually proposing? I double read this thread right now and I can't find a mention of a delay period. And what problem are we solving again? Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. Based on the arguments presented in this thread, I have been convinced of this too (tangible but small). What is the argument that convinced you? Protecting against someone MITMing the connection of users who do not have Flash enabled to get them to click somewhere on the page to copy something to the clipboard? (I'm genuinely trying to understand what we're getting out of this.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 1:40 PM, Justin Dolske wrote: On 5/6/15 10:02 AM, Ehsan Akhgari wrote: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. Well... Did Flash offer sites a way to to this without user interaction? No, and as I said in the first email of this thread, neither are we. I think the web sites do have an incentive to not annoy users claim is dubious too. Some sites certainly do, but we still see widespread annoyance/abuse of features like popups, onbeforeunload traps, playing unexpected audio in background tabs. And some legit sites (eg wendys.com / t-mobile.com) kind of abuse geolocation by prompting for it on every page upon page load. I never said that there are no websites that do annoying things. I did say that they have an incentive to not annoy the user, because they typically want the user to spend as much time on their website as possible. Perhaps this is anecdotal, but I don't see examples of the above abuses on the majority of websites that I visit. Also, in this case I can safely make a stringer claim, because there has been years of experience with an equivalent API. This isn't such a severe problem that we have to completely solve it right away, but I'd hate to see us painted into a corner where we have no options for mitigating abuse or giving our users control. As I said in the email that you're replying to, this will actually not paint us into a corner. We can always revisit this decision. Websites will need to have fallbacks for older browsers for a while, and I don't know if Safari plans to implement this yet. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. One off-the-cuff thought would be to place some reasonable restrictions on the usage (tab must be in foreground, maybe in response to a user interaction), and perhaps provide some (fairly subtle) UI indication of when it's invoked. That at least gives the user a chance to see a clearer cause/effect. Please read the original email of the thread again. Perhaps I was not clear enough. This API is going to be restricted to code that runs in response to a user event (which means by definition it is restricted to the foreground tab as well). I don't think we shoiuld show a UI indication because a) such an indication does not exist in any other app and b) it is not clear to me what the user is supposed to do with such an indication. Or, along the vein of retroactively revoking permissions -- just keeping a usage log somewhere. That at least enables motivated/SUMO users to be able to discover what site is causing the problem, and then either revoke it off or stop going there. Seems like kind of an interesting idea that would scale to other seldomly-abused permissions... Before we even begin to think about measures such as this, I would like to see some evidence that this is a problem _in practice_. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 20:32, Ehsan Akhgari wrote: If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. I admit that I didn't real the entire HTTP deprecation plan thread because of the length and the tone of some of the participants, so perhaps I missed this, but reading https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ seems to suggest that there is going to be a date and criteria for what new features mean, but I see no mention of what that date is, or what the definition of new features is. That's why there were two predicates qualifying the statement. My point is that the answer to Jonas' question may -- and I'll emphasize may -- turn on an overarching strategic security policy, rather than the security properties of the feature itself. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 2:55 PM, Adam Roach wrote: On 5/6/15 13:32, Jonas Sicking wrote: Like Ehsan, I don't see what advantages limiting this to https brings? In some ways, that depends on what we decide to define new features to mean, and the release date of this feature relative to the date we settle on in the announced security plan [1] of Setting a date after which all new features will be available only to secure websites. If we use the example definition of new features to mean features that cannot be polyfilled, then this would qualify. Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. I admit that I didn't real the entire HTTP deprecation plan thread because of the length and the tone of some of the participants, so perhaps I missed this, but reading https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ seems to suggest that there is going to be a date and criteria for what new features mean, but I see no mention of what that date is, or what the definition of new features is. So before we come up with a plan for that, I think the security properties of clipboard manipulation are exactly what we need to take into consideration here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 2:51 PM, Mike Taylor wrote:
Hey David,
On 5/6/15 13:09, dgra...@github.com wrote:
Although IE 11 supports this API as well, we have not enabled it yet.
The browser displays a popup dialog asking the user for permission to
copy to the clipboard. Hopefully this popup is removed in Edge so we
can start using JS there too. I just haven't had a chance to test with
it yet.
Thanks for mentioning this--I suspect other sites would also fall back
to Flash if our UX is similarly annoying.
Thanks David, this is really helpful. I also agree that showing UI for
this feature decreases the usability to a degree that the Flash
alternative may be preferred.
Right now, there isn't a reliable way to feature detect for this API
in JS. We use user agent detection instead, just for this feature. Any
suggestions here would be much appreciated.
You can use the document.queryCommandSupported()[1] or
document.queryCommandEnabled()[2] APIs to check for support.
So technically queryCommandSupported is the right way to feature detect
this. Note that currently our implementation of queryCommandSupported
is buggy and it returns true for all of the command names that we know
of, including cut, copy and paste. Over in
https://bugzilla.mozilla.org/show_bug.cgi?id=1161721, we'll fix our
implementation so that we return true for cut and copy and false for
paste. So in Firefox, you'd be able to feature detect like this:
function isSupported() {
return document.queryCommandSupported(copy)
!document.queryCommandSupported(paste);
}
Chrome's implementation of this function is affected by
https://code.google.com/p/chromium/issues/detail?id=476508, but it
seems like it is getting fixed. I have not tested IE's implementation
of queryCommandSuported yet.
Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote: Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Hi Tantek, This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config about:config, privacy.trackingprotection.enabled). Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote: A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. The worry was about your clipboard getting spammed, but I agree. HTTPS does make sense so at least the network cannot get to your clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) This I like a lot too, provided about:permissions moves into about:preferences and gets a redesign... One can dream. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, Thanks Doug. I think your first two suggestions are an excellent start. Since we have no legacy to deal with, we can start conservative, and wait for web developer feedback, and iterate accordingly. Thus, straw proposal, let's use your first two: * mitigate by requiring https * only allowing the top level document access these clipboard apis And then if developers complain about either of these restrictions in practice, then hopefully they'll come with specific use-cases for us to consider. and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Agreed. Making this conditional on an engagement gesture seems about right. Agreed on that too. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Having lost clipboard data personally - I think this is an actual issue. Ask forgiveness, not permission seems about the right balance here. I'd phrase it in a more user-centric manner, that is, a user interface should be forgiving of user mistakes, rather than asking permission. Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote: On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Hmm, what would that prevent against though? A web page could just use the normal DOM APIs to destroy the user data (e.g., something like the contents of a blog post the user is writing in a blogging web app). Is this what you had in mind? -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
\o/ Great to see this come through. Shumway was already using this but needed chrome privilege to do so. It's nice to open it up. --Jet On Tue, May 5, 2015 at 2:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Summary: We currently disallow programmatic copying and cutting from JS for Web content, which has relied on web sites to rely on Flash in order to copy content to the clipboard. We are planning to relax this restriction to allow this when execCommand is called in response to a user event. This restriction mimics what we do for other APIs, such as FullScreen. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012662 Link to standard: This is unfortunately not specified very precisely. There is a rough spec here: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands and the handling of clipboard events is specified here: https://w3c.github.io/clipboard-apis/. Sadly, the editing spec is not actively edited. We will strive for cross browser interoperability, of course. Platform coverage: All platforms. Target release: Firefox 40. Preference behind which this will be implemented: This won't be hidden behind a preference, as the code changes required are not big, and can be easily reverted. DevTools bug: N/A Do other browser engines implement this: IE 10 and Chrome 43 both implement this. Opera has adopted this from Blink as of version 29. Security Privacy Concerns: We have discussed this rather extensively before: http://bit.ly/1zynBg7, and have decided that restricting these functions to only work in response to user events is enough to prevent abuse here. Note that we are not going to enable the paste command which would give applications access to the contents of the clipboard. Web designer / developer use-cases: This feature has been rather popular among web sites. Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. Bugzilla does this, too! [1] (If you enable experimental user interface in your account's General Preferences.) Good point! Filed bug 1161797 for that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
