Whether he realizes it or not, he's more or less suggesting that javascript shouldn't be able to handle click events, which is asinine.

Wow that's jumping to conclusions! He's talking about making so obvious hyperlink elements (those containing basic URL content and not javascript evaluation) should have their destination fixed once created. Seems pretty reasonable to me.

You can still create your div or canvas and get click events and everything fancy you want.

As someone pointed out, you can already redirect the browser location at will anyway. Why not make it at least safe for a tag that has a concrete meaning and displays extra information in tool-tips and status bar about a destination to mean what it really means?

My point is that you can get the exact same behavior without modifying the href value of the link at all. Javascript can suppress the standard behavior of an <a> tag and not load a page on click. This is a very useful feature that lots of web apps use for progressive enhancement purposes. Javascript can also use window.location to load a new page. This is also very useful for a variety of purposes.

Without eliminating either of those things, the only way you can prevent this from being possible is to prevent any use of window.location from ever resulting from a click event, which a) would likely break plenty of legitimate code, and b) would be easy to work around in a variety of ways.

You seem to have bypassed my point. Yes you are still able to redirect the user anywhere, yes you are still able to make hyperlinks not really hyperlinks but random bits of code, but at least when the user sees an URL in the status bar he knows for sure this will lead to this URL.

That's not for nothing new browers disable custom status bar messages by default.

Also new browsers could add additional UX hints to make sure links are really links.

The OP problem is a real concern and this is in my opinion a step in the right direction. Make phishing harder and more obvious to a random joe knowing nothing about computers a single step at a time.

but at least when the user sees an URL in the status bar he knows for sure this will lead to this URL.

You're really not paying attention to what I'm saying, because no, even without changing the href value it's trivial in javascript to create a link that goes someplace completely different from where it says in the status bar.

Ok now I see what you mean, but you are basically stating the same problem than the author just in a different way ... the scope of the author's proposal should also include your example and prevent all actions that could perform unknown redirection when clicking on a link.

I see these as the very same thing: once you are commit to go somewhere (clicked on an hyperlink), don't process javascript that do "malicious" redirection.

There's no real way to prevent this without seriously crippling javascript or still allowing some sort of workaround.

You can still process all kind of javascript. It's quite easy for browser implementers to protect all redirection commands into a single scope that can be protected when necessary (when the user clicks on top of an hyperlink). I really don't see why you generalize so much.

I see these as the very same thing: once you are commit to go somewhere (clicked on an hyperlink), don't process javascript that do "malicious" redirection.

Except tons of web apps legitimately override the normal effects of clicking on a hyperlink for purpose of progressive enhancement or graceful degredation. Clicking on a hyperlink doesn't always mean you're committing to going to a page, that's often the fallback behavior for when javascript is disabled.

It's quite easy for browser implementers to protect all redirection commands into a single scope that can be protected when necessary (when the user clicks on top of an hyperlink). I really don't see why you generalize so much.

The problem is that it's rather simple to make the click event and the redirect occur in different scopes so there's no obvious cause and effect from the parser perspective. Just have the click event change some sort of global variable, and then have a timeout loop watch to see if that variable changes.

Unless you want to play security whack-a-mole and break more things than you're actually fixing, this isn't something that really can be prevented. Beyond that, the whole thing is kind of silly, because you should always be relying on the location bar to identify the site you're on anyway, not the status bar.

Except tons of web apps legitimately override the normal effects of clicking on a hyperlink for purpose of progressive enhancement or graceful degredation. Clicking on a hyperlink doesn't always mean you're committing to going to a page, that's often the fallback behavior for when javascript is disabled.

Of course, the rule is simple: you can do any kind of fancy stuff when you click on a link, but if the link contains a valid href, you can't change the location somewhere else than this location.

Just have the click event change some sort of global variable, and then have a timeout loop watch to see if that variable changes.

The scope would last until the click action is finished. Of course, if the user cancelled his click on a hyperlink by some voodoo magic (losing focus before the mouse-up or something), granted there are still ways to bypass this.

break more things than you're actually fixing

If this simple protection breaks that much things, these websites are probably in serious need of redesign in my opinion, but I can't comment on that that much since it's been years I haven't actively develop interactive websites.

because you should always be relying on the location bar to identify the site you're on anyway, not the status bar

Half-granted. It's very easy to browse late at night or on a mobile device or while being distracted ... I think ALL helpful indications that a web site is legitimate help protect the user at the end of the day. It's not a whack-a-mole thing, it's good practices for the future.

If you haven't developed for the web in years, you might not be familiar with the concept of progressive enhancement.

The idea is that you build a solid, working basic site without any of the bells and whistles, and then you build additional functionality on top of that for more capable browsers. That way your site provides the best functionality possible, no matter what.

So, let's use a very basic example of a lightbox-style web gallery. You have a bunch of thumbnail images on the page, and clicking on each of them shows you to the full-size version of that image.

Each of those images is set up as a link directly to the full-size image. That way, if javascript is disabled, clicking on the links still takes you to the full-size image.

However, if javascript is enabled there's no need to leave the page, the script can retrieve the image and display it within the same page. This provides additional functionality that would not be possible without a script.

In order for this to work though, you first need to suppress the normal link behavior, otherwise clicking on that thumbnail will still leave the current page and take you to the full-size image.

If you couldn't override that default click event, the lightbox in our example would either not be possible, or wouldn't have a way of functioning with scripts disabled.

So we've established that there's a valid and useful reason for clicking on a link to not take you to its href location. So at this point you need to prevent the script from loading a new page, but doing so is nearly impossible because there's an almost endless number of ways you can trick the parser into thinking that the click and the redirect are two unrelated events. Have the click set a global variable, then have a timeout loop watch to see if that variable has changed, then redirect. Have the click event trigger the click event of a different link. Load a new page into an iframe, and have a script on that page redirect to the new location. You can create individual fixes for each of these approaches, but you'll break intended functionality, and there will always be another new more convoluted workaround possible.

Ok I start to see what you mean, but the light-box example doesn't break the rules we stated: it executes fancy javascript, even popups some frame that loads the image etc. But does not change the page location.

In no way opening a thumbnail misdirects me, and it respects the protected scope of "don't change the window.location while I'm in a pending hyperlink click action."

Any 'obvious' hyperlink element can be spoofed using the 'fancy' features. You can't prevent that without breaking the web. The only solution is to check what page you are on after you have clicked because the address bar cannot be spoofed.

As I previously stated, browsers have obivous UI/UX behaviors when relating to hyperlinks. Some (most) can be spoofed, but not all. For instance, modern browsers don't let you create fake status-bars by default.

Edit: also want to point out that the point is to get "one step closer" to good safe browsing, not to fix all world's problems in a single try.