Google AdWords Exploit Seen in the Wild

For the latter, as one of my sibling posts points out the user will go "Huh, stupid password manager didn't fill out my password - I'll have to do it manually". Often the password manager even helps them do this in the name of user convenience.

Only Brick wall UX works. That's what WebAuthn does here. Don't offer the user a way to "continue anyway", don't ask them confusing questions, just a brick wall and no way forward.

The user will probably be emotional. Scammers work hard to make your users afraid, or horny, or confused, and so they really, really want to give their bank credentials to https://honest-this-is-your-bank.not-a-scam.example/tmp/back... and nothing you can tell them is going to make them stop wanting to do that.

The brick wall doesn't care about the user's emotional state and will stubbornly resist. Maybe the user will eventually realise it was a scam, maybe they won't, the brick wall doesn't know or care either way.

Brick Wall UX even helps the software engineer. When a manager asks if you can't just add a banner that says "Hi, this is our new web site, please continue to use your old credentials" and thus undo every second of training about phishing your users ever got the answer with a Brick Wall UX is that literally can't work. No matter how much they beg and cajole and swear it's just a temporary workaround, it will not work at all, so they're just going to have to go tell the Big Boss that no matter how much was spent on new-brand-name.example the login system will have to remain forever on login3.long-forgotten-brand.example because that's what some idiot picked five years ago then it was set up and too bad.

> We're taking away easy attacks

What attacks are blocked by this that are not also blocked by using SPF and warning users when SPF is not present or doesn't match?

> what's the harm in linking to the actual URL? Why the need to hide it, IF you already make the link text look like a URL?

This is practically irrelevant. We are discussing the costs/benefits of the implementation of a client side feature, not the ideal form that all emails sent should adhere to (which is a far broader and more complicated topic.)

However, I do have several practical reasons why the link text and url matching can have negative consequences in practice:

Third party tracking issues:

1) Practical difficulty: Most link click tracking is done via third parties (usually the sender's ESP). No click tracking tool I've seen offered by an ESP provides any way to use the link url as the link text (since the link url is usually processed and rewritten by the ESP after the email is composed and sent.)

2) Confused users: The average user has no idea what an ESP is and could be needlessly confused / frightened when shown links so some random domain even when the operator of that domain is trusted by the sender.

First party tracking issues:

3) Removal of user choice: If you only give the track-able url in both link target and text, you FORCE your users to be tracked, rather than giving them the option to select the link text and paste it directly into their browser.

4) User experience: The url that is shown in the link text can be much more informative as to what it does (e.g. shows you your order) rather than an uninformative, generic click tracking link.

> The super majority of click-tracking runs via third parties.

Can you find me some email link tracking services that are not also involved in sending that email in the first place?

You do expose additional information about the user's clicks and IP address. If this is something your company is concerned with, you probably need to implement first-party click tracking both for email AND your website. You should probably also run your own ESP.

If you are trying to promote the use of first-party click tracking (or just discourage third-party click tracking), it would be far better to block all links that go to domains that don't match the sender's domain (or alternately that don't match the sender's domain's SPF record.)

> I'm sure that it's not trivial, but few things are, so rejecting it for that reason doesn't sound like a good idea to me.

I am not rejecting it because it's not trivial. I am rejecting it because thinking through how that implementation would realistically work makes me thing that it would accomplish almost nothing and possibly even negatively impact users' understanding of security.

You seem to think that is not true, so I am asking how this feature can be implemented in way that has a positive impact on security.

My biggest concern is that we shouldn't do anything to teach people that sometimes they CAN trust the link text rather than needing to check the actual URL they end up at. As far as I can think, all the attacks that this stops are better stopped by checking SPF and strongly warning users when it is not present or does not match.

I'm usually much more pro-google than most on HN, but this is quite bad. I understand it enables other features and a technical work-around that also keeps those features is difficult. But this is a disastrous user experience.

It reminds me of caller-id spoofing. Yes, there's a legitimate use case for it. But don't just throw security out the window to enable it, especially when there is a clear and obvious way to abuse it.

A lot of companies send ads to amazon.com rather then their own web site.

it Is something of note that someone who helped pioneer electronic stock trading is now working in digital advertising (which in many ways is similar to to trading stocks)