Live data from Hacker News

Gmail is opening and caching URLs within emails without user intervention (2019)

support.google.com

141–150 of 271 posts

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#141
post #78
post #25

Earlier quoted context omitted.

And make sure the action is a POST instead of a GET. GETs should never modify important state.

This is the correct answer. Just because the norm is to embed verification hashes in URLs to be clicked, doesn't mean it's the right way for it to be done. Why not send a short random code by email for the user to then copy into the sign-up form they were in the process of filling in?

Verification hashes in URLs are fine, as long as accessing the URL does not invalidate the hash yet.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#143
post #6

All URLs sent to any major email provider are "clicked" because they are scanning the page to see if it is phishing or otherwise malicious (desktop antivirus and other things will also prescan URLs). It also protects privacy by defeating click tracking on marketing emails. Google will also pre-load all the images in your email too. You shouldn't take any write action to your database just based on a URL being visited…

> protects privacy by defeating click tracking on marketing emails.

I don't think that's true. It should be pretty trivial to know whether a click came from a user or google.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#144
post #112
post #74

Earlier quoted context omitted.

Or link them to a page with a POST form that actually performs the action. That way you only add a single click to the flow, and no remotely sane software will automatically perform POST requests to arbitrary urls.

> no remotely sane software will automatically perform POST requests to arbitrary urls I'm not a web developer. Out of curiosity, why is that?

Websites are generally designed such that GET requests are side-effect free, and POST requests do have side effects. So for example searching on google is a GET request. It doesn't do anything other than serve the requested page. Logging in on the other hand has the side effect of setting cookies and probably writing some stuff to the database, so that's a POST request.

These assumptions are so baked into web software that while assuming a GET request won't do anything zany or overly stateful is probably fine, assuming the same for a POST request should probably be considered negligent.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#145
post #50

Earlier quoted context omitted.

Many phishing test as a service companies will report clicks vs. people who actually interact with the page.

Which is more accurate since clicking a link is not usually an issue while filling out a form on it is the real attack.

Most companies still trigger whatever action (disciplinary, additional training) upon just clicking the link, though.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#146
post #6

All URLs sent to any major email provider are "clicked" because they are scanning the page to see if it is phishing or otherwise malicious (desktop antivirus and other things will also prescan URLs). It also protects privacy by defeating click tracking on marketing emails. Google will also pre-load all the images in your email too. You shouldn't take any write action to your database just based on a URL being visited…

That also include links sent on all major chat, in this day and age, if you not self-hosting, or E2E all your links will be minded by companies.

WhatsApp and Signal notably don't do this on their servers for the link preview features they will fetch it locally on your device.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#147
post #3

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…

I believe this is how they fetch images without meaningfully accessing tracking pixels. If everything send to gmail is opened upon arrival and cached, you know nothing about when or if the recipient actually opened the email.

Last time I looked into this, Gmail was not loading and caching images. Is there any evidence that this has changed?

What is being described here is likely being done for some other purpose.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#148

Earlier quoted context omitted.

That's why it should not be HTTP GET endpoint. Get endpoint should only be when request is idempotent. Use HTTP POST for your usecase.

Well, this is why your email provider should not open your links for you. Use a different email provider instead.

I think I'm going to continue using the one that is pre-opening links that should be idempotent so that it can check them against its heuristics for spam or phishing. That's been really nice to have.

And I'll instead refrain from using sites that inappropriately provide bare get URLs that are really state-mutating booby traps in disguise.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#149
post #78
post #25

Earlier quoted context omitted.

And make sure the action is a POST instead of a GET. GETs should never modify important state.

This is the correct answer. Just because the norm is to embed verification hashes in URLs to be clicked, doesn't mean it's the right way for it to be done. Why not send a short random code by email for the user to then copy into the sign-up form they were in the process of filling in?

This is how Steam does it.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#150
post #126

Earlier quoted context omitted.

That's why it should not be HTTP GET endpoint. Get endpoint should only be when request is idempotent. Use HTTP POST for your usecase.

This endpoint is idempotent - clicking that link multiple times has the same effect as doing it once.

Not if it "disappears after access"
Post reply on HN