Firefox and IE let this feature be configurable:

https://msdn.microsoft.com/en-us/library/bb250473(v=vs.85).a...

http://i.stack.imgur.com/jvDUh.png

https://developer.mozilla.org/en-US/docs/Mozilla/Preferences...

But the same quick search shows that it does not appear possible to control this in Chrome. If anyone knows how, please correct me.

I just turned this preference off in Firefox, and it didn't stop the demo from working, which makes sense since the preference says it only disables oncopy/cut/paste events, and this demo uses a different method.

This is because the Firefox preference is useless - it only disables the clipboard events, but not the clipboard access from any other event. So the demo simply hooks the keydown event instead. Have a look at the source, it's really quite straightforward.

What browsers really should have are a standard "Ask & Whitelist" dialog for all of these security critical features[1]. It seems Firefox even used to have this feature, but it and the corresponding addon have long since crumbled to dust[2].

Unfortunately browsers are no longer controlled by hackers who think about all the implications of a feature, but by corporations who think about money, and us hackers have to spend inordinate amounts of time trying to play security whack-a-mole, or be forced to give up and use our browsers like sheep, the way the corporations want us to.

[1] There's many more, including utterly ridiculous stuff such as telling websites the battery charge status of your device (and if your charger is plugged in): https://gist.github.com/haasn/69e19fc2fe0e25f3cff5

[2] http://kb.mozillazine.org/Granting_JavaScript_access_to_the_...

I found one of the bugs and... wow:

https://bugzilla.mozilla.org/show_bug.cgi?id=38966

They had a pretty useful per-site configuration mechanism that wasn't UI-configurable so someone started to make a UI for it, but then some higher-up decided they should remove the whole thing completely! The screenshots they have there look so awesome:

https://bug38966.bmoattachments.org/attachment.cgi?id=63187

It's ironic that, meanwhile, IE gets this right.

> Unfortunately browsers are no longer controlled by hackers who think about all the implications of a feature, but by corporations who think about money, and us hackers have to spend inordinate amounts of time trying to play security whack-a-mole, or be forced to give up and use our browsers like sheep, the way the corporations want us to.

FWIW, the features that this uses have their origins in proprietary IE5 features (maybe 5.5?). Whether this attack works in IE5 I leave as an exercise to someone else.

Note that the tradeoffs are more complex than what one might naïvely assume: people weren't using the feature as it existed in Firefox before because it required explicit user interaction, but doing the same thing through Flash didn't… so everyone just used Flash. In effect, this is a security bug the platform has long had (because, like it or not, de-facto the web platform for the longest time included Flash). Now, should we blindly copy everything Flash can do? Of course not. But if something is making people hold on to Flash, we really should consider the tradeoffs. Are we just gaining theoretical superiority but practical irrelevance (on desktop at least; mobile where Flash is gone is a different story)?

> I just turned this preference off in Firefox, and it didn't stop the demo from working, which makes sense since the preference says it only disables oncopy/cut/paste events, and this demo uses a different method.

How is this method different?

Oncopy is a named javascript event type that triggers when you copy the text of an element.

This method is more sophisticated; it monitors the whole page for copy commands, and has an event listener watching to see when this 'copy' command is executed.

I tried the demo in Safari 9.1.1 (11601.6.17) and got "not evil" in the Terminal.

Did you use the keyboard or the mouse? Because when I copy using keys, my clipboard is empty. Only right-clicking gives me "not evil". The eventListener is on keydown FYI

It's honestly probably because it's been done in Flash for so long that any difficulties would be worked around with more Flash.

On a somewhat related note: why do browsers allow websites to prevent you from leaving via those annoying dialog boxes that ask you to click "cancel" or "leave"?

To be able to remind you about your unsaved changes before you leave the page. I personally find the benefits of websites doing that to be greater than the annoyment from websites abusing this functionality. (just an extra click when its being abused, but potentially saving hours of my time when used properly)

