5 ms·

I can reproduce it on gmail.com Google seems to hide this via Javascript. To reproduce in Chromium: Enable dev tools, enable "Preserve log", go to settings a

I can reproduce it on gmail.com Google seems to hide this via Javascript. To reproduce in Chromium: Enable dev tools, enable "Preserve log", go to settings and enable "Auto-open DevTools for popups". Then click on a link in a mail. Now you can see under the Network tab, that the new window did not go to the link you clicked but to a Google redirect url. I guess Google outputs a normal link in the html but then intercepts the click and sends you to their tracking url. As nobody seems to be able to reproduce it for IMAP, I guess that either A) the author is in an a/b test group that got targeted with the tracking links or B) he uses an email client that uses some other protocol or C) He is outright lying or D) Something else. My money is on B. The author says on Twitter he uses mail.app on a Mac. I would not be surprised if the developer of a hip shiny Mac app happily used the newest shiny API from Google. Can someone with a Mac and that app reproduce it?

jeffbee 6y ago
Google has been rewriting the click target in gmail's web presentation for years. That is not the same, or even related, to changing the URL in the email itself (as presented by SMTP or IMAP).
oefrha 6y ago
> Google seems to hide this via Javascript. I'm like 200% sure Google can't "hide this via JavaScript" (whatever "this" means) in my native mail client if they have actually rewritten the URLs, which is the accusation here.
- TooCreative 6y ago
  That is why I said "on gmail.com" which is Googles web interface. I don't use a local mail software.
- soraminazuki 6y ago
  But you said in another comment that you couldn't reproduce the OP's accusation "including on webmail." Gmail has been rewriting links in the web interface for all users using JavaScript for years now.
  - oefrha 6y ago
    Maybe my comment isn't clear when viewed in isolation, but I was (and I believe OP was) talking about rewriting href of a tags, or in the case of bare links, rewriting the text altogether. So adding a data-saferedirecturl attribute and using that in the click handler is entirely different. Btw the data-saferedirecturl attribute is not found in the email bodies when downloaded via IMAP. I didn't check Gmail's REST API but I assume someone else has checked that too with a client using that. I mean, given the linked screenshots, the accusation is very clear, and no one has thus far reproduced anything close to that. (Incidentally I'm no stranger to Google redirects. I don't use webmail normally, but I did write an extension to remove the redirects from Google SERP...)
    - soraminazuki 6y ago
      > So adding a data-saferedirecturl attribute and using that in the click handler is entirely different. The end result is the same. Gmail is rewriting url in their web interface. While there isn't enough evidence yet to decide whether they're attempting to do the same for IMAP, the fact that they do it in the web interface is undeniably true.
jpp 6y ago
I can confirm I'm seeing this -- I just noticed, searched Google, and ended up ... here. I have an email generated by one of our internal systems with a link to it, fetched via IMAP using Apple Mail, and the link is edited to be like so: https://www.google.com/url?q=<ORIGINAL-URL>&source=gmail-imap&ust=1603744768000000&usg=<SOME-TOKEN-HERE> https://www.google.com/url?q=<ORIGINAL-URL>&source=gmail... We're on GSuite Business, and under "Spoofing and Authentication", have "Apply future recommended settings automatically." enabled. Probably some other options, too. I happen to have "Advanced Protection Program" enabled for my account; so this may be happening because of that. Given the phishing attempts I've seen in my career, having this as an opt-in option for certain users ... well, let's just say I've personally had users I would have had this turned this on for and we would all be happier. I can also see the privacy concerns. Perhaps we'll learn more about the opt-in / opt-out details in the coming days, so that users can make the appropriate choices for themselves?
- tcombinator 6y ago
  Can you confirm you account is actually set to "IMAP" and not "Google" in macOS? See my other comments in the thread where this only happens for me under that condition. Downloading the messages via pure IMAP produces unmodified links.
tcombinator 6y ago
I can and have reproduced this for over a week now and have been hammering google & apple to fix it with no luck. Google says it's an Apple issue and Apple says it's a Google issue. The issue only appears to surface under specific use cases and always requires the user to have setup Mail.app on macOS or iOS with the gsuite account/user set to type "Google" vs. "IMAP". This seems to be the real pickle as all the following use cases below require this to be true for the link manipulation to occur. The same messages viewed in gmail.com or in Mail.app on macOS or iOS with the account type set to "IMAP" have their links left untouched. - Sending a message from a gsuite account user to an external party DOES NOT show the issue - Sending a message from an internal gsuite account user to another user in the same gsuite account + another user outside of the gsuite account DOES show the issue - Sending a message from a gsuite account user to another gsuite user in the same account DOES NOT show the issue - Sending a message from an external account into a gsuite account user DOES SHOW the issue (this might be tied to admin settings in G Suite > Settings for Gmail > Safety - still needs to be tested more) - The same messages that DO SHOW the issue only show it in Mail.app on macOS & iOS when the gsuite user account is setup as "Google" vs. "IMAP". It DOES NOT show up in the GMAIL iOS app nor does it show up in the gmail.com web interface. Google support has been effectively useless. Apple support has honestly done more to shed light on the issue. However, both companies are blaming the other and refusing to escalate to engineering or get on a call with the other company to sort this out together. Of course, Google support claims nobody else is reporting this, while Apple support alerted me to this thread. Super frustrating all around. If you are a Gsuite user please report this so I'm not yelling into the wind here. I can also confirm for my account the issue started on October 6, 2020. Do you have a link to that twitter?

