> Are we really promoting good security practices or just adding security theater cruft?
We're taking away easy attacks, just like blocking known spammers from delivering emails to your MTA. Yes, it doesn't solve spam completely, but it reduces the amount. Add other things like SPF, DKIM etc and you can identify even more malicious emails and warn the user. And certainly, the OP's description mentioned matching urls (though the text would have to match the href, so "ebay.com" would likely be fine for "https://ebay.com/something"), but again: 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? I'm sure there are also reasons why a site operator wants to avoid SSL, but I do like the fact that many browsers do warn users when (potentially) sensitive data gets transmitted via plain text.
> Who said anything about a third party?
The super majority of click-tracking runs via third parties. And yes, every additional detail you share with them (PII has gotten a lot of attention lately, and I'm beginning to come around and love GDPR) will put your users more at risk - now it's not just your database that risks exposing your users when a leak/breach happens, it's also your email provider's.
> How would you implement link url / text mismatch blocking? Have you thought through the consequences for your users and their understanding of security or satisfaction with your product?
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. "Hey, let's not do SSL, it's not that simple to build and might inconvenience a user that has their clock set 100 years into the future"
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.
> 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.
I don't believe that "copy link text to avoid tracking" is a relevant part here, so I still don't understand why you'd want to give the impression of a text-link with a different URL. I see lots of malicious reasons, but I don't see valid ones where there is a strong case that this is a necessity. Why should we teach users that "don't trust your lying eyes, just click on whatever" is ever a good idea? Why shouldn't we teach them to not touch something that is trying to deceive them? If we teach them to ignore these things, we're making it easier for scammers.
Sure, blocking links to domains that don't match the sender's may be something as well, but I do see lots of cases where that's totally normal, i.e. me sending you an email saying "hey, I read your blog entry, and this site here does what you want". Mind you, that's just a link, it's not a link that is trying to confuse you about it's true target.
> You do expose additional information about the user's clicks and IP address. If this is something your company is concerned with
If any company isn't concerned with that, they either don't do business in Europe or they should talk to a lawyer. ;)
> If you are trying to promote the use of first-party click tracking (or just discourage third-party click tracking)
Neither is my intent, I just don't see valid reasons to pretend you're linking to one URL when you're linking to another when there's an easy alternative: put words into the linktext, not URLs.
It's like FB's idea to pressure users into giving them their passwords for their email account. Terrible idea, no valid business case ("it's easy and we can really check that they are the owner of that email account" isn't valid), but lots of reasons for malicious actors, so somebody telling you "give me your email password" is a warning sign for everybody. Trying to confuse users about what URL you're linking to is as well.
We're taking away easy attacks, just like blocking known spammers from delivering emails to your MTA. Yes, it doesn't solve spam completely, but it reduces the amount. Add other things like SPF, DKIM etc and you can identify even more malicious emails and warn the user. And certainly, the OP's description mentioned matching urls (though the text would have to match the href, so "ebay.com" would likely be fine for "https://ebay.com/something"), but again: 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? I'm sure there are also reasons why a site operator wants to avoid SSL, but I do like the fact that many browsers do warn users when (potentially) sensitive data gets transmitted via plain text.
> Who said anything about a third party?
The super majority of click-tracking runs via third parties. And yes, every additional detail you share with them (PII has gotten a lot of attention lately, and I'm beginning to come around and love GDPR) will put your users more at risk - now it's not just your database that risks exposing your users when a leak/breach happens, it's also your email provider's.
> How would you implement link url / text mismatch blocking? Have you thought through the consequences for your users and their understanding of security or satisfaction with your product?
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. "Hey, let's not do SSL, it's not that simple to build and might inconvenience a user that has their clock set 100 years into the future"