Hacker News Reader

> You're not supposed to send off a POST request directly as the page has been loaded to exchange the tokens, but require the user to click on a button to confirm the activity.

Since requiring the user to do anything drastically reduces the go-through rate, the current "standard" is to use either a meta-refresh tag, a HTTP Refresh header [1], setting location.href from JS or a <form> that gets submitted via JavaScript, and a <button> inside a <noscript> for those that don't do JS.

Used to be enough but nowadays content scanners run legitimate chromium embedded and whatnot, which obviously trips over at least the refresh tag/header and the automated Javascript solutions. And that's the problem.

[1] https://en.wikipedia.org/wiki/Meta_refresh

> And that's the problem.

Which again, it's a known problem, existed for many years already and we have a work around for. If you want to do POST requests from URLs sent via email/other communication platforms, you need to make it so the user confirms the activity.

Users who wanted to sign in and have to press a button after loading the page instead of just logging them in won't suddenly not want to login. They have a clear purpose when clicking the link, regardless if they have to click one button afterwards or not.

And besides, if you don't implement it like that, you'll have even more users dropping off because they literally won't be able to sign in at all, no matter how badly they want to.

Won't this shift the meta for malware to a "button" that is 99.9% transparent and overlays the whole page in the hope that someone will accidentally click on it when trying to select text or something? A lot better than 0-click ig but might catch people now and then.

> Which again, it's a known problem, existed for many years already and we have a work around for.

Not really. Other than Google's crawlers it was rare to see full browser engines or even JS runtimes as part of "security" solutions.

Both Microsoft and Google been doing this in emails for many years. I linked elsewhere a SO question from 7 years ago talking about this issue for gmail, others mentioned some Microsoft stuff there too.

So the "current standard" is not working at all any longer.

What is the solution? Like making the user click again might be against GDPR.

https://www.onlinetraveltraining.com/uk/news/posts/why-one-c...

> As of the 1st June 2024, the one-click unsubscribe feature on email is mandatory, and enforced by Google as a requirement for bulk senders.

Huh? This has nothing to do with the unsubscribe-header thingy. This is about when you for example provide a URL that contains a token in an email, which you exchange for an authentication token once the user visits the URL. Some people implement that page to automatically do the exchange on page load, instead of waiting for the user to click on a button.

> What is the solution? Like making the user click again might be against GDPR.

Dropping all packets from Microsoft or Google in the firewall ? /s

Because of this I always implement magic links with an additional link to click. Robust and easy and not a thing you do 100 times a day anyway.

Microsoft's Office365 nicely clicks the links for you. Had this issue with Webhelp's emails where Microsoft was nicely cancelling the receipients transport by clicking on every Cancel link on the page and clicking on the javascript confirm link to cancel the transport within 20 seconds of their staff booking transport. Quite annoying. Ended up having to block large parts of Microsoft's IP ranges.

They’re clicking the buttons??

Wait they click on buttons in your experience?

What about double opt-in links? What about unsubscribe links? Do these need to be triple opt-in now because of Microsoft?

> now because of Microsoft?

I'm not sure why people believe this to be a new issue, I think the first time I myself implemented a work around for this issue was like 4 years ago, and here is a Stackoverflow Question about it from 7 years ago: https://stackoverflow.com/questions/43443947/how-to-stop-e-m...

Outlook/Microsoft is not the only ones who do this either, when I first had to work around it myself it was because it was happening in gmail if I remember correctly.

Accessing links (GET), yes, executing JS and POSTing is the new thing. Putting an XHR in DOMContentLoaded was the workaround for the behavior you are talking about.

You misunderstood the submission article and the problem if you think Microsofts scanner is POSTing by itself.

> Putting an XHR in DOMContentLoaded

Since the first time I encountered this problem with my users (4 years ago at least), that was never a solution that worked for everyone.

what if microsoft decides they not only want to load the URL in messages, but also click links and click buttons? presumably this is to detect bad/dangerous content. bad people will also just put that dangerous stuff behind a link or button if it's that easy to evade their checking.

or why exactly are they following those links again? perhaps it is for previews instead of "security"?

from the article:

> Over time, it also became OK for software to visit links in email to find out what was behind them.

why would that be OK? if i email a secret link to someone, i fully expect it to stay between the recipient and me. not some company reading along. but that's why i don't have accounts with these types of companies...