Expose execCommand clipboard commands to apps?

[Tim Chien]

Hi all,

Forgive me on lake of knowledge on the history of the topic.

The soon-to-be-released FxOS copy-and-paste UX spec contains a use
case where, instead of having application controlling the selectable
area, have the application send the content to clipboard directly with
an API method.

There was an old API behind a security pref, as documented here
https://developer.mozilla.org/en-US/docs/Midas/Security_preferences
and the capability was removed last year with bug 913734.

I wonder if the situation on mobile and app permissions and etc is
changed enough for us to re-evaluation all that?

--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Ehsan Akhgari]

On 2014-07-15, 12:41 AM, Tim Chien wrote:
> Hi all,
>
> Forgive me on lake of knowledge on the history of the topic.
>
> The soon-to-be-released FxOS copy-and-paste UX spec contains a use
> case where, instead of having application controlling the selectable
> area, have the application send the content to clipboard directly with
> an API method.
>
> There was an old API behind a security pref, as documented here
> https://developer.mozilla.org/en-US/docs/Midas/Security_preferences
> and the capability was removed last year with bug 913734.
>
> I wonder if the situation on mobile and app permissions and etc is
> changed enough for us to re-evaluation all that?

The reason why this is hidden behind a chrome privilege check is to make
sure that websites are not able to read or modify the contents of the
clipboard.

Reading the clipboard has potential privacy implications. For example,
the user may copy their phone number in one application, and we don't
want to have a web page which just sits there polling the content of the
clipboard to be able to read it. And things will get worse if we're
talking about a credit card number. Writing to the clipboard can
clobber the content that the user put on the clipboard explicitly, so
it's annoying, but probably not privacy/security sensitive.

I think what we should do is to dispatch the copy event when the user
makes a copy operation through the UI and let the application manipulate
the clipboardData property on the event object if it wants to put custom
data on the clipboard as part of the copy operation.

Does that sound like a good solution? If not, do you mind describing
the use case please?

Cheers,
Ehsan

[Boris Zbarsky]

On 7/15/14, 2:50 PM, Ehsan Akhgari wrote:
> Writing to the clipboard can
> clobber the content that the user put on the clipboard explicitly, so
> it's annoying, but probably not privacy/security sensitive.

It becomes a problem if the user then pastes the result into their
terminal. But there are other ways to mess with that. :(

-Boris

[Ehsan Akhgari]

Right.

I'll also note that while browsers have been very cautious about the
clipboard, Flash has been exposing this for years now, and in practice
people have been relying on that on desktop for quite some time now.

Cheers,
Ehsan

[Tim Chien]

Ehsan,

Thanks for the quick reply. The DRAFT spec can be seem here:
https://docs.google.com/a/mozilla.com/file/d/0B9B_TWf-R7HGQUhMMzV4VVNfYUE/edit
(I will remove the file once Omega officially release it)

Please look at page 3, where the copy button is drawn by the
application, not the system. There isn't a place for the system to
initiate copy event (and the actual copy-to-clipboard) on behave of
the user, unfortunately.

On Wed, Jul 16, 2014 at 2:50 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2014-07-15, 12:41 AM, Tim Chien wrote:
>>
>> Hi all,
>>
>> Forgive me on lake of knowledge on the history of the topic.
>>
>> The soon-to-be-released FxOS copy-and-paste UX spec contains a use
>> case where, instead of having application controlling the selectable
>> area, have the application send the content to clipboard directly with
>> an API method.
>>
>> There was an old API behind a security pref, as documented here
>> https://developer.mozilla.org/en-US/docs/Midas/Security_preferences
>> and the capability was removed last year with bug 913734.
>>
>> I wonder if the situation on mobile and app permissions and etc is
>> changed enough for us to re-evaluation all that?
>
>
> The reason why this is hidden behind a chrome privilege check is to make
> sure that websites are not able to read or modify the contents of the
> clipboard.
>
> Reading the clipboard has potential privacy implications. For example, the
> user may copy their phone number in one application, and we don't want to
> have a web page which just sits there polling the content of the clipboard
> to be able to read it. And things will get worse if we're talking about a

> credit card number. Writing to the clipboard can clobber the content that

> the user put on the clipboard explicitly, so it's annoying, but probably not
> privacy/security sensitive.
>

> I think what we should do is to dispatch the copy event when the user makes
> a copy operation through the UI and let the application manipulate the
> clipboardData property on the event object if it wants to put custom data on
> the clipboard as part of the copy operation.
>
> Does that sound like a good solution? If not, do you mind describing the
> use case please?
>
> Cheers,
> Ehsan

[Tim Chien]

Please find the spec (and future updates) in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037286

[Ehsan Akhgari]

Hmm, is this targeted at certified apps, packaged apps or web pages?

I'm fine with relaxing this restriction on the first two. Relaxing it
for web pages requires a bit more thought...

[Tim Chien]

The FxOS UX team is only responsible of Gaia apps, so relaxing this to
certified apps will fit their use cases.

However in terms of enabling the ecosystem, we can make our own
decision on exposing to all packaged apps.

[Ehsan Akhgari]

I thought about this more, and I think I would be open towards exploring
exposing these APIs to all web pages with a certain restriction. Most
of the concerns associated with the abuse of this API are about pages
that call into the API "behind the user's back". In some other APIs
such as the full screen API, we have a restriction to only allow the
functionality to be exposed if the API is called as part of the handler
for a user generated event (such as a key press or a click/touch.) I
think it would be nice to see if we can expose this API with a similar
restriction to all web pages (including packaged apps) across the board.

Do you know someone who is willing to invest some time into this? I can
help them get started. I don't think it should be a lot of work, we
basically need to research what other UAs do right now, and then send a
proposal to public-webapps to see if others are interested to modify
their behavior similarly.

Cheers,
Ehsan

[Dale Harvey]

I just wanted to add a yes please

Outside of the requirement of Firefox OS, the inability to provide a
reasonably copy and paste solution has been a long time nightmare when
building web applications and something I have suffered with a lot in the
past.

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Paul Theriault]