Sure, but I ant to at least be able to blacklist sites. Yes, Jira, I'm looking at you.

This seems like a good thing for an extension to do.

I have seen sites that have pages where you're placed in a queue (for whatever reason) and if you leave the page you will be dropped from the queue, so it's nice to have something preventing you from accidentally leaving, but that's the only legitimate use I can think of.

I used to work for a company whose primary product was a web server that companies could buy and run for use purely internally. Our pages involved a lot of data entry that could be lost, so that sort of pop-up can be handy in that situation as well.

Of course a better solution wouldve been a program which doesnt so easily let you lose data in the first place, but this software was long past that.

Still, that functionality should be opt-in.

It's really not that bad. The big problem was historically the buttons were labeled "Cancel" or "Ok", and some browsers allowed pages to customize the button labels, making which you clicked very ambiguous. Browsers today just giving "Stay on this page" and "Leave this page" buttons aren't really much of a bother if you remember how bad it used to be.

Or potentially losing any page state when navigating away or closing a browser, such as form data.

Right. You don't want to lose the blog post or other document you've been working on for an hour because you hit the close button on the wrong tab.

Websites can find better solutions if we kill this annoying feature. We have local storage in all browsers. Rather than prompting why not save it and recover when the user comes back. The users will always prefer this. It saves data even when the website crashes or the connectivity is lost and there is some important data on the page. Why have a feature that is abused more often than used especially there is no case where it is the only/best solution.

It's not always that clear. If I leave a page, how is one to know whether that was intentional or not?

If it's intentional, you don't want to pull the data back up (people want a "fresh copy")

If it's not intentional, you do want to pull the data back up.

Though of course you can make something like a "New Copy" button, but then that presents its own challenges.

That no longer makes sense unless it isn't feasible to preserve the change history along with current state...

I agree. This thought process comes from a different era and has just continued to perpetuate itself. If you are working on insanely* large files then that box makes sense, otherwise we have the technology to save the user the headache.

*insanely large is anything that takes up 75% of whatever computer bottlenecks first at the time of reading this comment(Memory, processor)

Funnily enough that API is already highly restricted: You can only show that single dialog box, you cannot modify the actions of the cancel and leave buttons and you cannot perform any asynchronous operations within the callback. (Technically you can, but the browser won't wait for them to finish)

All this was introduced to prevent abuse. Apparently it still wasn't enough though...

It's important to point out that the "yes, actually leave" option is not overridable. As a developer, you only get to set what message is displayed. The browser handles the rest, and it's basically "stop redirecting or continue". The developer only has control in the "stop redirecting" case.

Totally agree. On Firefox these are often modal to the whole browser so you can't even force close the tab.

What absolutely annoys me about this feature is that there are shitty ads which throw this dialog in a loop, making it virtually impossible to close them.

In which browser? Modern implementations shouldn't even make that possible.

Chromium on Linux. Maybe they play some tricks with refreshing or redirecting to make the browser show this dialog again on the next attempt to close the tab, if the browser wouldn't normally do that. Unfortunately, I didn't investigate and don't have links.

I see it on Firefox. Now that you mention it, it seems to happen less often lately. Maybe I am looking less at shady sites or they have changed something.

It's intended use is for data entry, it's meant to be a prompt for "Hey there's unsaved changes on your 'Super Important Document' are you sure you want to to leave?"

This is fair. For me, this is a case where it is likely as narrowly annoying as helpful, and thus a no-win situation. Some sites I use are respnsible allowing you to copy an ip address on click, or a cryptocurrency wallet address on click, removing any extra whitespace and confirming a full address copy. This is quite important as perfectly copied addresses (which are basically massive strings of random text) ensure your money arrives properly, or is dispatched to the correct location.

However, sometimes I want to share a qoute I found online. I don't want a promo for the website inserted into my clipboard. For them, it must be a fine line that realization: user-hostility can be short term profitable but long term fatal.