Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

support.google.com

Post reply on HN
Print view View original

161–170 of 271 posts

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

#161

Post by zenexer »

obuda wrote: post #153
_wldu wrote: 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…

Another idea is to have 3 links, where only one is visible: https://example/com/token?forBots https://example.com/token https://example.com/token?forBots Hopefully any automated systems will open the first or last link first, so that you can save the request info and filter based on that. In case requests come out of order, you can always add a small delay to the "human" link before responding. I haven't yet gotten t…

No link in an email should perform an action on its own. Every link should lead to a confirmation button, at minimum. Too many services automatically open all the links in emails.

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

#162

Post by pwdisswordfish0 »

geofft wrote: post #109
hyperman1 wrote: post #105

Earlier quoted context omitted.

I understand they are known to the public? Every MTA from any random site between the sender and receiver gets the mail, including secrets. They can all decide to scan the site, write them in a log,... Then, when you click the link, if you don't have https, anything between receiver and site also gets a copy of the link. And there are proxys, add injecting ISPs, etc.

Are you claiming that the contents of emails are public? Which "random sites" see emails between sender and receiver? Yes, proxies and ad-injecting ISPs can see the contents of plaintext HTTP. But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system!

> But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system!

That's fine. No one is saying that. They're saying that URLs aren't an authentication (or authorization) system.

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

#163

Post by simonw »

kyrra wrote: post #111
iamdual wrote: post #104

Earlier quoted context omitted.

You need to authenticate the user before the activation.

This. You could rely on a cookie during the get request as well, that you set on the users browser during registration. Or re-auth after click.

The problem with that is people like myself who tend to register on a laptop but then click the email verification link on their mobile phone.

(Because waiting for Gmail to load on a laptop is painful, whereas on my phone is shows up as a push notification within seconds)

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

#164

Post by weird-eye-issue »

_wldu wrote: post #136
weird-eye-issue wrote: post #67

Earlier quoted context omitted.

Btw you could just have JS do a POST request, the user doesn't need to do anything except open the page. This is how unsubscribe pages work.

Thanks. I don't use JS, just Go with HTML templates. I populate the form now with {{ .code }} from the URL so the user does not have to copy/paste the code. But they do have to click 'Submit' to post the form. I think this is a reasonable approach that most users are OK with.

You could add a single line of JS to have it auto submitted as well

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

#165

Post by LinuxBender »

parineum wrote: post #77
_wldu wrote: 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…

Does gmail respect robots.txt?

Not for this use case or crawling. They won't even hit robots. I've caught google, discord, valve, slack doing this on my hobby sites over the years, likely checking to see if the target URL contains obvious malware. In my case the solutions were simple. Add simple auth and/or block IP ranges associated with their AS number. Obviously this isn't the solution for companies, though you could have a unique domain specifically for email URL's and decide what limitations to put in place. Blocking them can flag your site as "malicious" and I am perfectly ok with google saying my domains are malicious.

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

#166

Post by wizzwizz4 »

chrisshroba wrote: post #137
janci wrote: post #113

Earlier quoted context omitted.

You can use in email body (obviously does not work in plaintext mode)

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.

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

#167

Post by sleavey »

prepend wrote: post #155
sleavey wrote: post #78

Earlier quoted context omitted.

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?

> user to then copy into the sign-up form Extra steps are hard and boring and people don’t want to do them. I consider myself a savvy user and I want to click a link. Not click a link, then look up a code from the email, then paste, then click submit. I’d live with having to manually click “I’m sure I want to unsubscribe” or something. This is most annoying when the site wants me to type in my email address to unsubs…

Are we really going to continue to break the paradigm that GET requests should be idempotent to save people an extra click or Ctrl+C and Ctrl+V? Standards matter. In this case Google are doing something that should be allowed, but being criticised for it because it breaks badly implemented services.

Entering emailed or texted codes is becoming more common with 2FA for banking, PayPal etc. anyway so I think most people are going to broadly manage.

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

#168

Post by _wldu »

weird-eye-issue wrote: post #164
_wldu wrote: post #136

Earlier quoted context omitted.

Thanks. I don't use JS, just Go with HTML templates. I populate the form now with {{ .code }} from the URL so the user does not have to copy/paste the code. But they do have to click 'Submit' to post the form. I think this is a reasonable approach that most users are OK with.

You could add a single line of JS to have it auto submitted as well

Wouldn't that be equivalent to just doing a GET?

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

#169

Post by nickjj »

_wldu wrote: 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…

This is interesting because it's something that would likely only happen in production or a staging server.

If you're building your web app in development, chances are your links will have localhost as their hostname which wouldn't trigger a visit from Google. You may also end up having an in memory fake email server to not even send the email in dev too (lots of web frameworks have solutions for this).

Checking the user-agent might work but I'm not a fan of this method because now it sets you up with having to keep a list of all known agents for every email client / service that might pre-visit URLs.

Post reply on HN