On 22 Jul 2014, at 4:22 am, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> I thought about this more, and I think I would be open towards exploring exposing these APIs to all web pages with a certain restriction. Most of the concerns associated with the abuse of this API are about pages that call into the API "behind the user's back". In some other APIs such as the full screen API, we have a restriction to only allow the functionality to be exposed if the API is called as part of the handler for a user generated event (such as a key press or a click/touch.) I think it would be nice to see if we can expose this API with a similar restriction to all web pages (including packaged apps) across the board.
>
> Do you know someone who is willing to invest some time into this?
> I can help them get started. I don't think it should be a lot of work, we basically need to research what other UAs do right now, and then send a proposal to public-webapps to see if others are interested to modify their behavior similarly.

My team can help with this.

[Frederik Braun]

I'm thinking the copy event is a tad easier to solve. We have to ask the
web page in case it wants to strip data from tags or something.

The paste thing is more interesting. I'm not sure if this is going to be
something that UX is OK with, but it would be easier to secure if paste
would require interaction with a chrome URI, that shows up when
long-pressing something editable (input, textarea ..). Application
requesting pastedata just on a call seems tricky.

I also like Ehsan's idea to require a trusted event, but on Firefox OS
isn't everything the user does a trusted event which could be used?


Just my first 2 cents -
I'll try to dig in a bit more later.
Freddy

On 21.07.2014 20:22, Ehsan Akhgari wrote:
> I thought about this more, and I think I would be open towards exploring
> exposing these APIs to all web pages with a certain restriction. Most
> of the concerns associated with the abuse of this API are about pages
> that call into the API "behind the user's back". In some other APIs
> such as the full screen API, we have a restriction to only allow the
> functionality to be exposed if the API is called as part of the handler
> for a user generated event (such as a key press or a click/touch.) I
> think it would be nice to see if we can expose this API with a similar
> restriction to all web pages (including packaged apps) across the board.
>
> Do you know someone who is willing to invest some time into this? I can
> help them get started. I don't think it should be a lot of work, we
> basically need to research what other UAs do right now, and then send a
> proposal to public-webapps to see if others are interested to modify
> their behavior similarly.
>

[Tim Chien]

Ping. Do we have a proposal here yet?

[Ehsan Akhgari]

(Sorry for the late reply, this email was caught in my backlong...)

On 2014-07-24, 8:39 AM, Frederik Braun wrote:
>
>
> I'm thinking the copy event is a tad easier to solve. We have to ask the
> web page in case it wants to strip data from tags or something.

The page already gets a chance to modify what goes on the clipboard, for
example:

window.addEventListener("copy", function(e) {
e.clipboardData.set("text", "copy this instead");
e.preventDefault();
}, false);

> The paste thing is more interesting. I'm not sure if this is going to be
> something that UX is OK with, but it would be easier to secure if paste
> would require interaction with a chrome URI, that shows up when
> long-pressing something editable (input, textarea ..). Application
> requesting pastedata just on a call seems tricky.

Well, my point is that there is not a lot of security risks in allowing
paste. We already sanitize the tags and attributes that can run code
(for example, script tags and event handler attributes).

> I also like Ehsan's idea to require a trusted event, but on Firefox OS
> isn't everything the user does a trusted event which could be used?

Not sure what you mean here by the trusted event. My idea was to enable
document.execCommand("copy"/"paste") *if* the execCommand function is
called in response to a user initiated event (a touch event, a key press
etc.) in order to prevent the page from calling these APIs when it's
idle. The basic idea is that there is no good reason why the page would
want to call these APIs if the user is not interacting with the page.

How does that sound?

Cheers,
Ehsan

[Ehsan Akhgari]

(CCing dev-webapi again)


On Fri, Aug 15, 2014 at 3:12 AM, Frederik Braun <fbr...@mozilla.com> wrote:

> On 14.08.2014 17:08, Ehsan Akhgari wrote:
> > (Sorry for the late reply, this email was caught in my backlong...)
> >
> >
> > On 2014-07-24, 8:39 AM, Frederik Braun wrote:
> >>
> >>
> >> I'm thinking the copy event is a tad easier to solve. We have to ask the
> >> web page in case it wants to strip data from tags or something.
> >
> > The page already gets a chance to modify what goes on the clipboard, for
> > example:
> >
> > window.addEventListener("copy", function(e) {
> > e.clipboardData.set("text", "copy this instead");
> > e.preventDefault();
> > }, false);
> >
> >> The paste thing is more interesting. I'm not sure if this is going to be
> >> something that UX is OK with, but it would be easier to secure if paste
> >> would require interaction with a chrome URI, that shows up when
> >> long-pressing something editable (input, textarea ..). Application
> >> requesting pastedata just on a call seems tricky.
> >
> > Well, my point is that there is not a lot of security risks in allowing
> > paste. We already sanitize the tags and attributes that can run code
> > (for example, script tags and event handler attributes).
> >
>

> Oh, yes.
> I wasn't too concerned with unsanitized data.
> I was concerned that malicious apps might poll the clipboard for
> interesting information and use those that match a certain pattern
> (credit cards, email addresses) for evil.
> If I copy something from App1 to App2, I would prefer if App3 didn't
> have the chance to poll the clipboard.
>

