Send me an email at sneak@sneak.berlin and I'll send you my G Suite address that you can send a test message to that contains a URL, and I'll forward it back to you from my non-G Suite account so you can see what happens.
ust is a timestamp. usg is probably some kind of HMAC (q || ust, secret) so that only google can generate the redirecting urls. If you change the usg, the redirection fails. The same happens if you change ust or q.
It's to protect the privacy of the Gmail user - it means the website doesn't get to know that you came from gmail.com. Google doesn't get any extra info, since they already had all your email contents and you already had a privacy agreement with them.
One could argue that they have to do this to meet the law.
This only works for inline images because Google caches them, and then you get the images from Google’s cache. It has nothing to do with external links.
If Google redirects you to a website, you’re still going to the website. Unless Google internally follows all the links in emails it won’t do anything to help spam. Not to mention all tracked links I’ve ever seen track primarily based on the URL itself.
Additionally, Google adding a redirection step won’t save anything, except show via HTTP Referer that you were linked to this page by Google. If you clicked the link from a desktop IMAP client you’d have no referer, so this is a net loss for privacy, not a gain.
I moved to fastmail. Biggest pain was all my filters that I ported to their rule syntax and still manually maintain. I believe they have a better way to do this 5+ years later, but that is my experience.
I moved to fastmail earlier this year. Honestly, it took a full day of updating all my accounts on every site that used my email. It helps to have a password manager to keep track of progress.
Since then it's been pretty good. I keep my old gmail as an additional account on my email client to track things I've missed, but it's been surprisingly little.
1. Get Fastmail
2. Forward all your email from gmail to Fastmail. Use this time to update your contacts, etc.
3. After 30 days disable gmail forward. You will probably keep the email address for spam.
For Calendar - you can have fastmail pull your gmail calendar. Keep that in place to help transition recurring meetings to fastmail, and then eventually you can sunset that too.
Do invest in your own domain name so that if you need to leave fastmail in the future you can do that more easily.
I would definitely recommend using 2 email addresses. Pick one for your important stuff and another for spam (give this out to merchants and what not). Protonmail works but there are others. Also realize that you are not going to self destruct if you miss an email from migrating as long as you cover the most important contacts. It can actually be a good spring cleaning exercise.
Can't reproduce on either Gmail or GSuite, including on webmail (I thought this could be some sort of "you're leaving example.com, do you really want to do that" thing, but nope). The part about IMAP being affected sounds especially suspicious. Knowing op's track record I'd rather hear from some more impartial sources.
Screenshots are not completely made up. At least the `usg` HMAC seems to be valid, and timestamps are recent enough, so the redirector URLs are legit. Of course it's possible to generate the valid redirector URLs in other ways.
So if this is a scam it's not a completely stupid scam.
Anyway, A/B testing or gradual deoployment is a thing. I'll not turn against a fellow hacker and call him shady, just because a potential A/B gaslighing practice from some megacorp. ;) I'll just wait.
Sorry for us being skeptical of 140 character claims...
I don't see how that url means Google is doing this, when none of us have been able to verify. There could be 100 different things touching your email doing this.
Pretty sure most hn wants this to be true as a reason to sharpen pitchforks.
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.
They can also use this for phishing prevention. There are probably other ways to do it -- e.g. you could rewrite the url dynamically at read time if it's been detected as a phishing attack -- but using a redirector is likely simpler.
Tbh I'm struggling a little to understand what the threat model is here. You trust gmail to receive and handle your email. In the vast majority of cases, you're accessing the email through their web frontend, where they could easily detect hovers and clicks and log those with fair reliability, if they had nefarious ends in mind. But them using a redirector is a bridge too far? If you trust them to do the first two items, it seems a little far fetched to distrust the last.
If they're rewriting emails that you send out, that allows them to also track what the recipients of the emails do, even non-gmail ones. And not every gmail user uses the webmail interface either -- many use standalone clients that wouldn't normally have this tracking.
Also, there is something very wrong when we're okay with Google rewriting parts of our emails. How long until they decide to start modifying other bits of our emails? Reading the contents of the email is one thing, modifying it from its original is a whole 'nother ball game.
That's not the claim. The claim is that they're rewriting urls you receive. I suppose if the imap claim is true, and you reply, and you quote the redirector url in your reply, and someone clicks that link, they could detect it. That seems a little annoying and presents a slight risk, but it doesn't seem like the type of thing that would be intentionally designed in, even if I model google as completely amoral and short-termist. There just doesn't seem to be much advantage in it.
> And not every gmail user uses the webmail interface either
That's why i said the vast majority of cases, not "all." :)
And why I started with 'If' -- my previous comment is preconditioned on Google actually doing what the OP originally claimed (which didn't seem to be specifically limited to downloaded emails,) a claim I do find dubious.
Not seeing how this observation addresses my question about the threat model. I mean you're absolutely right (and I think that assumption is also accurate), but I don't see how it's relevant.
Is the another non chromium browser that can handle more than 5 extensions?
Ff extension management is terrible which i find unusable in an age where I need extensions to prevent sites from removing usability features like select, copy, and paste.
I'm using brave but I don't fully understand how it's related to chromium and if it's a true fork that they are going to be able to maintain independently. I have many many extensions in brave and an extension manager that let's me toggle them right from a drop down. Any suggestions?
This is about gmail, not chromium, but nevertheless: If you’re not willing to adapt your workflow to something other than chromium, maybe you don’t value your privacy as much as you think you do.
Correct I value basic usability (the ability to use many plug-ins in this case) over privacy. This is why I don't use proton, cause I can't actually get anything done with it.
In that case, I'd urge you to tone down your negative criticism on Firefox.
You've already decided that you are not willing to use it over issues you have with it: that choice is fine. Telling others in relevant discussions why you made that choise is, too.
No-one asked you why you chose not to use Firefox in a thread about Gmail. Yet you managed to inject your FUD here nonetheless: Firefox can handle 5+ addons just fine. But now some random passersby might get the impression that Firefox is a burning dumpsterfire based on random negative critiques that aren't even in the right place nor true at all. That helps exactly no-one.
I have used Gmail since you needed an invite to use it and I've never had any other assumption than my e-mails being about as safely tucked away as they would be on a public notice board in a town square, and that Google in addition to this is probably scanning them frenetically to figure out what they, or more specifically their advertisers, can try to sell me.
If I need to send something I actually care about I wouldn't use e-mail in the first place. It's a low-effort type of communication with normal people who don't care about security, so I'm not going to waste time making my end of that line of communication an impenetrable bastion.
"Now?" Has this not always been the case? I tend to use the web UI on my desktop which, IIRC, has always made links bounce through a Google. I use an app on my mobile device so I can't confirm whether links bounce through Google.
Is Google rewriting the links in the message such that if I forward to someone's non-Gmail address, they still bounce through Google?
Or is the client 'rewriting' links dynamically? This same thing happens all over the web. Drop a link in your Medium-hosted blog, and they'll front the link with their own and then redirect.
Can't repro. Links in text/plain, HTML, and mixed survive round trip through Google. Suggests that whatever client the OP is using is confused by the data-saferedirecturl attribute in Gmail's web presentation?
Yes, I think he is talking about the data-saferedirecturl attribute. He's not wrong though, as the redirect stored in the attribute is loaded when you click a link.
So just like Microsoft has literally done for years?[0] I don't know how many times I've clicked on internal documentation that has a link that went through Outlook at some point and was wrapped in a safe link. It's designed to catch bad links without safe browsing in your browser (which things like IE and old Edge didn't have).
It is already annoying that they do that with search results.
Does anyone know a good/open source extension for chrome and Firefox that de-google the link before you click on it?
See my longer replies in the thread, I've tested this extensively and can reproduce it reliably. Please report this to google to help back my claim which they of course are casting doubts on left right and center.
I hate the Google redirects because they are noticeably slow. They did more to move me off Hangouts than anything else. They also plague Google News, but AMP is slowly "fixing" that problem.
Me too. Noticeably slow is a bit of understatement. Often times, I have to wait >4s for a redirect, which is kinda infuriating, given that I know it's not the issue of the actual website, just google messing with the URLs.
Why does all the SPDY nonsense matter when Google adds huge latency in other ways.
Its been a long run with gmail but I'm going to make the full leap to protonmail pretty soon. It takes a little work to migrate things but I just cant stand gmail for so many reasons now.
And after Google pay thought it was a good idea to send my phone number out to every online merchant (I now get nonstop spam texts and calls) I've had it with the company.
I can't reproduce this either, so I'll ask maybe a simple question: how does URL-rewriting benefit Google in this situation?
Google already knows the bodies of emails and can do whatever analytics they please on them. The vast majority of users are also using it via their web client, meaning that Google can put arbitrary JavaScript on the page to record which links are being clicked on. They already have most of the metadata that they could scrape from a rewritten URL, since you're already on their property. It's possible that I'm missing something, but it feels like it's a lot of effort for information that Google already possesses.
> how does URL-rewriting benefit Google in this situation?
When I use, say, thunderbird, Google does not know whether I opened an email, interacted with links on them or downloaded images/external resources in them.
With link-rewriting, when I click on e.g. shopping.example.com/product/1337 and not on shopping.example.com/product/42 in an email, google now knows that "berkes, thunderbird-user is more likely to like product 1337" and can offer that data to advertisers.
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.
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).
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.
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.
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...)
> 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.
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?
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.
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.
This doesn't seem to be new, there's a Medium post from a year ago[1] talking about how the "data-saferedirecturl" attribute is used by Google to track clicks with Javascript, there's a question on support.google.com[2] with 100+ upvotes and no response asking what this attribute is for and how to disable it, and it even shows up in an internal (at least, targeted towards internal readers) U.S. Department of the Interior page which explicitly states that employees should not paste links from Google[3].
It's worth noting that this also happens on the "HTML version" of Gmail.
Advanced Protection is that ultra‐secure mode that requires hardware security keys to login and prevents third‐party apps. Here’s a quote from its advertising copy:
> Protection against malware is built into Google Chrome, but Advanced Protection performs even more stringent checks before each download. It flags, or even blocks you from downloading files that may be harmful.
Sounds an awful lot like what’s going on here. It would explain why nobody’s been able to reproduce it—almost nobody has AP turned on. I imagine the number of people
1) with AP turned on
2) using a third‐party mail client (mail.app)
3) viewing plaintext mails instead of HTML mail where the link rewriting is less obvious
I can confirm this has nothing to do with that as I do not have it enabled on my account and can reliably reproduce the issue. See my other replies in the thread for more details.
88 comments
[ 540 ms ] story [ 1863 ms ] threadHow can I replicate this?
Perhaps some law enforcement agency has asked google to specifically track URLs in your messages and it's just you seeing this.
One could argue that they have to do this to meet the law.
That's entirely solved by Referrer-Policy: no-referrer, so no.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
(Unless you're talking about someone using another webmail client that doesn't set the header, which would be a stretch.)
If Google redirects you to a website, you’re still going to the website. Unless Google internally follows all the links in emails it won’t do anything to help spam. Not to mention all tracked links I’ve ever seen track primarily based on the URL itself.
Additionally, Google adding a redirection step won’t save anything, except show via HTTP Referer that you were linked to this page by Google. If you clicked the link from a desktop IMAP client you’d have no referer, so this is a net loss for privacy, not a gain.
Somewhere in the terms of service:
> This license allows Google to [...] modify your content, such as reformatting or translating it
Without debating the legality of this, surely you are aware that agreeing to something illegal does not make the thing legal.
It very often does because much illegality has absence of consent as an essential criterion.
I would prefer a native email client coupled to a simple hosting solution.
Since then it's been pretty good. I keep my old gmail as an additional account on my email client to track things I've missed, but it's been surprisingly little.
For Calendar - you can have fastmail pull your gmail calendar. Keep that in place to help transition recurring meetings to fastmail, and then eventually you can sunset that too.
Do invest in your own domain name so that if you need to leave fastmail in the future you can do that more easily.
https://twitter.com/sneakdotberlin/status/131783835638279782...
It says source=gmail-imap right in the URL. Look.
Can someone else verify with raw data?
So if this is a scam it's not a completely stupid scam.
Anyway, A/B testing or gradual deoployment is a thing. I'll not turn against a fellow hacker and call him shady, just because a potential A/B gaslighing practice from some megacorp. ;) I'll just wait.
I don't see how that url means Google is doing this, when none of us have been able to verify. There could be 100 different things touching your email doing this.
Pretty sure most hn wants this to be true as a reason to sharpen pitchforks.
- 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.
If I click on a link, my browser opens it. Done, right?
https://caniuse.com/referrer-policy
Tbh I'm struggling a little to understand what the threat model is here. You trust gmail to receive and handle your email. In the vast majority of cases, you're accessing the email through their web frontend, where they could easily detect hovers and clicks and log those with fair reliability, if they had nefarious ends in mind. But them using a redirector is a bridge too far? If you trust them to do the first two items, it seems a little far fetched to distrust the last.
Also, there is something very wrong when we're okay with Google rewriting parts of our emails. How long until they decide to start modifying other bits of our emails? Reading the contents of the email is one thing, modifying it from its original is a whole 'nother ball game.
That's not the claim. The claim is that they're rewriting urls you receive. I suppose if the imap claim is true, and you reply, and you quote the redirector url in your reply, and someone clicks that link, they could detect it. That seems a little annoying and presents a slight risk, but it doesn't seem like the type of thing that would be intentionally designed in, even if I model google as completely amoral and short-termist. There just doesn't seem to be much advantage in it.
> And not every gmail user uses the webmail interface either
That's why i said the vast majority of cases, not "all." :)
Maybe get out now rather than waiting for the frog to get cooked.
Ff extension management is terrible which i find unusable in an age where I need extensions to prevent sites from removing usability features like select, copy, and paste.
I'm using brave but I don't fully understand how it's related to chromium and if it's a true fork that they are going to be able to maintain independently. I have many many extensions in brave and an extension manager that let's me toggle them right from a drop down. Any suggestions?
You've already decided that you are not willing to use it over issues you have with it: that choice is fine. Telling others in relevant discussions why you made that choise is, too.
No-one asked you why you chose not to use Firefox in a thread about Gmail. Yet you managed to inject your FUD here nonetheless: Firefox can handle 5+ addons just fine. But now some random passersby might get the impression that Firefox is a burning dumpsterfire based on random negative critiques that aren't even in the right place nor true at all. That helps exactly no-one.
If Snowdens leaks didn't make you leave nothing will.
If I need to send something I actually care about I wouldn't use e-mail in the first place. It's a low-effort type of communication with normal people who don't care about security, so I'm not going to waste time making my end of that line of communication an impenetrable bastion.
Is Google rewriting the links in the message such that if I forward to someone's non-Gmail address, they still bounce through Google?
Or is the client 'rewriting' links dynamically? This same thing happens all over the web. Drop a link in your Medium-hosted blog, and they'll front the link with their own and then redirect.
What's the new, surprising bit here?
0: https://docs.microsoft.com/en-us/microsoft-365/security/offi...
I'm not able to repro at the moment. I manage a few domains in G, I'll keep poking.
Why do links in gmail redirect?
Why does all the SPDY nonsense matter when Google adds huge latency in other ways.
And after Google pay thought it was a good idea to send my phone number out to every online merchant (I now get nonstop spam texts and calls) I've had it with the company.
Google already knows the bodies of emails and can do whatever analytics they please on them. The vast majority of users are also using it via their web client, meaning that Google can put arbitrary JavaScript on the page to record which links are being clicked on. They already have most of the metadata that they could scrape from a rewritten URL, since you're already on their property. It's possible that I'm missing something, but it feels like it's a lot of effort for information that Google already possesses.
When I use, say, thunderbird, Google does not know whether I opened an email, interacted with links on them or downloaded images/external resources in them.
With link-rewriting, when I click on e.g. shopping.example.com/product/1337 and not on shopping.example.com/product/42 in an email, google now knows that "berkes, thunderbird-user is more likely to like product 1337" and can offer that data to advertisers.
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?
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.
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...)
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.
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...
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?
- 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?
It's worth noting that this also happens on the "HTML version" of Gmail.
[1]: https://medium.com/@ohadinho25/googles-gmail-tracks-link-cli...
[2]: https://support.google.com/mail/thread/12875647
[3]: https://www.doi.gov/employees/drupal/links
Advanced Protection is that ultra‐secure mode that requires hardware security keys to login and prevents third‐party apps. Here’s a quote from its advertising copy:
> Protection against malware is built into Google Chrome, but Advanced Protection performs even more stringent checks before each download. It flags, or even blocks you from downloading files that may be harmful.
Sounds an awful lot like what’s going on here. It would explain why nobody’s been able to reproduce it—almost nobody has AP turned on. I imagine the number of people
1) with AP turned on
2) using a third‐party mail client (mail.app)
3) viewing plaintext mails instead of HTML mail where the link rewriting is less obvious
must be close to zero.