Live data from Hacker News

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

support.google.com

231–240 of 271 posts

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

#231

Earlier quoted context omitted.

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

That too as I suspect the unsubscribe links may just be data gathering.

I typically never type in any information because I assume the site doesn’t know and wants to know.

I’d rather just set up a kill rule on my end than risk getting my email on one more list.

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

#232

Earlier quoted context omitted.

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

Sorry, GET requests aren’t idempotent. At the minimum they create log entries. So you can DDoS servers by filling their logs with “idempotent” GETs.

UX is important, and I think saying “suck it users, I’m going to use GET the way I think is write” is not a positive way of thinking about it.

I think the problem is just the mechanics of POST not being allowed in an email, so if there’s a way to POST from just clicking on a link I think we should use it. But there’s not, so having a GET that triggers something is the least bad thing. I like it better than javascript and forms in email. And better than autosubmitting, hidden forms on load.

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

#233
post #229

Earlier quoted context omitted.

Ah interesting, so you're saying that GMail is not likely to be avoiding the POST requests if they're in the JS code? I have a passing, non-professional familiarity with Web practices, so this isn't something I have a great intuition for.

The basic flow would be: - You GET /reset/abc123 - Your server responds back with a page that has a form - There's a hidden field with the token - Javascript kicks in and on page load executes the form as a POST request - Your server responds to that POST request and does whatever it needs to do All of that is kicked off by gmail visiting /reset/abc123, and now it comes down to whether or not gmail's pre-visiting cod…

Right, it's the second part of the fourth bullet that I was asking about. Basically, that it sounds like it isn't feasible for Google to avoid POST requests if they're being submitted from JS.

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

#234
post #102

Earlier quoted context omitted.

"Things change as time goes on" is not an excuse to ignore valid standards. All big email providers know this and know that GETs should not affect their unsubscribe/confirmation links. It's part of their job.

"Things change as time goes on" is not an excuse to ignore valid standards. You're talking about an idealised, theoretical world. I'm talking about the real one, the same one where big mail providers routinely ignore valid standards themselves in their efforts to fight real world problems like spam and identity theft. Again, if someone is going to help themselves to private information then the burden should be 100%…

Yes, people often don't follow standards, but they are sometimes useful in the real world for deciding who should fix their software, and for making breakage less likely due to whatever changes happen in the future.

Google isn't the only vendor you need to worry about. Other mail agents, browsers, or proxies will sometimes prefetch URLs. On the web you often don't know what software your users are running or what it will do, and there's no way of knowing what they'll do in a year. Users have the right to run whatever mail software they want. But if you follow standards then you have a better chance.

If you don't, it's a risk. Sometimes vendors do go the extra mile to tolerate other people's buggy code, but not always.

You can decide to blame everyone else if you want, but if you use GET requests for user actions, something will likely break eventually.

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

#235
post #97

Earlier quoted context omitted.

They are in fact private names, because they're unknown to the public. This is in fact an authentication system. Yes, the public could guess a 128-bit random value and log in - but that's no different from the ability of the public to guess your password, or your session cookie, or your SSL session state, or whatever. Every authentication mechanism is based on "There is a high-entropy value, and nobody but the author…

You're doing some subtle jiu jitsu and extracting a lot of benefit from responding to the previous message as if it said "if the names are not known to the public, then[...]". It does not. Resource identifiers, on the web[1], are not private names—not even by virtue of the fact they were communicated over a private channel—and they need to be treated as public, full stop. URLs are not private names, simply because of…

I'm not following your argument. What is this thing that URLs are which makes them public?

For instance, I could argue "Fingerprints are not passwords, and they need to be treated as public, because of what they are" - because I can finish that sentence with "and what they are is a pattern that's left on every single random thing you touch, and is also immutable and impossible to rotate."

What's the analogous thing for URLs?

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

#236
post #109

Earlier quoted context omitted.

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.

I agree no one is saying that. I think they are being unsound in refusing to say that but also saying that URLs don't count as an authentication system.

Is the argument "Information in an email should be treated as public"? Then how do you validate users on signup in the first place? How do you ensure that someone owns an email address that they claim to own?

Is the argument "Information sent over HTTPS should be treated as public"? Then why does the argument not apply to passwords or cookies?

If the argument is something else, what is it?

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

#237

Earlier quoted context omitted.

"Things change as time goes on" is not an excuse to ignore valid standards. You're talking about an idealised, theoretical world. I'm talking about the real one, the same one where big mail providers routinely ignore valid standards themselves in their efforts to fight real world problems like spam and identity theft. Again, if someone is going to help themselves to private information then the burden should be 100%…

Yes, people often don't follow standards, but they are sometimes useful in the real world for deciding who should fix their software, and for making breakage less likely due to whatever changes happen in the future. Google isn't the only vendor you need to worry about. Other mail agents, browsers, or proxies will sometimes prefetch URLs. On the web you often don't know what software your users are running or what it…

Yes, I understand the reason for the standards, and other things being equal I am all for following them. I just think it's strange that an organisation spying on someone's communications and then doing anything it otherwise couldn't and breaking anything as a result should be getting such a free ride. There is no law that says any web application you write has to follow those standards, and the only reason not doing so is a problem in this case is because the likes of Google didn't mind their own business.

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

#238

Earlier quoted context omitted.

Yes, people often don't follow standards, but they are sometimes useful in the real world for deciding who should fix their software, and for making breakage less likely due to whatever changes happen in the future. Google isn't the only vendor you need to worry about. Other mail agents, browsers, or proxies will sometimes prefetch URLs. On the web you often don't know what software your users are running or what it…

Yes, I understand the reason for the standards, and other things being equal I am all for following them. I just think it's strange that an organisation spying on someone's communications and then doing anything it otherwise couldn't and breaking anything as a result should be getting such a free ride. There is no law that says any web application you write has to follow those standards, and the only reason not doing…

There are other reasons but you're ignoring them.

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

#239

Earlier quoted context omitted.

I was just wondering if a web page that counts visitors is idempotent. Not?

It changes state on the server, i.e. the counter. So no.

I’d say it depends on what the counter is for. If it’s used to bill the user per pageview, then it’s user-visibly not an idempotent action, so no. If it’s used to estimate site speed, then the user doesn’t care, so yes. (In fact, analytics is the example I see most often under “non-idempotent stuff it’s OK to do on a GET”.) If it’s used to display a counter in the site footer, then you might wish the user cared for your bragging, but they probably don’t, so yes with a disapproving glance in your general direction.

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

#240
post #173

Earlier quoted context omitted.

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.

Tons of services send a verification link after registration, and when you click the link you are taken to a page that says "You're verified." But in those cases there may be an automatic POST after you travel to the link, so it wouldn't be triggered by gmail looking up the url.

This may be for the purpose of ensuring the email address itself is deliverable. You don't want someone to sign up with random garbage, then try sending notifications, newsletters, etc. to it- I believe doing so can affect domain reputation.

For this use-case, it seems like even an automated link click would be a good signal of a deliverable email address.

Post reply on HN