If we restrict the commands to only work as a response to a user initiated
action, then that problem goes away. This is basically why my idea is
useful.

> >> I also like Ehsan's idea to require a trusted event, but on Firefox OS
> >> isn't everything the user does a trusted event which could be used?
> >
> > Not sure what you mean here by the trusted event. My idea was to enable
> > document.execCommand("copy"/"paste") *if* the execCommand function is
> > called in response to a user initiated event (a touch event, a key press
> > etc.) in order to prevent the page from calling these APIs when it's
> > idle. The basic idea is that there is no good reason why the page would
> > want to call these APIs if the user is not interacting with the page.
> >
>

> So, it seems we agree? I, too, think we should require event.isTrusted
> to be true.
>

event.isTrusted would be true if the user presses Ctrl+C for example, and
it would be false if the web page runs execCommand("copy"). (But I'm not
sure why isTrusted matters here.)


> There's a lot of tap, touch and click in a mobile interface. A popular
> ap that is used regularly, could still poll the clipboard. But that's
> not as bad as an evil app lurking in the background! :)
>

Yes that will remain a possibility. Note that with Flash exposing this
functionality on desktop, this _has_ been a possibility since forever. I
am not aware of a lot of abuses from this in the wild.


> > How does that sound?
> >
>
> I'm convinced this is going in a good direction. I just wonder if
> Firefox OS (gaia) should provide a user interface, so we have strong
> visual clues about what's going on.
> I'd hate if every app had to bring their own select, copy and paste
> buttons.
>

I thought the idea is to let the system app render some kind of UI on top
of the app which provides this functionality by default, so that would give
us the default OS level UI.

Cheers,
Ehsan

[Paul Theriault]

So I did some research on other flash on other UAs currently allow, replies in line.

So to be clear Ehsan, are you only proposing to allow writing to the clipboard in response to a user-initiated action? FWIW that is the approach that Flash currently takes. To contrast, IE requires the user to click yes on a pop-up, but this allows both reading and write access to the clipboard.

If you mean read as well as write to clipboard then this is not safe I think - sensitive data might be left in the clipboard that the user has forgotten about, and would be exposed to the next web page they interacted with. I.e. user copies data from App A, pastes in App B, then visits App C, which also gets the data. (or App C interrupts the user etc).

>
>
>>>> I also like Ehsan's idea to require a trusted event, but on Firefox OS
>>>> isn't everything the user does a trusted event which could be used?
>>>
>>> Not sure what you mean here by the trusted event. My idea was to enable
>>> document.execCommand("copy"/"paste") *if* the execCommand function is
>>> called in response to a user initiated event (a touch event, a key press
>>> etc.) in order to prevent the page from calling these APIs when it's
>>> idle. The basic idea is that there is no good reason why the page would
>>> want to call these APIs if the user is not interacting with the page.
>>>
>>
>> So, it seems we agree? I, too, think we should require event.isTrusted
>> to be true.
>>
>
> event.isTrusted would be true if the user presses Ctrl+C for example, and
> it would be false if the web page runs execCommand("copy"). (But I'm not
> sure why isTrusted matters here.)
>
>
>> There's a lot of tap, touch and click in a mobile interface. A popular
>> ap that is used regularly, could still poll the clipboard. But that's
>> not as bad as an evil app lurking in the background! :)
>>
>
> Yes that will remain a possibility. Note that with Flash exposing this
> functionality on desktop, this _has_ been a possibility since forever. I
> am not aware of a lot of abuses from this in the wild.