jeffbee 6y ago

Google has been rewriting the click target in gmail's web presentation for years. That is not the same, or even related, to changing the URL in the email itself (as presented by SMTP or IMAP).

oefrha 6y ago

> Google seems to hide this via Javascript. I'm like 200% sure Google can't "hide this via JavaScript" (whatever "this" means) in my native mail client if they have actually rewritten the URLs, which is the accusation here.

TooCreative 6y ago
That is why I said "on gmail.com" which is Googles web interface. I don't use a local mail software.
soraminazuki 6y ago
But you said in another comment that you couldn't reproduce the OP's accusation "including on webmail." Gmail has been rewriting links in the web interface for all users using JavaScript for years now.
- oefrha 6y ago
  Maybe my comment isn't clear when viewed in isolation, but I was (and I believe OP was) talking about rewriting href of a tags, or in the case of bare links, rewriting the text altogether. So adding a data-saferedirecturl attribute and using that in the click handler is entirely different. Btw the data-saferedirecturl attribute is not found in the email bodies when downloaded via IMAP. I didn't check Gmail's REST API but I assume someone else has checked that too with a client using that. I mean, given the linked screenshots, the accusation is very clear, and no one has thus far reproduced anything close to that. (Incidentally I'm no stranger to Google redirects. I don't use webmail normally, but I did write an extension to remove the redirects from Google SERP...)
  - soraminazuki 6y ago
    > So adding a data-saferedirecturl attribute and using that in the click handler is entirely different. The end result is the same. Gmail is rewriting url in their web interface. While there isn't enough evidence yet to decide whether they're attempting to do the same for IMAP, the fact that they do it in the web interface is undeniably true.

jpp 6y ago

I can confirm I'm seeing this -- I just noticed, searched Google, and ended up ... here. I have an email generated by one of our internal systems with a link to it, fetched via IMAP using Apple Mail, and the link is edited to be like so: https://www.google.com/url?q=<ORIGINAL-URL>&source=gmail-imap&ust=1603744768000000&usg=<SOME-TOKEN-HERE> https://www.google.com/url?q=<ORIGINAL-URL>&source=gmail... We're on GSuite Business, and under "Spoofing and Authentication", have "Apply future recommended settings automatically." enabled. Probably some other options, too. I happen to have "Advanced Protection Program" enabled for my account; so this may be happening because of that. Given the phishing attempts I've seen in my career, having this as an opt-in option for certain users ... well, let's just say I've personally had users I would have had this turned this on for and we would all be happier. I can also see the privacy concerns. Perhaps we'll learn more about the opt-in / opt-out details in the coming days, so that users can make the appropriate choices for themselves?

tcombinator 6y ago
Can you confirm you account is actually set to "IMAP" and not "Google" in macOS? See my other comments in the thread where this only happens for me under that condition. Downloading the messages via pure IMAP produces unmodified links.

tcombinator 6y ago

I can and have reproduced this for over a week now and have been hammering google & apple to fix it with no luck. Google says it's an Apple issue and Apple says it's a Google issue. The issue only appears to surface under specific use cases and always requires the user to have setup Mail.app on macOS or iOS with the gsuite account/user set to type "Google" vs. "IMAP". This seems to be the real pickle as all the following use cases below require this to be true for the link manipulation to occur. The same messages viewed in gmail.com or in Mail.app on macOS or iOS with the account type set to "IMAP" have their links left untouched. - Sending a message from a gsuite account user to an external party DOES NOT show the issue - Sending a message from an internal gsuite account user to another user in the same gsuite account + another user outside of the gsuite account DOES show the issue - Sending a message from a gsuite account user to another gsuite user in the same account DOES NOT show the issue - Sending a message from an external account into a gsuite account user DOES SHOW the issue (this might be tied to admin settings in G Suite > Settings for Gmail > Safety - still needs to be tested more) - The same messages that DO SHOW the issue only show it in Mail.app on macOS & iOS when the gsuite user account is setup as "Google" vs. "IMAP". It DOES NOT show up in the GMAIL iOS app nor does it show up in the gmail.com web interface. Google support has been effectively useless. Apple support has honestly done more to shed light on the issue. However, both companies are blaming the other and refusing to escalate to engineering or get on a call with the other company to sort this out together. Of course, Google support claims nobody else is reporting this, while Apple support alerted me to this thread. Super frustrating all around. If you are a Gsuite user please report this so I'm not yelling into the wind here. I can also confirm for my account the issue started on October 6, 2020. Do you have a link to that twitter?