Hacker News Reader

Comment by bdefore | Hacker News Reader

In the second link above, a Bing ad is presented to download Chrome while describing a domain of "www.google.com" but when clicked takes the user to googleonline2018.com ... maybe my expectations are out of date, but how is that possible? The otherwise excellent article doesn't explain.

edit: was the second, not first link. this one: https://blog.infostruction.com/2018/10/26/adware-empire-iron...

View on HN

What do you mean by "describing"? If you mean the thingy in the bottom of your screen when you hover over a link, this is trivial to fake and Google itself is the largest user of this "feature". In a Google search, right click a link and copy it, then paste it somewhere. It will be a long ugly google.com tracking URL, even though what your browser showed you in the hover display was the link to the actual website.

Sorry i misstated, it was the article at the second link from post i responded to. first image of that post, under where it says 'Get Chrome - Download Chrome Today' there is a green text that shows www.google.com. I thought that was enforced by the search engine and not able to be manipulated.

At the risk of insinuating too much, there is a concerning incentive for Bing to provide corrupt links to Chrome.

That definitely seems like a major flaw with Bing's search ads. They should be either deriving that green domain name, or verifying it matches the link, or at least verifying that you own that domain.

I can't find a current Bing search ad whose green domain name doesn't match the domain of the destination of the link. Hopefully they've fixed this by now.

> the thingy in the bottom of your screen when you hover over a link, this is trivial to fake

Sounds like a security flaw. Why don't browsers patch it?

Because the company that most benefits from it existing also makes the world's most used browser.

What about other browsers?

Short of preventing JS from triggering redirects, I don't see a way they could, and that's a pretty important feature in modern web apps.

You could lock out JS redirects once the user has clicked on a URL.

If it's callstack-based the event handler could easily just run the redirect in setTimeout. Making it time-based might work, but would break a lot of common use-cases. Maybe they could block only cross-origin redirects?

There still is the issue of Mozilla being the only one without a direct incentive to prevent this fix from rolling out. With their whopping 3 percent market share, I doubt they'd be willing to break a web feature we've had for decades.

Time based? If that's equivalent to "toggling a flag" then yes that's what I'm suggesting.

What use cases would it break? Why do you need a fake URL to show up when the link is hovered?

The way the faking works is that the site catches your click event and redirects you to somewhere else. Therefore, the only fix is to prevent such redirects. Preventing JS redirects would break many things. AJAX form submission with a redirect at the end, for example, is very common.

Preventing them in onclick handlers of a[href] elements would break fewer, but then you have the issue of correlating the redirect with the click. If you simply ban window.href= in the handler, sites could simply use setTimeout or set a flag and have a repeating background task trigger the redirect when the flag is set. Alternatively, you could do something like prevent all redirects X seconds after a link is clicked. Unfortunately, that would only discourage sites that are trying to be fast (like Google). Scam sites are usually slow and bloated anyways.

> AJAX form submission with a redirect at the end, for example, is very common.

Why does that AJAX form need to pretend it's a link to a specific URL?

A button would have no problem, and a link that stays on the page would have no problem.

The trick works by cancelling the link click event and redirecting somewhere else in JS. The only way to prevent that would be to not allow any redirects in JS, including buttons.

I tested it in Firefox and Chrome. While they both display a spoofed URL in the status bar when hovered, they differ if you right-click the link. In Chrome, nothing changes. In Firefox the status bar string changes to the actual, not spoofed URL.

At least in Firefox, one can check easily what the actual URL is before clicking without having to copy-paste elsewhere.

Interesting. I had not known that. I tested it in Firefox and Chrome. While they both display a spoofed URL in the status bar when hovered, they differ if you right-click the link. In Chrome, nothing changes. In Firefox the status bar string changes to the actual, not spoofed URL.

At least in Firefox, one can check easily what the actual URL is before clicking without having to copy-paste elsewhere.

I'm seeing that Firefox behavior in Chrome.

It seems to rewrite the link when it gets a mousedown event. Once I right-click, or if I left-click and then drag (to avoid an actual page navigation), the new hovered URL is the google.com/<tracking> version.

Also this only seems to apply to search ads/promoted results. Organic search results don't get rewritten, and copying and pasting a link address gives me the expected destination URL.

My Nextdns filters blocked the link to TFA (edgesuite.net).

Responding to myself to say: I didn’t realise but edgesuite.net is just an Akamai CDN domain. No idea why it was blocked by my filters.

Reply on news.ycombinator.com