As far as I can tell, Flash only exposes the ability to _write_ to the clipboard except for when handling paste events. Also, since a rash of malware in 2008 it only allows writing to the clipboard in response to user interaction (search for “clipboard poisoning" for related media coverage).

>
>>> How does that sound?
>>>
>>
>> I'm convinced this is going in a good direction. I just wonder if
>> Firefox OS (gaia) should provide a user interface, so we have strong
>> visual clues about what's going on.
>> I'd hate if every app had to bring their own select, copy and paste
>> buttons.
>>
>
> I thought the idea is to let the system app render some kind of UI on top
> of the app which provides this functionality by default, so that would give
> us the default OS level UI.

I assume this is the case too from looking at the UX specs, but the system app will need an API fire cut/copy/paste/events so that it can provide this OS level UI, won’t it? Can we just expose execCommand(cut/copy/paste) via a permission to certified apps since we are going to need that level of access for the system app to be able to implement the UI for cut/copy/paste.

This means that only certified apps can do UX as described in the spec [1] can implement buttons as per pages 4 & 5, but honestly Im not a big fan of letting apps create their own clipboard related UX - that seems more like something that should be handled by system UI to me for consistency and learnability, but thats just my opinion.

We might also look at exposing the ability to set the clipboard to user-initiated event loops, but that seems secondary to FxOS requirements, and doesn’t solve all the use cases here.

Thoughts?

[1] https://bug1037286.bugzilla.mozilla.org/attachment.cgi?id=8469849

[Paul Theriault]

>
> I assume this is the case too from looking at the UX specs, but the system app will need an API fire cut/copy/paste/events so that it can provide this OS level UI, won’t it? Can we just expose execCommand(cut/copy/paste) via a permission to certified apps since we are going to need that level of access for the system app to be able to implement the UI for cut/copy/paste.

Howie informs me that this is already implemented, as part of the browser API. I wasn’t aware of this (bug https://bugzilla.mozilla.org/show_bug.cgi?id=987040) but I am looking into this at the moment.

>
> This means that only certified apps can do UX as described in the spec [1] can implement buttons as per pages 4 & 5, but honestly Im not a big fan of letting apps create their own clipboard related UX - that seems more like something that should be handled by system UI to me for consistency and learnability, but thats just my opinion.
>
> We might also look at exposing the ability to set the clipboard to user-initiated event loops, but that seems secondary to FxOS requirements, and doesn’t solve all the use cases here.
>
> Thoughts?
>
> [1] https://bug1037286.bugzilla.mozilla.org/attachment.cgi?id=8469849
>
>
>
>

[Ehsan Akhgari]

On 2014-08-18, 2:21 AM, Paul Theriault wrote:
> So I did some research on other flash on other UAs currently allow,
> replies in line.
>
> On 16 Aug 2014, at 6:25 am, Ehsan Akhgari <ehsan....@gmail.com

Yes. I'm actually proposing to allow *both* reading and writing as a
response to user action.

> If you mean read as well as write to clipboard then this is not safe I
> think - sensitive data might be left in the clipboard that the user has
> forgotten about, and would be exposed to the next web page they
> interacted with. I.e. user copies data from App A, pastes in App B, then
> visits App C, which also gets the data. (or App C interrupts the user
> etc).

Hmm, I'm confused. According to
<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#getData%28%29>,
this is what Flash allows. Are you suggesting that their protection is
too relaxed here?

Are you worried about the types of attacks where they create a game
asking the user to click around and keep reading the clipboard value by
issuing an execCommand("paste") and examining the data on the clipboard
through a paste event handler?

>>>>> I also like Ehsan's idea to require a trusted event, but on Firefox OS
>>>>> isn't everything the user does a trusted event which could be used?
>>>>
>>>> Not sure what you mean here by the trusted event. My idea was to enable
>>>> document.execCommand("copy"/"paste") *if* the execCommand function is
>>>> called in response to a user initiated event (a touch event, a key press
>>>> etc.) in order to prevent the page from calling these APIs when it's
>>>> idle. The basic idea is that there is no good reason why the page would
>>>> want to call these APIs if the user is not interacting with the page.
>>>>
>>>
>>> So, it seems we agree? I, too, think we should require event.isTrusted
>>> to be true.
>>>
>>
>> event.isTrusted would be true if the user presses Ctrl+C for example, and
>> it would be false if the web page runs execCommand("copy"). (But I'm not
>> sure why isTrusted matters here.)
>>
>>
>>> There's a lot of tap, touch and click in a mobile interface. A popular
>>> ap that is used regularly, could still poll the clipboard. But that's
>>> not as bad as an evil app lurking in the background! :)
>>>
>>
>> Yes that will remain a possibility. Note that with Flash exposing this
>> functionality on desktop, this _has_ been a possibility since forever. I
>> am not aware of a lot of abuses from this in the wild.
>
> As far as I can tell, Flash only exposes the ability to _write_ to the
> clipboard except for when handling paste events. Also, since a rash of
> malware in 2008 it only allows writing to the clipboard in response to

> user interaction (search for �clipboard poisoning" for related media
> coverage).

Hmm, this documentation
<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData%28%29>
says:

"In the application sandbox of Adobe AIR, setData() can be called
anytime. In other contexts, setData() can only be called in response to
a user-generated event such as a key press or mouse click."

>>>> How does that sound?
>>>>
>>>
>>> I'm convinced this is going in a good direction. I just wonder if
>>> Firefox OS (gaia) should provide a user interface, so we have strong
>>> visual clues about what's going on.
>>> I'd hate if every app had to bring their own select, copy and paste
>>> buttons.
>>>
>>
>> I thought the idea is to let the system app render some kind of UI on top
>> of the app which provides this functionality by default, so that would
>> give
>> us the default OS level UI.
>

> I assume this is the case too from looking at the UX specs, but the
> system app will need an API fire cut/copy/paste/events so that it can

> provide this OS level UI, won�t it? Can we just expose

> execCommand(cut/copy/paste) via a permission to certified apps since we
> are going to need that level of access for the system app to be able to
> implement the UI for cut/copy/paste.

As I've said before, exposing this functionality to the certified apps
only is fine, but I'm trying to take this opportunity to address this
issue for all Web content, because I think there is nothing Firefox OS
specific about the actual use case here. (Think of why github requires
to use the Flash plugin, I believe clipboard access is the only reason!)

> This means that only certified apps can do UX as described in the spec
> [1] can implement buttons as per pages 4 & 5, but honestly Im not a big
> fan of letting apps create their own clipboard related UX - that seems
> more like something that should be handled by system UI to me for
> consistency and learnability, but thats just my opinion.

Sure. I think that UI is provided by the system app... But note that
the UX spec doesn't address all of the clipboard use cases and in fact
it *only* addresses the most basic ones. Think of the Contacts app
requiring to copy a contact, or the Email app requiring to copy the
email address of someone, or the gallery app requiring to copy an image,
etc. There are *tons* of clipboard use cases that our initial
implementation doesn't address, and I think it's best to not limit the
developers to the basic copy/paste use case that we're initially targeting.

> We might also look at exposing the ability to set the clipboard to
> user-initiated event loops, but that seems secondary to FxOS

> requirements, and doesn�t solve all the use cases here.

Why do you think it doesn't solve the Firefox OS use case?


(Also note that bug 987040 doesn't have anything to do with the
clipboard access, in that bug we just exposed a selection changed event.)

Cheers,
Ehsan

[Paul Theriault]

Note the small text on this page relating tot he getData method. For reference:

"Flash Player requires that the getData() be called in a paste event handler. In AIR, this restriction only applies to content outside of the application security sandbox.”

I would be extremely concerned if flash player allowed arbitrary reading from the clipboard!

>
> Are you worried about the types of attacks where they create a game asking the user to click around and keep reading the clipboard value by issuing an execCommand("paste") and examining the data on the clipboard through a paste event handler?

That could be one scenario, but I’m more worried about opportunistic attacks. Like click an advertisement, and it gets the contents of your clipboard.

So I think this approach might provide a mitigation for execCommand(cut/copy) but not for paste.

>
>>>>>> I also like Ehsan's idea to require a trusted event, but on Firefox OS
>>>>>> isn't everything the user does a trusted event which could be used?
>>>>>
>>>>> Not sure what you mean here by the trusted event. My idea was to enable
>>>>> document.execCommand("copy"/"paste") *if* the execCommand function is
>>>>> called in response to a user initiated event (a touch event, a key press
>>>>> etc.) in order to prevent the page from calling these APIs when it's
>>>>> idle. The basic idea is that there is no good reason why the page would
>>>>> want to call these APIs if the user is not interacting with the page.
>>>>>
>>>>
>>>> So, it seems we agree? I, too, think we should require event.isTrusted
>>>> to be true.
>>>>
>>>
>>> event.isTrusted would be true if the user presses Ctrl+C for example, and
>>> it would be false if the web page runs execCommand("copy"). (But I'm not
>>> sure why isTrusted matters here.)
>>>
>>>
>>>> There's a lot of tap, touch and click in a mobile interface. A popular
>>>> ap that is used regularly, could still poll the clipboard. But that's
>>>> not as bad as an evil app lurking in the background! :)
>>>>
>>>
>>> Yes that will remain a possibility. Note that with Flash exposing this
>>> functionality on desktop, this _has_ been a possibility since forever. I
>>> am not aware of a lot of abuses from this in the wild.
>>
>> As far as I can tell, Flash only exposes the ability to _write_ to the
>> clipboard except for when handling paste events. Also, since a rash of
>> malware in 2008 it only allows writing to the clipboard in response to

