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
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
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
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
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
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
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
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
On Sat, May 23, 2015 at 5:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
And that is exactly the point I have been trying to make. The potential
for abuse definitely exists today, with Flash. And so far we have no
evidence that this is an issue in practice today. At the very least, by
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:
On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2015-05-05 6:31 PM, Daniel Holbert wrote:
On 05/05/2015
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
On Wed, May 6, 2015 at 10:51 AM, Gervase Markham g...@mozilla.org wrote:
On 06/05/15 08:00, Tantek Çelik wrote:
Result: loss of user data that user had put into the clipboard
previously. This isn't possible with current DOM APIs and is a new
vulnerability introduced by cut/copy.
Given that
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote:
Keep in mind the thesis of that plan isn't that we restrict
security-sensitive features to https -- it's that /all new stuff/ is
restricted to https. If this falls under the definition of a new feature,
and if it's going to be
On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote:
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote:
Keep in mind the thesis of that plan isn't that we restrict
security-sensitive features to https -- it's that /all new stuff/ is
restricted to https. If
On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote:
Going fullscreen also gives the user UI at the time of activation, allowing
them to manipulate permissions in an obvious way.
Note that we're changing that:
https://bugzilla.mozilla.org/show_bug.cgi?id=1129061
Perhaps an
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 2015-05-06 3:00 AM, Tantek Çelik wrote:
On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2015-05-05 6:31
On 2015-05-06 1:08 PM, Anne van Kesteren wrote:
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
* Restricting this API to resources loaded from a secure origin also doesn't
help in any way in practice. It doesn't address your original concern _at
all_ (since your
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
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
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 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
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
Not pure vandalism. The user data loss is a side-effect of other incentives.
E.g. trivial attacker incentive: all those share-button-happy
news/media
On 06/05/15 18:08, Anne van Kesteren wrote:
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
* Restricting this API to resources loaded from a secure origin also doesn't
help in any way in practice. It doesn't address your original concern _at
all_ (since your
On 5/6/15 10:49, Martin Thomson wrote:
On Wed, May 6, 2015 at 8:42 AM, Doug Turnerdo...@mozilla.com wrote:
This is important. We could mitigate by requiring https, only allowing the top
level document access these clipboard apis, and doorhangering the API.
Thoughts?
A doorhanger seems
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
On 5/6/15 10:49, Martin Thomson wrote:
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
This is important. We could mitigate by requiring https, only allowing the top
level document access these clipboard apis, and doorhangering the API.
Thoughts?
A doorhanger seems
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
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
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
* Restricting this API to resources loaded from a secure origin also doesn't
help in any way in practice. It doesn't address your original concern _at
all_ (since your malicious web site can easily get a certificate
I think the ribbon would be really useful if it allowed the user to restore
the previous clipboard content. However this is probably not possible for
all data that can be stored in clipboards, i.e. files.
On Wed, May 6, 2015 at 7:33 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, May 6,
On 06/05/15 18:22, James Graham wrote:
On 06/05/15 18:08, Anne van Kesteren wrote:
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari
ehsan.akhg...@gmail.com wrote:
* Restricting this API to resources loaded from a secure origin also
doesn't
help in any way in practice. It doesn't address your
On 2015-05-06 6:48 PM, Tantek Çelik wrote:
On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote:
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote:
Keep in mind the thesis of that plan isn't that we restrict
security-sensitive features to https -- it's that
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
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
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
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
On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
Not pure vandalism. The user data loss is a side-effect of other incentives.
E.g. trivial attacker incentive: all those share-button-happy
news/media sites are likely to auto-copy URL + title of an article
you're
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
This is important. We could mitigate by requiring https, only allowing the
top level document access these clipboard apis, and doorhangering the API.
Thoughts?
A doorhanger seems like overkill here. Making this
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote:
A doorhanger seems like overkill here. Making this conditional on an
engagement gesture seems about right. I don't believe that we
should be worry about surfing - and interacting with - strange sites
while there is
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote:
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
This is important. We could mitigate by requiring https, only allowing the
top level document access these clipboard apis,
Thanks Doug. I think your
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2015-05-05 6:31 PM, Daniel Holbert wrote:
On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
Sites such as Github currently use Flash in order to
allow people to copy text to the clipboard by clicking a button in
On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2015-05-05 6:31 PM, Daniel Holbert wrote:
On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
Sites such as Github currently use Flash
\o/ Great to see this come through. Shumway was already using this but
needed chrome privilege to do so. It's nice to open it up.
--Jet
On Tue, May 5, 2015 at 2:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
Summary: We currently disallow programmatic copying and cutting from JS for
Web
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
47 matches
Mail list logo
