Hacker News Reader

Comment by techsupporter | Hacker News Reader

> However, basically every mail platform creates tailored links to track click engagement.

Yep, even financial institutions do this and half of them don’t even use domains they own for the tracking links.

Years and years of “don’t click on suspicious links” out the window because bank.example.com/creditcard is turned into 4828fjfneo848.totallyfine.adtracker.thirdparty.example.org

I hate all of it but nobody seems to give a shit (nor do they care to implement proper 2FA to effectively guard against phishing) so whatever. If people have their accounts drained because marketers gotta get that sweet engagement metric, what does it matter any more?

View on HN

My work touts the "look at links before you click!". But they also auto forward all email links to a service that scans the link for malicious stuff. The result is that when I hover over a link, I get a REALLY long url, like: https://urldefense.company.com?link=blablablablablahlablabla......

And I can't actually read it.

My work actually visits the url ahead of time.

This sucks when the link is a one-time-use only code.

Sounds like a great target for Server Side Request Forgery, https://owasp.org/www-community/attacks/Server_Side_Request_.... Could be fun to try if that software also visits links for internal-only applications, should such exist in your corp.

This is pretty common and something that bit us last year - enterprise Outlook 365 (or some extension? idk it was def only O365 though) added some security features that would make a HEAD request to any links contained in an email. This messed up our (admittedly antiquated) process for activating users and resetting passwords as it consumed the one-time code our systems generated for them, as you mentioned. Because the app that handled this was old and in the process of replacement we didn't want to invest too much time in rewriting it all, so a quick and easy fix was to have a handler specifically for HEAD requests to those activation and reset resources. The link protection started issuing GET requests a little while after, so we ended up having to add an extra confirmation step so the user had to click something after the link was followed.

To be honest the original process we had maybe wasn't 100% perfect - users can double click links for example, and would see a message that the link had "expired". So from a UX perspective we maybe should've had the extra confirmation step before activation/reset to begin with. But I'm in two minds over email providers following all the links in your emails, it feels a bit creepy

Wow, this behavior seems perfect for sneakily verifying that an email was received. And the user can't do anything against it. It's not a perfect replacement for tracking pixels, though, if you want to figure out whether an email was opened. Creepy.

> Wow, this behavior seems perfect for sneakily verifying that an email was received.

Isn't that pretty much the definition of "confirming your email address" transactional emails? Wouldn't really call this "sneaky".

I read it as anyone – including spammers – who puts link in will get a head request to it from the email provider, thus providing information – even if just that the address is real.

However, the absence of a bounce probably also does that, albeit less reliably.

Some email providers don't bounce/reject specifically to not leak that information as far as I know.

I don’t think it would be that useful to be honest. I don’t think it happens when the email is opened by the end user, but some point during the delivery process. And even then you’d only find out from some email providers - not everyone does it

Does anyone actually send links like that? Any competent programmer will make the link expire on an interaction, not on load - there are some many things that could cause a link to receive a GET request, but where the use wouldn't actually be able to interact with the page.

Using GET for non-idempotent generally considered bad, but it seems that email is a place that non-idempotent GET is still used. I often see it on unsubscribe link.

Yeah, fair enough, I do run into those occasionally too, but most of them these days make sure to require at least a confirmation click.

> I often see it on unsubscribe link.

Those are meant to load a page with a confirmation form that makes a POST request. The GET link can still expire over time, but must never be expired from a GET request: you never know when a link preview bot is going to follow links.

A pet peeve is unsubscribe links are frequently on an obscure domain that has found it's way onto Adblock lists.

That's got be by design.

If something makes itself difficult to unsubscribe you could always feed it to the spam filter

When I unsubscribe from a mailing list I know I didn't sign up for, I'll also hit the report spam button in the hopes it gives them some negative gmail juju.

This does get reported to the sending platform. Stuff like Mailgun and Mailchimp will show you a rate for it, and they do suspend if it gets too high.

Depending on where you do it, yeah, it works. In the gmail interface for gmail, but also in the unsubscribe reason box for the sending platform. Both work.

Do both, but definitely do the spam report via Gmail or your email provider because that dings the platform they use as well. Without a threat to their mailability, they'd have no incentive to keep their customers (the person spamming you) honest.

I do this if my attempt to unsubscribe fails at all.

I mark any newsletter as spam if I didn’t intentionally sign up which is 100% of the time

It's not uncommon for the unsubscribe links to live on the same domain as the link tracking and other features of whatever email or marketing automation platform they are on, so if those are blocked to prevent tracking, the unsubscribe links would be as well.

If I can't unsubscribe with a single click then it's spam and I report it as spam. They don't give a shit about me, so I don't give a shit about them.

And more and more often, unsubscribe links go 403 or even 500 when on Tor or well-known VPNs, while the rest of the site works fine on it. A great way to make me never want to deal with you again is to coerce me to doxx myself to unsubscribe from your newsletter.

I find reporting as spam or setting a filter rule is easier than unsubscribing.

It's easy: I set a rule in Mail that flags every email containing "Unsubscribe" or related terms with a red flag, and I review and mark them as junk when they show up. Every newsletter is spam because I would never ever sign up for one, regardless of whether I do business with the sender. Either they are illegally mailing me spam from some list that they purchased, or they hid their "please don't send me bullshit" opt out when I signed up for their services, because I would never ask to receive marketing or product updates. It's all spam.

> I hate all of it but nobody seems to give a shit

I hope this will change. More companies need to make some noise about it.

> Years and years of “don’t click on suspicious links” out the window because bank.example.com/creditcard is turned into 4828fjfneo848.totallyfine.adtracker.thirdparty.example.org

I got an email from my bank (Barclays) a couple of months ago that literally took me several minutes to determine whether or not it was a phishing email.

It wasn't, but it used badly compressed jpegs for the Barclays logo and the call-to-action button, the link attached to the button had no verifiable connection to Barclays, and for some reason it used backticks instead of apostrophes in the copy.

When I finally did click the link I was half expecting to be taken to a page saying "you moron, this is obviously a scam" in 96pt font.

I spend about 10 seconds at most thinking about if my bank sent me a spammy looking email and then separately go to the bank site and look for whatever they were supposedly talking about.

Rule of thumb: never click on the link.

I just don’t click on those links, except on accident because some jackass made it impossible to copy/pasta the URL on my mobile device because I couldn’t see what the URL was in a preview window.

Could Apple preload those links too the way they want to preload the tracking pixels? (I don't know much about web tech)

MFA won’t protect against phishing.

The MFA we commonly use right now won't protect against phishing because, as I suspect you mean, the codes are not protected against being entered into the "wrong" site.

Proper MFA, like U2F/FIDO2/whatever-it-is-called-today, will protect against phishing because the visited site won't match the hash needed to complete the second-factor-auth-flow.

Yes it does, maybe not directly. Two examples, both 1Password and my Yubikey only autofill passwords based on the domain. I immediately get a tingle when I go to autocomplete a commonly visited website and it doesn't fill ... time to immediately inspect the URL for phishing etc. Those tools have definitely saved me multiple times.

Reply on news.ycombinator.com