>> user interaction (search for “clipboard poisoning" for related media

>> coverage).
>
> Hmm, this documentation <http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData%28%29> says:
>

> "In the application sandbox of Adobe AIR, setData() can be called anytime. In other contexts, setData() can only be called in response to a user-generated event such as a key press or mouse click.”

Exactly. AIR is for desktop applications. We are interested Flash Player’s behaviour right, not AIR?

>
>>>>> How does that sound?
>>>>>
>>>>
>>>> I'm convinced this is going in a good direction. I just wonder if
>>>> Firefox OS (gaia) should provide a user interface, so we have strong
>>>> visual clues about what's going on.
>>>> I'd hate if every app had to bring their own select, copy and paste
>>>> buttons.
>>>>
>>>
>>> I thought the idea is to let the system app render some kind of UI on top
>>> of the app which provides this functionality by default, so that would
>>> give
>>> us the default OS level UI.
>>
>> I assume this is the case too from looking at the UX specs, but the
>> system app will need an API fire cut/copy/paste/events so that it can

>> provide this OS level UI, won’t it? Can we just expose

>> execCommand(cut/copy/paste) via a permission to certified apps since we
>> are going to need that level of access for the system app to be able to
>> implement the UI for cut/copy/paste.
>
> As I've said before, exposing this functionality to the certified apps only is fine, but I'm trying to take this opportunity to address this issue for all Web content, because I think there is nothing Firefox OS specific about the actual use case here. (Think of why github requires to use the Flash plugin, I believe clipboard access is the only reason!)

Yeh ignore me here - I didn’t realise that we already had a solution by extending the mozbrowser API.

>
>> This means that only certified apps can do UX as described in the spec
>> [1] can implement buttons as per pages 4 & 5, but honestly Im not a big
>> fan of letting apps create their own clipboard related UX - that seems
>> more like something that should be handled by system UI to me for
>> consistency and learnability, but thats just my opinion.
>
> Sure. I think that UI is provided by the system app... But note that the UX spec doesn't address all of the clipboard use cases and in fact it *only* addresses the most basic ones. Think of the Contacts app requiring to copy a contact, or the Email app requiring to copy the email address of someone, or the gallery app requiring to copy an image, etc. There are *tons* of clipboard use cases that our initial implementation doesn't address, and I think it's best to not limit the developers to the basic copy/paste use case that we're initially targeting.

