On 2015-05-06 3:00 AM, Tantek Çelik wrote:
On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
wrote:
On 2015-05-05 6:31 PM, Daniel Holbert wrote:
On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
Sites such as Github currently use Flash in order to
allow people to copy text to the clipboard by clicking a button in
their
UI.
First, this is awesome and can't wait to try it out.
Second, "cut" is potentially destructive to user data, have you
considered enabling this only for secure connections? Either way it
would be good to know the reasoning behind your decision.
Hmm, what would that prevent against though? A web page could just use the
normal DOM APIs to destroy the user data (e.g., something like the contents
of a blog post the user is writing in a blogging web app). Is this what you
had in mind?
Sorry I wasn't clear. *Both* "cut" and "copy" have the impact of
*clearing* the previous clipboard data (on typical platforms).
Thus if the user had say, cut a bunch of text from another application
(like a text editor), and then switched to a browser window, gotten
distracted and clicked something, it is *possible* the page could
select text, do a cut/copy, and blow away that bunch of text from the
other application.
Result: loss of user data that user had put into the clipboard
previously. This isn't possible with current DOM APIs and is a new
vulnerability introduced by cut/copy.
Thanks for the clarification! I have actually already considered this,
and I don't think this is a problem that we need to deal with, at least
until we have some evidence that it is an actual problem in the wild.
Two points to note here:
1. The scenario that you're describing is already possible on the Web,
through Flash. However, I have not seen any evidence of this kind of
thing ever occurring in the wild. Given the fact that people have
literally had years to start trying to do this. Web sites do have an
incentive to not annoy users, and we have seen how they have largely
stopped doing annoying things such as blocking the context menu in the past.
2. Even if we decided that this is a serious issue that we need to
solve, there is no good solution here. Let's look at some of the
suggestions in this thread:
* Directly promoting the user is a horrible user experience, and given
that it is practically impossible to describe what we're asking for them
(many users may not even know what a "clipboard" is, since it has never
been exposed in a user-facing way in any OS that I've seen at least),
and also because it could be an annoying and pointless question to ask:
"Would you like website X to be able to copy text so that you can paste
it elsewhere?" "Why would I not want to allow that? Where is the
Whatever Button?". :-)
* Having a permissions for this is a similarly horrible user experience
for similar reasons to prompting, except that we show the permission UI
at different times than the prompt UI. Also, if the permission is
granted by default, this does very little to protect any of our users
anyway.
* Restricting this API to resources loaded from a secure origin also
doesn't help in any way in practice. It doesn't address your original
concern _at all_ (since your malicious web site can easily get a
certificate and perform the same annoying operation), and a potential
network attacker MITMing your connection can inject a tiny Flash object
and script it. It will be a few more lines of code for the attacker to
write, and they would get a pretty solid attack for the majority of
desktop users, at least.
* It may be argued that this attack has not been possible through Web
APIs so far, so we should now do something about it now that the
implementation is moving from Flash to the browser engine. I think
that's a very theoretical view of the world, and is quite insufficient
if we believe that this is a real issue worth addressing. Also, a
variation of this attack has been possible through the clipboard events
on the Web without Flash for a while now. For example, if you press
your mouse cursor in a text area and without selecting anything, press
Cmd+C, you would typically expect for the contents of the clipboard to
remain unchanged. It is possible for a web app to put arbitrary data on
the clipboard in that case (and again, with this feature, we have seen
no evidence of abuse in the wild so far.)
* At least on desktop where Flash is widely available, the real value of
this API is giving people a good incentive to move away from using
Flash. If the Web alternative is an API that doesn't work in some cases
(be it because the user said no to a prompt, disabled a permission, or
if the web page is served from a non-secure origin), people will keep
using Flash for this, and that eliminates most of the benefit from this
effort. Even worse, they may start to serve the Flash based code only
to Firefox users, which puts them at an unfair disadvantage compared to
the users of other major browsers.
Based on the above, I am planning to expose this API without any
restrictions, since I think the current lack of evidence for this being
an issue in practice will likely prove to be a more reliable way to make
this decision rather than hypothesizing about what an attacker could
possibly do. I do realize that we may actually see this issue popping
up in the wild in the future, and I'm open to revisiting this decision
when we have such evidence at hand. Thankfully, it would be relatively
easy to change our behavior, and we will make sure to make our behavior
feature detectible through the document.queryCommandSupported() API.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
