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

181–190 of 271 posts

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

#181

Post by eplanit »

_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 like the reason I quit using Skype 10 years ago. My colleagues and I noticed the same thing: send a link in a chat, and within seconds to minutes a request (or more) for that URL from a Microsoft server would be logged. Done and bye.

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

#182

Post by acdha »

vbezhenar wrote: post #85
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?

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.

This depends on your willingness to turn away business, and may not even be legal depending on where you work. In the United States, I would not want to defend that copy and paste scheme as being compliant with the Americans With Disabilities act having seen usability tests from people trying to accomplish that exact workflow using screen readers. Remember that things like cognitive impairments count and, like vision and motor control/range of motion, most of us will be affected at some point in our lives.

What I do think would be reasonable is having a well-labeled link which takes you to a confirmation form: someone can follow it easily and choose to submit it with far less friction and it leaves standard web semantics intact.

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

#183

Post by acdha »

prepend wrote: post #157
duckmysick wrote: post #118

Earlier quoted context omitted.

How many times having to click a link (instead of entering a code) stopped you from finishing a sign-up process?

It’s pretty easy to measure. I had a site with a verification step. And we would see like 20% drop off of people who clicked on the link but never confirmed. Not sure why. We didn’t have them copy and paste anything, just click a confirm button. Switching to no confirm obviously changed this to 0% drop off of people who clicked the link, but the number of people who clicked was the same. It was curious to me why peop…

How would you have known if that 20% were real people and not bot activity?

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

#184

Post by rrjanbiah »

_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…

Here's a quick PoC:

  

  
   location.href = "/actual_validate/email/1d00a5c2648c211befd33f5a8a7cbfab?js=1";
  
  
   Click to confirm your account

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

#185

Post by nickjj »

wutbrodo wrote: post #180
nickjj wrote: post #179

Earlier quoted context omitted.

There were good suggestions in other comments in this HN post. One of them mentioned that you can continue keeping things as a 1 click solution with the token in the URL, but instead of doing the destructive action upon visiting the link -- instead you would get sent to a page with a form where the token is put into a hidden field that gets auto-submit as a POST request with Javascript. This way from your POV it's a…

Ideally they wouldn't be following redirects _if they're POST requests_, right?

True, that was a bad choice of words but gmail could still load the page, execute the JS which in turn submits the form which is a POST request to your back-end. It's technically not following a redirect but it's doing things beyond just visiting the URL linked in the email due to it executing JS.

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

#186

Post by inetknght »

joering2 wrote: post #83
mike_d wrote: post #50

Earlier quoted context omitted.

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

Would you mind naming some? I kind of have a hard time finding those, and some time ago I purchased phishingly.com for a side project, but it doesn't seem I will be working on this anytime soon, so I may as well pass it on.

> Phish testing campaigns in companies that send fake phishing emails to employees, are probably full of inaccurate data due to this.

Anecdata: just running curl on one of those test URLs will trigger a failure and can result in a long discussion with HR and IT.

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

> Would you mind naming some?

KnowBe4 is one such company. Their emails are also easy to spot because they'll have an X-PHISH-TEST email header.

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

#187

Post by obuda »

eplanit wrote: post #181
_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 like the reason I quit using Skype 10 years ago. My colleagues and I noticed the same thing: send a link in a chat, and within seconds to minutes a request (or more) for that URL from a Microsoft server would be logged. Done and bye.

Wouldn't be surprised if pretty much every communication service is doing this.

I sent a link to a large file over Viber and immediately some ip connected and started downloading. Stopped at 350mb of around 3.5gb. I get that they want to show thumbnails or whatnot, but they just don't discriminate between content types.

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

#188

Post by tmoertel »

red_admiral wrote: post #154

Wasn't there an issue like this years ago in something called Google Web Accelerator (I think it was a toolbar for IE). Theory: it preloads links in the background. Practice: some old bb showed a (delete) link after each post and a (ban) link, among others, next to each user if you were logged in as administrator. All of these sent GET requests because some developer hadn't read that part of the standards, and there…

Yes, we had this same scenario play out 16 years ago, and it seems that many modern web developers have forgotten its lessons:

https://blog.moertel.com/posts/2005-05-06-google-web-acceler...

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

#189

Post by 867-5309 »

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…

>This is most annoying when the site wants me to type in my email address to unsubscribe.

I've become increasingly suspicious of this practice

if my email address is in the URL, why don't you autofill that email box for me? if it's not in the URL, why aren't you fetching it from your database using my unique hash in the URL? do you even keep any records of email subscription preferences? am I just signing up for more shitty spam by giving you my email, again? am I just being marked as 'active' i.e. fresh meat, somewhere in the spammiverse?

these questions become more poignant and the suspicion more fiery when, low and behold, it turns out you are still subscribed

I don't fill them in any more, I just block the sender

don't get me started on the "it may take up to 28 days for our systems to register your desertion" bollocks -- I'm not working a contractual notice period, or running a lap of dishonour. it's a bitflip to 'false' in the 'is_pesterable' column, else a respectful deletion. it takes microseconds, not weeks!

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

#190

Post by obuda »

rrjanbiah wrote: post #184
_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…

Here's a quick PoC: location.href = "/actual_validate/email/1d00a5c2648c211befd33f5a8a7cbfab?js=1"; Click to confirm your account

Why the prefetch though? Reason being bots don't open them? If so, this is a really good idea!
Post reply on HN