211–220 of 271 posts
The email should have a link to a page with a CAPTCHA challenge and a form that submits by POST. The POST with valid captcha solution testifies a human clicked purposefully.
Hard no. CAPTCHA is a blight on the web to anyone who values privacy or has accessibility issues.
Earlier quoted context omitted.
Is it possible to embed a link that uses POST in an email? I can't think of a way unless form tags work, but then the link wouldn't work in a plain text email reader
You can use in email body (obviously does not work in plaintext mode)
Earlier quoted context omitted.
I this sometime triggers a warning to the user (something like “Are you sure you want to submit form data to external site?”), which may not be the best end user experience.
If you put a header “account verification form” above the button, it's a better experience; the user knows what the computer is calling a form.
Earlier quoted context omitted.
You can also check for various headers to determine (with quite good accuracy) if a link was clicked by a human or fetched programatically. Here's a list I've accumulated over the years for virtually the same feature as yours: - `sec-fetch-dest` header is present (HUMAN) - `accept` header is present (HUMAN) - `from` header is bingbot(at)microsoft.com (AUTOMATED) - `user-agent` header includes BingPreview (AUTOMATED)…
Also most humans do use browsers, so if you don't have any following requests for resources like scripts, images or just the favicon, you probably got visited by a bot.
I have my browser configured to retrieve the page only and no additional requests for CSS, images, or javascript.
Earlier quoted context omitted.
It takes more effort and more users will decide to move elsewhere. I don't really believe that if someone can't bother to copy code from e-mail, he's worthy to have as a client, but some company are obsessed by metrics and percentage of successfully registered users is one of those metrics.
I understand your way of thinking, but we ended up having a flow for a government site where users had 2-3 steps what normally could be done in 1. Also many were not tech savvy and confused. So we ended up adding JS to automate the click.
Earlier quoted context omitted.
It’s likely faster for the noscript case.
Yeah, I don't know about that. Wouldn't it be that the query strings differentiate the two links? I assume so, because of an old trick where query strings are used for ad-hoc cache control as in /style.css?1629472765
I always wondered when single-click unsubscribe was going to be a problem because of exactly this. I mean, how do you expect to give a URL to Google and have them just never crawl it?
Oh, that's the rake we stepped on. Bloody obvious in retrospect, but it took us an embarrassingly long time to realize that we were leaking mailing list subscribers because of these one-click unsub links.
It didn't take some companies long. They were just a bit more, uhhh, shady about the knowledge.
I built a small Go web app to do some security testing. When a user registers for an account, I generate a 128-bit secure token and email it to the address they provided (as a URL). Token URLs look like this: /validate/email/1d00a5c2648c211befd33f5a8a7cbfab The token is cryptographically strong and disappears after access. It can't be guessed and no one but the email account holder should click it, but I am seeing th…
Make the link expire after a certain period of time and not after first click.
This is a good feature in my opinion. Why should I let the sender know when I click on tracking links or view the email? If you really want to, just filter out clicks from AS15169.
> This is a good feature in my opinion. Some links include automatic login functionality. I definitely don't want Google logging in to my accounts.
Then don't use websites who provide links that provide insecure features.