Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[dgraham]

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 
> , 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 
> , 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")

[Ehsan Akhgari]

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")

[Neil Deakin]

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:






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")

[Jesper Kristensen]

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")

[Ted Mielczarek]

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")

[Karl Tomlinson]

> 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")

[Ehsan Akhgari]

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")

[Jesper Kristensen]

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: , 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")

[Robert O'Callahan]

On Sat, May 23, 2015 at 5:21 AM, Ehsan Akhgari 
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")

[Ehsan Akhgari]

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")

[tim]

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")

[Adam Roach]

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 
 
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")

[Ehsan Akhgari]

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 
, 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 
, 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")

[Ehsan Akhgari]

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 
 
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")

[Ehsan Akhgari]

On 2015-05-06 6:48 PM, Tantek Çelik wrote:

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson  wrote:

On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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")

[Ehsan Akhgari]

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")

[Tantek Çelik]

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson  wrote:
> On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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")

[Martin Thomson]

On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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")

[Neil Deakin]

On 2015-05-06 2:38 PM, Adam Roach wrote:


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.


It isn't possible, no. Only the type of data is known to the clipboard. 
The data itself is opaque and, in most cases, not actually determined 
until it is pasted. You could handle some specific trivial cases, but i 
don't think this is an avenue worth exploring.


___
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")

[Adam Roach]

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")

[Gervase Markham]

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")

[Mike Taylor]

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] 

[2] 



--
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")

[Adam Roach]

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")

[Jonas Sicking]

On Wed, May 6, 2015 at 10:08 AM, Anne van Kesteren  wrote:
> On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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.

But the argument here is "if websites had access to write to the
clipboard, they will do horrible things X, Y and Z". However that
argument is fairly easily disproven by looking at websites that exist
today.

Also keep in mind that for any well behaving websites, limiting the
ability to write to the clipboard is an annoyance for users. The
reason this feature is getting added is because *users* are annoyed
that they have to use keyboard shortcuts to copy data. I would argue
that users visit far more well behaving websites, than once that don't
care about user experience.

Like Ehsan, I don't see what advantages limiting this to https brings?

/ 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")

[Jonas Sicking]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  wrote:
>
>> On May 6, 2015, at 7:30 AM, Tantek Çelik  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 
> , 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")

[Gervase Markham]

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")

[dgraham]

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: , 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")

[Justin Dolske]

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")

[Tom Schuster]

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  wrote:

> On Wed, May 6, 2015 at 6:40 PM, Adam Roach  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")

[James Graham]

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
 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")

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:40 PM, Adam Roach  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")

[Ehsan Akhgari]

On 2015-05-06 1:08 PM, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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")

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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")

[James Graham]

On 06/05/15 18:08, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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")

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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")

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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")

[Ehsan Akhgari]

On 2015-05-06 3:00 AM, Tantek Çelik wrote:

On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari  wrote:

On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik  wrote:


On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari 
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 benefit from this 
effort.  Even worse, they may start t

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Mike Taylor]

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] 

--
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")

[Tantek Çelik]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson  wrote:
> On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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")

[Anne van Kesteren]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson  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")

[Martin Thomson]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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")

[Doug Turner]

> On May 6, 2015, at 7:30 AM, Tantek Çelik  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 , 
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")

[Tantek Çelik]

On Wed, May 6, 2015 at 10:51 AM, Gervase Markham  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")

[Gervase Markham]

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")

[Tantek Çelik]

On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari  wrote:
> On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik  wrote:
>>
>> On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari 
>> 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")

[Ehsan Akhgari]

On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik  wrote:

> On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari 
> 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")

[Tantek Çelik]

On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari  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")

[Ehsan Akhgari]

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

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Daniel Holbert]

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.)

Looking forward to not needing flash for this anymore!

~Daniel

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1149593#c1
___
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")

[Jet Villegas]

\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 
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: , 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")

[Robert O'Callahan]

On Wed, May 6, 2015 at 9:51 AM, 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.
>

Sounds great!

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

Intent to implement and ship: document.execCommand("cut"/"copy")

[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: , 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