So what I am saying is that Cut/Copy/Paste are all system level actions that need to be trusted. We may provide an API to access the clipboard directly, but I feel that we should keep the APIs responsible for allowing the system app to implement the trusted Cut/Copy/Paste actions as restricted to the system app only. (As I said in my earlier email, I’m not real keen on the

>
>> We might also look at exposing the ability to set the clipboard to
>> user-initiated event loops, but that seems secondary to FxOS

>> requirements, and doesn’t solve all the use cases here.

>
> Why do you think it doesn't solve the Firefox OS use case?

Because I though you were talking about setting the clipboard only, but it seems I misunderstood you.

>
>
> (Also note that bug 987040 doesn't have anything to do with the clipboard access, in that bug we just exposed a selection changed event.)

Ah ok - so I asked on IRC what implemented copy & paste in Firefox OS, and this what Howie pointed me to. Because the WIP patch & the wiki spec [1] in that bug talks about cutToClipboard(), copyToClipboard(), pasteFromClipboard() I had assumed that this bug was responsible for this.

If not here, are there separate bugs which implement these clipboard methods? Or is this still under discussion?

>
> Cheers,
> Ehsan

[Ehsan Akhgari]

> "Flash Player requires that the getData() be called in a paste event handler. In AIR, this restriction only applies to content outside of the application security sandbox.�

>
> I would be extremely concerned if flash player allowed arbitrary reading from the clipboard!

OK, I think I understand your point now. So here is a modified proposal:

* Allow execCommand("copy"/"cut") for all web content if run in response
to a user generated event.
* Allow execCommand("paste") only for certified apps or chrome content.

I think this should address your concern. Please let me know what you
think.

>> Are you worried about the types of attacks where they create a game asking the user to click around and keep reading the clipboard value by issuing an execCommand("paste") and examining the data on the clipboard through a paste event handler?
>

> That could be one scenario, but I�m more worried about opportunistic attacks. Like click an advertisement, and it gets the contents of your clipboard.

>
> So I think this approach might provide a mitigation for execCommand(cut/copy) but not for paste.

Yep, see the proposal above.

>>>>>>> I also like Ehsan's idea to require a trusted event, but on Firefox OS
>>>>>>> isn't everything the user does a trusted event which could be used?
>>>>>>
>>>>>> Not sure what you mean here by the trusted event. My idea was to enable
>>>>>> document.execCommand("copy"/"paste") *if* the execCommand function is
>>>>>> called in response to a user initiated event (a touch event, a key press
>>>>>> etc.) in order to prevent the page from calling these APIs when it's
>>>>>> idle. The basic idea is that there is no good reason why the page would
>>>>>> want to call these APIs if the user is not interacting with the page.
>>>>>>
>>>>>
>>>>> So, it seems we agree? I, too, think we should require event.isTrusted
>>>>> to be true.
>>>>>
>>>>
>>>> event.isTrusted would be true if the user presses Ctrl+C for example, and
>>>> it would be false if the web page runs execCommand("copy"). (But I'm not
>>>> sure why isTrusted matters here.)
>>>>
>>>>
>>>>> There's a lot of tap, touch and click in a mobile interface. A popular
>>>>> ap that is used regularly, could still poll the clipboard. But that's
>>>>> not as bad as an evil app lurking in the background! :)
>>>>>
>>>>
>>>> Yes that will remain a possibility. Note that with Flash exposing this
>>>> functionality on desktop, this _has_ been a possibility since forever. I
>>>> am not aware of a lot of abuses from this in the wild.
>>>
>>> As far as I can tell, Flash only exposes the ability to _write_ to the
>>> clipboard except for when handling paste events. Also, since a rash of
>>> malware in 2008 it only allows writing to the clipboard in response to

>>> user interaction (search for �clipboard poisoning" for related media

>>> coverage).
>>
>> Hmm, this documentation <http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData%28%29> says:
>>

>> "In the application sandbox of Adobe AIR, setData() can be called anytime. In other contexts, setData() can only be called in response to a user-generated event such as a key press or mouse click.�
>
> Exactly. AIR is for desktop applications. We are interested Flash Player�s behaviour right, not AIR?

Yep, I was reading the second part actually: "In other contexts,

setData() can only be called in response to a user-generated event such

as a key press or mouse click." My new proposal is on par with this.

>>>>>> How does that sound?
>>>>>>
>>>>>
>>>>> I'm convinced this is going in a good direction. I just wonder if
>>>>> Firefox OS (gaia) should provide a user interface, so we have strong
>>>>> visual clues about what's going on.
>>>>> I'd hate if every app had to bring their own select, copy and paste
>>>>> buttons.
>>>>>
>>>>
>>>> I thought the idea is to let the system app render some kind of UI on top
>>>> of the app which provides this functionality by default, so that would
>>>> give
>>>> us the default OS level UI.
>>>
>>> I assume this is the case too from looking at the UX specs, but the
>>> system app will need an API fire cut/copy/paste/events so that it can

>>> provide this OS level UI, won�t it? Can we just expose

>>> execCommand(cut/copy/paste) via a permission to certified apps since we
>>> are going to need that level of access for the system app to be able to
>>> implement the UI for cut/copy/paste.
>>
>> As I've said before, exposing this functionality to the certified apps only is fine, but I'm trying to take this opportunity to address this issue for all Web content, because I think there is nothing Firefox OS specific about the actual use case here. (Think of why github requires to use the Flash plugin, I believe clipboard access is the only reason!)
>

> Yeh ignore me here - I didn�t realise that we already had a solution by extending the mozbrowser API.

>
>>
>>> This means that only certified apps can do UX as described in the spec
>>> [1] can implement buttons as per pages 4 & 5, but honestly Im not a big
>>> fan of letting apps create their own clipboard related UX - that seems
>>> more like something that should be handled by system UI to me for
>>> consistency and learnability, but thats just my opinion.
>>
>> Sure. I think that UI is provided by the system app... But note that the UX spec doesn't address all of the clipboard use cases and in fact it *only* addresses the most basic ones. Think of the Contacts app requiring to copy a contact, or the Email app requiring to copy the email address of someone, or the gallery app requiring to copy an image, etc. There are *tons* of clipboard use cases that our initial implementation doesn't address, and I think it's best to not limit the developers to the basic copy/paste use case that we're initially targeting.
>

> So what I am saying is that Cut/Copy/Paste are all system level actions that need to be trusted. We may provide an API to access the clipboard directly, but I feel that we should keep the APIs responsible for allowing the system app to implement the trusted Cut/Copy/Paste actions as restricted to the system app only. (As I said in my earlier email, I�m not real keen on the

Well, I'm trying to change your mind about copy and cut. :-) I am
convinced that we cannot expose paste as I originally wanted. But I'm
actually happy with ignoring paste for now.

>>> We might also look at exposing the ability to set the clipboard to
>>> user-initiated event loops, but that seems secondary to FxOS

>>> requirements, and doesn�t solve all the use cases here.

>>
>> Why do you think it doesn't solve the Firefox OS use case?
>
> Because I though you were talking about setting the clipboard only, but it seems I misunderstood you.
>
>>
>>
>> (Also note that bug 987040 doesn't have anything to do with the clipboard access, in that bug we just exposed a selection changed event.)
>
> Ah ok - so I asked on IRC what implemented copy & paste in Firefox OS, and this what Howie pointed me to. Because the WIP patch & the wiki spec [1] in that bug talks about cutToClipboard(), copyToClipboard(), pasteFromClipboard() I had assumed that this bug was responsible for this.

Originally the plans on that bug were exactly what Howie said, but I
convinced people that we need a lower level API, and we ended up
designing an API to notify the consumer of the mozbrowser API of the
changes in the selection in the content loaded inside the mozbrowser and
also express the bounds of the selection on the screen, to let the
system app implement the bubble on top of that. The copy and paste part
was not addressed in that bug.

> If not here, are there separate bugs which implement these clipboard methods? Or is this still under discussion?

I am not aware of any existing bugs on that. It seems to me that you're
arguing for having a mozbrowser API for doing copy/paste and Tim in the
original email in this thread is asking for a way for the apps
themselves to be able to copy/paste. I guess we need to reconcile on
which one we should allow first. (We might want to do both.)

FWIW, the command bubble in the UX spec pretty much requires us to do
this work in the system app, which means we'll have to expose the
mozbrowser APIs at any rate, I think.

Cheers,
Ehsan

[hall...@gmail.com]

kl. 00:18:03 UTC+2 onsdag 20. august 2014 skrev Ehsan Akhgari følgende:

> * Allow execCommand("copy"/"cut") for all web content if run in response
>
> to a user generated event.
>
> * Allow execCommand("paste") only for certified apps or chrome content.

Hi Ehsan and all,
I'm editing the clipboard API spec - updated editor's draft on http://dev.w3.org/2006/webapi/clipops/clipops.html - and the proposal above is nearly what we've ended up spec'ing. We're ever so slightly more liberal on paste events, because I believe that if "paste" is not synthetic or triggered from document.execCommand(), it's triggered from the browser's trusted UI (Edit menu/right-click menu/ctrl-v) and thus pretty reliably expresses the user's intention to let the web site read clipboard data. (I don't know what UI controls we have on Firefox OS devices - certainly not ctrl-v but perhaps a long-click + "paste"?) There's also an exception that will allow scripts to read the clipboard data in contexts where the UA is configured to allow this (could be for example white-listed, trusted sites).

You might find this spec interesting, and I hope it's mature enough to be implemented in Gecko, in which case Firefox OS would probably get the desired functionality with minimal integration work. The spec also comes with a pretty extensive set of test cases to ensure the quality of implementations.
-Hallvord

[Ehsan Akhgari]

On 2014-09-13, 4:45 PM, hall...@gmail.com wrote:

> kl. 00:18:03 UTC+2 onsdag 20. august 2014 skrev Ehsan Akhgari f�lgende:
>
>> * Allow execCommand("copy"/"cut") for all web content if run in response
>>
>> to a user generated event.
>>
>> * Allow execCommand("paste") only for certified apps or chrome content.
>

> Hi Ehsan and all,
> I'm editing the clipboard API spec - updated editor's draft on http://dev.w3.org/2006/webapi/clipops/clipops.html - and the proposal above is nearly what we've ended up spec'ing. We're ever so slightly more liberal on paste events, because I believe that if "paste" is not synthetic or triggered from document.execCommand(), it's triggered from the browser's trusted UI (Edit menu/right-click menu/ctrl-v) and thus pretty reliably expresses the user's intention to let the web site read clipboard data. (I don't know what UI controls we have on Firefox OS devices - certainly not ctrl-v but perhaps a long-click + "paste"?) There's also an exception that will allow scripts to read the clipboard data in contexts where the UA is configured to allow this (could be for example white-listed, trusted sites).

Yeah, that sounds fine to me. Note that most of this thread was talking
about initiating these operations through execCommand.

In fact, I think what you're suggesting is what we already implement. :-)

> You might find this spec interesting, and I hope it's mature enough to be implemented in Gecko, in which case Firefox OS would probably get the desired functionality with minimal integration work. The spec also comes with a pretty extensive set of test cases to ensure the quality of implementations.

Which parts specifically? If you find unimplemented parts, please file
bugs. I think we have most of it implemented already.

Cheers,
Ehsan

[hall...@gmail.com]

> Which parts specifically? If you find unimplemented parts, please file
> bugs. I think we have most of it implemented already.

I plan to do some deeper testing and bug reporting soon. I know some details (like commands not always being enabled when I would like them to be - it would be good if for example ctrl-v would always fire a "paste" event regardless of whether there is a cursor/editable context or not - and this issue prevents several of my tests from being testable.. But I plan to report a few bugs :)).
-Hallvord

[Ehsan Akhgari]

On 2014-09-15, 5:20 PM, hall...@gmail.com wrote:
>> Which parts specifically? If you find unimplemented parts, please file
>> bugs. I think we have most of it implemented already.
>

> I plan to do some deeper testing and bug reporting soon. I know some details (like commands not always being enabled when I would like them to be - it would be good if for example ctrl-v would always fire a "paste" event regardless of whether there is a cursor/editable context or not - and this issue prevents several of my tests from being testable.. But I plan to report a few bugs :)).

Oh, yeah, that issue is actually known. Currently we don't dispatch
those events if the corresponding command is disabled. I think the
right thing to do would be to dispatch the events always, but bail out
early on the default action if the command is disabled. That way, if
the command is disabled, content can still receive these events.

The issue that makes that a bit hard to fix is that right now the
Ctrl+X/C/V are bound to XUL commands, which we disable/enable as the
current selection changes. This stuff is triggered on the Gecko side by
calling nsGlobalWindow::UpdateCommand("select") in
nsDocViewerSelectionListener::NotifySelectionChanged. That ends up
calling goUpdateGlobalEditMenuItems in toolkit, which currently updates
the cmd_cut/copy/paste commands. I think we'd want to instead update
the corresponding menu items and toolbar keys. But these are well known
commands in XUL applications, I don't know we can simply change toolkit
here. CCing dev-firefox and Neil, hopefully someone can check over my
idea here.

Cheers,
Ehsan

[Ehsan Akhgari]

On Tue, Sep 16, 2014 at 5:52 AM, Neil <ne...@parkwaycc.co.uk> wrote:

> Ehsan Akhgari wrote:
>
> On 2014-09-15, 5:20 PM, hall...@gmail.com wrote:
>>

>> Which parts specifically? If you find unimplemented parts, please file
>>>> bugs. I think we have most of it implemented already.
>>>>
>>>

>>> I plan to do some deeper testing and bug reporting soon. I know some
>>> details (like commands not always being enabled when I would like them to
>>> be - it would be good if for example ctrl-v would always fire a "paste"
>>> event regardless of whether there is a cursor/editable context or not - and
>>> this issue prevents several of my tests from being testable.. But I plan to
>>> report a few bugs :)).
>>>
>>
>> Oh, yeah, that issue is actually known. Currently we don't dispatch
>> those events if the corresponding command is disabled. I think the right
>> thing to do would be to dispatch the events always, but bail out early on
>> the default action if the command is disabled. That way, if the command is
>> disabled, content can still receive these events.
>>
>> The issue that makes that a bit hard to fix is that right now the
>> Ctrl+X/C/V are bound to XUL commands, which we disable/enable as the
>> current selection changes. This stuff is triggered on the Gecko side by
>> calling nsGlobalWindow::UpdateCommand("select") in
>> nsDocViewerSelectionListener::NotifySelectionChanged. That ends up
>> calling goUpdateGlobalEditMenuItems in toolkit, which currently updates the
>> cmd_cut/copy/paste commands. I think we'd want to instead update the
>> corresponding menu items and toolbar keys. But these are well known
>> commands in XUL applications, I don't know we can simply change toolkit
>> here. CCing dev-firefox and Neil, hopefully someone can check over my idea
>> here.
>>
>

