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
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 mechan
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 t
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 pa
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
> 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 execComm
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
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 doi
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 develo
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).
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:
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 depreca
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 E
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
sett
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 h
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
li
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 defini
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 a
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
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]
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
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.
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 wh
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 malici
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 aut
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
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
bro
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.
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,
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_ (
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 yello
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 ea
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.
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
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.
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
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 wro
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 n
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 exc
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 preciou
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
"engag
> 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 yo
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
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),
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
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 peopl
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.
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"
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.)
Look
\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 rel
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
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
r
52 matches
Mail list logo