> Actually the key elements are only for show, see
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/editMenuOverlay.xul#31
>

Hehe, nice! :-)


> We need the commands to be up-to-date so that the menuitems can be
> disabled correctly, and also toolbar buttons where appropriate (offhand I
> don't know whether Firefox uses this), and more importantly the Mac menu
> also depends on the commands being up-to-date.
>
> What might work is to change the command controller API so that you don't
> need to check that the command is enabled before attempting to invoke it.
> (Obviously you would have to fix all the implementations in mozilla-central
> and at least warn comm-central too please.) Then you could make the XBL and
> native keys simply invoke the command directly, and then you could make
> Ctrl+X/C/V always fire the appropriate event first. (Because of the way
> contenteditable works, you would need to add dummy cut and paste handlers
> to the global window commands for uneditable documents which just fired the
> event and did nothing and always claimed to be disabled.)
>

I don't think that will give us exactly what we want though. The desired
outcome is for the commands themselves to be *always* enabled, they just
need to do nothing if you invoke them in contexts that they are currently
disabled in, except for dispatching the events. But the tricky thing is
that other XUL based apps may not want to have these commands always
enabled...

--
Ehsan

[Ehsan Akhgari]

> Depends on your definition of enabled. What I was trying to say was that
> the enabled state as set on the XUL command element (observed by the
> menuitem or toolbarbutton as appropriate for other XUL based apps) would be
> ignored by the XBL and native keybindings, they would always attempt to
> invoke the command directly. This means that when you press Ctrl+V the XBL
> or native key handler would tell the controller to dispatch the event
> whether or not the menuitem was enabled.
>

Yes, I got that part, but what I meant was that we want the menu and
toolbar items to also be enabled always in Firefox, since not all users
invoke these commands through the keyboard shortcuts.


> If on the other hand you want the Mac menu to flash when you press Ctrl+V
> on a page when it's not in an editable area, then you've got a lot more
> work to do, sorry.
>

Can you please clarify what additional work that entails?

Thanks!
--
Ehsan

[Ehsan Akhgari]

On Tue, Sep 16, 2014 at 1:00 PM, Neil <ne...@parkwaycc.co.uk> wrote:

> Ehsan Akhgari wrote:
>
> what I meant was that we want the menu and toolbar items to also be
>> enabled always in Firefox, since not all users invoke these commands
>> through the keyboard shortcuts.
>>
>

> Ah, well if you want them to be always enabled, then that's much easier,
> and solves your Mac menu problem (as long as your Mac users understand that
> pressing Ctrl+V flashes the menu even though nothing actually happens);
> just don't disable them (i.e. remove them from the list of commands to be
> updated). Currently goDoCommand checks that the command is enabled before
> doing it, so you'd want to remove that check as will as fixing the
> controller.
>

Is that acceptable for other XUL apps, such as Thunderbird and SeaMonkey?

--
Ehsan