Most mature email clients have been through the wringer and are locked down to a reasonably tight subset of HTML. Especially if they have a "load remote resources" button -- you can usually expect that not pressing it will avoid any tracking risk rather than leaving you partially exposed like Evolution does.
> I suggested that maintaining a whitelist of allowed html tags and attributes, and stripping them before passing the email html onto a web browser would be a good defense in depth strategy
Are there any best in class HTML preprocessors that do this well? There are many use cases for displaying email content in e.g. CRM widgets where the underlying networking can’t be controlled. An iframe with a good CSP goes a long way, but as OP notes you want defense in depth!
Evolution lets you default to the plain text version of an email, even if it contains an HTML version [0], so if you have that setting enabled (which I do, and strongly recommend), it should hopefully reduce the impact of this issue.
[0] Edit > Preferences > Mail Preferences > HTML Messages > HTML Mode = Show plain text if present
For that to work, you need to enable the "only show plain" setting, not the "show plaintext if present".
And you'll probably get a lot of empty emails you can't read that way, unless you configure the plaintext plugin to dump the HTML into the reader view.
The good news: even if you think the AI is good-for-nothing, rewriting HTML into legible plaintext is the one thing it can do pretty well. And probably even a 3B model would do well on this task, so you don't need to send the email body off to the cloud to be data-mined.
That's such a silly overkill use of AI. I'm not having my mail server kick off a 100W GPU every time I receive an email just to extract text from a structured document, nor am I having my computer drain my battery the moment I receive an email. Outsourcing the ridiculous power consumption to the cloud as some kind of dataleak-as-a-service is even worse. I'd rather try to parse the HTML with regex.
You could do that, actually. I brought up AI because it could result in slightly cleaner output than just the naive de-tagging, and because you can use it for general purpose text tasks - not just HTML to plaintext but also semantic message labelling/search, suggestion of task items in a to-do list, maybe some other things too.
Oh, but gmail also reveals to tracking services (i.e. virtual deliverability manager from aws ses) that you opened an email even when you disabled loading images.
No reasonable person would ever think that Google preserves their privacy. Perhaps Google preserves it enough so they can sell whatever information they're hiding, but that's about it.
It does, and as usual, Apple catched up a decade later. It was called Google Image Proxy for GMail (or something like that) when it was released, much to the chagrin of email marketers.
Since 2013, marketers haven’t known WHERE their readers are simply from users opening an email in Gmail.
But today, marketers don’t know IF their readers even open an email if users use Apple Mail.
Partial quote from the second article: “The issue is that the single most useful piece of information a sender gets from you[/the proxy] loading the image is that/when you read the email. And this is not mitigated at all by this system [b/c] when you open an email the server will see a request. Mix that with the ubiquitous uniquely-named images … and you get read notifications.”
(I want _neither_ to leak my IP _nor_ to have “Read Receipts” enabled when I get spam or whatever.)
You can literally ask any SMTP MX server if an email address is valid, and it'll tell you yes/no. Emails send to invalid addresses are in general not silently discarded.
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team[…]
Politicians are masters of this tactic of deflection. The nastier, the better they are at it.
Calling it out is the best one can do without getting trapped in a cycle of low-effort premises and high-effort responses.
Although, as usual in HN, the premises come from different accounts, so both are valid. And it probably reveals valid addresses when the image URL is unique for each email.
Definitely happens a lot on HN, but I think that's just the nature of a mix of different opinions. Better IMHO to just treat them as individual arguments and reply accordingly
I'm really not (honestly!) trying to invalidate anyone's point or win any argument - my post is more of a question-in-disguise: the GP post I was replying to concerns message-read tracking; whereas my post invokes the entirely separate matter of external actors being able to determine the validity or existence of a gmail address.
I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
> I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
Analogously, the issue would be out of bounds then, as the issues are distinct, and so a failure mode that discloses the existence of an email account is not a failure you can lay at the feet of any particular provider of email accounts, but is partly an implementation detail of how different email providers respond to emails to nonexistent addresses. That particular failure (disclosure of the existence of an email address) and any potential solution is considered out of the scope of the problem in the thread (disclosure of the opening of an HTML email due to loading tracking pixels).
Obviously if you're reading gmail on the web or in the official phone app, then of course every click is observable.
But you can read gmail in thunderbird or any other email client, and in that case gmail still doesn't know anything more than that your client performed a sync, which it might be doing periodically at all times and so isn't meaningful.
What platform (web, android, ios) did you test on, and how did you test? I used emailprivacytester.com on a few email services and gmail wasn't susceptible to any of the attacks.
I tested it by sending an email using ses and virtual deliverability manager to my gmail account which is configured to not load images automatically. Then I observed how the open is registered in the virtual deliverability manager’s dashboard.
HTML as a mail format is a horrifying mess. What you want is a rich text format for displaying static text and maybe some images and links and stuff. What we got is the entirety of the modern web application development environment stuffed into our mail clients, with maybe 1/100th the attention to standards compliance and bug fixing that real browsers get, and a metric ton of "Oh Wait Not That" workarounds to plug the obvious security gaps inherent in the "run web apps from any attacker who has your email address" metaphor.
This is one of the big reasons why email has pretty much died for casual use. Even in work environments almost everyone uses chat clients these days.
> This is one of the big reasons why email has pretty much died for casual use. Even in work environments almost everyone uses chat clients these days.
I don't see how this follows. Yes, HTML email fucking sucks. But most people are using Gmail, Outlook, Apple Mail, etc, all of which do a pretty good job at handling HTML emails - especially between each other. How do you go from "html emails are bad" to "html emails led to IM replacing email"?
In the 1990s it was common to exchange short, 1-line, emails - or even emails where the entire message fits in the subject line.
…you can still do that on internal email systems; but over the internet any kind of unsolicited short email will probably be dropped by Bayesian filters on the recipient’s side because the information-capacity of a short email is… well, short, making it harder to discern from short spam/attack emails.
Also, email clients are getting heavier and slower: (Classic) Outlook M365/2025/Etc somehow takes a grating 10+ seconds to fully load and warm-up on my brand new machine, while double-clicking an email to open it makes the whole thing awkwardly hang for 2-3 seconds, even when working offline. It’s given me a huge aversion to using email in general, so I’m not going to send a 1-liner via Outlook.
> …you can still do that on internal email systems; but over the internet any kind of unsolicited short email will probably be dropped by Bayesian filters on the recipient’s side because the information-capacity of a short email is… well, short, making it harder to discern from short spam/attack emails.
I do this all the time. I don't think I've ever had a dropped email, because I always get a response.
> Also, email clients are getting heavier and slower: (Classic) Outlook M365/2025/Etc somehow takes a grating 10+ seconds to fully load and warm-up on my brand new machine, while double-clicking an email to open it makes the whole thing awkwardly hang for 2-3 seconds, even when working offline. It’s given me a huge aversion to using email in general, so I’m not going to send a 1-liner via Outlook.
Does your average human really care though?
Also, mobile email clients (Gmail, Apple Mail) load roughly as fast (or faster) than popular IM apps (Whatsapp, Slack, Discord). Discord in particular is a huge resource hog, with very noticeable load times, and semi-advertisement popups that you have to click through. I have not seen any evidence that this diminishes Discord's popularity.
In my personal experience, while the experience you're describing is frustrating, it didn't feel connected. I don't see a connection to prevalence of HTML being a driving factor. Even when I was using pine I'd use irc or aim if available.
For me, it was simply the lack of adoption of messaging options that made email the default tool. Once cell phones came along and people got accustomed to instant quick messaging that was generally ubiquitous, email was out, whether you were using pine, outlook, or something in between.
Why would you subject yourself to that torture? Thunderbird is like LibreOffice is to MS Office, meaning you will have to adapt, but it is still lean for being a contemporary email client.
MS can take my VBA macros from my cold, dead, fingers: the JS-based replacement in New Outlook is incredibly neutered, such as local filesystem access or managing message attachments.
> Even in work environments almost everyone uses chat clients these days.
I'm not sure how this is better though. With chat clients you are completely locked into their ecosystem. Email at least is an open protocol and interoperable.
Not only does my mail usage not generate any outbound network traffic, nor follow any links, but I can also inspect and edit URLs without following them.
This has been true since the beginning of HTML email. It hasn't stopped it from proliferating. It hasn't stopped it from being de-facto mandatory, and has no chance of reversing the course now.
HTML is going to be inseparable part of e-mail for as long as e-mail lives, and yeah, it seems more likely than e-mail will die as a whole rather than get any simpler technically.
At this point we can only get better at filtering the HTML.
Between my network ad blocker and VPN, I’m lucky for an email that is anything beyond formatted text to render properly anymore.
I’ve practically given up on clicking any sort of links from marketing emails as they are full of multiple redirect trackers. Which, is a shame, as these are obviously from companies I care to keep up with and support.
Email will always have its place, but I agree the default email experience we all know shouldn’t default to essentially a viewport.
Mine blocks any external resources unless you choose to download them with a button on the top of the email. Helps lower their ability to track as well, on top of the other precautions.
No kidding. If your org is large enough, you have to communicate with nontechnical people sometimes. Unless you're a Microsoft shop, they probably aren't using your chat platform of choice. Email is still the first stop where I work. Not to mention talking to people _outside_ of my org, which is _most_ communication for me.
I'm pretty sure that the real reason is spam. Nobody is composing e-mail with complex designs to send their colleagues.
I feel like the major problem with almost everything that has a feed these days is the feed. Real state is a finite resource victim of the tragedy of commons: to be visible, you must post, but if others post, you are less visible, so to be even more visible, you post more, which prompts others to post even more, and anyone who doesn't play this game loses.
This happens with all feeds: chronological feeds on Tumblr, e-mail, RSS, etc.
One project I've seen that has tried a novel approach to this was https://fraidyc.at/ Essentially instead of putting all posts in a line, it's an RSS client that just tells you who has posted recently but not what they have posted.
I'm glad that he is raising the flag after the devs failed to take it seriously. Evolution is going to have to do PR damage control soon and talk about how they're changing things to avoid this in the future.
> The sender can look at their DNS logs to see if you’ve read your email, and the IP address of your DNS resolver at that time, which may indicate your location. [..] An attacker could look at the SNI header during the TLS negotiation
I suppose, but AFAIK no one is really doing that. So in that sense it's a "if a tree falls in the forest, but no one is around to hear it"-type issue.
And the response seems reasonable by the way; they set the correct flag. WebkitGTK has a bug and it doesn't work. It's not great, but you can't expect people to fix everything, especially for fairly minor issues like this.
>It's not great, but you can't expect people to fix everything, especially for fairly minor issues like this.
1. It's not a minor issue that a privacy feature doesn't work.
2. OP clearly stated ( https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_... ) that they know the fixes are not trivial, so at the very least they want the application and website to make it clear that the privacy feature doesn't work, so that users are not misled.
You forget about targetted tracking, stalkers, and the very simple reality that this is a certain way to see if people looked at the email.
Handwaving this away because "nobody will do this" is in the same family of issues as "I have nothing to hide" or "what can they really do with my data?"
> you can't expect people to fix everything, especially for fairly minor issues like this.
The feature is called "Load Remote Content". Turning that off should have predictable consequences. The fact that it doesn't do what people would rightly assume it should do is not a "fairly minor issue".
People who blindly accept problems, who accept a lack of concern about privacy, both as a right and as a preference, who handwave away poor behavior aren't helping anyone. Tech companies rarely DTRT on their own, so people need to hold their feet to the fire. Those companies don't need apologists.
Privacy feature that doesn't work is (arguably) worse than no privacy feature at all.
HTML mails continue to be a mistake
If I can't read/reply with mutt, it isn't worth reading/replying to.
The linked WebKit bug report seems to have some activity from today, so I'm hopeful this will be fixed at the source: https://bugs.webkit.org/show_bug.cgi?id=259787
Does thunderbird protect against this tracking vector?
Most mature email clients have been through the wringer and are locked down to a reasonably tight subset of HTML. Especially if they have a "load remote resources" button -- you can usually expect that not pressing it will avoid any tracking risk rather than leaving you partially exposed like Evolution does.
Yes
> I suggested that maintaining a whitelist of allowed html tags and attributes, and stripping them before passing the email html onto a web browser would be a good defense in depth strategy
Are there any best in class HTML preprocessors that do this well? There are many use cases for displaying email content in e.g. CRM widgets where the underlying networking can’t be controlled. An iframe with a good CSP goes a long way, but as OP notes you want defense in depth!
JSoup / HtmlCleaner
I believe DOMPurify is considered best in class.
Evolution lets you default to the plain text version of an email, even if it contains an HTML version [0], so if you have that setting enabled (which I do, and strongly recommend), it should hopefully reduce the impact of this issue.
[0] Edit > Preferences > Mail Preferences > HTML Messages > HTML Mode = Show plain text if present
That's a load-bearing "if present" there. Companies that want to track you can just send email without plaintext versions and you're still vulnerable.
>can just send email without plaintext
How? Even if they write in HTML only there is nothing which could prevents a email client from just not rendering them which would mean plaintext.
For that to work, you need to enable the "only show plain" setting, not the "show plaintext if present".
And you'll probably get a lot of empty emails you can't read that way, unless you configure the plaintext plugin to dump the HTML into the reader view.
If an E-Mail client does not have such a basic feature you should use a better one e.g. thunderbird/claw
Not at all. You will see the HTML code but not render which is easily readable since HTML is very simple.
The good news: even if you think the AI is good-for-nothing, rewriting HTML into legible plaintext is the one thing it can do pretty well. And probably even a 3B model would do well on this task, so you don't need to send the email body off to the cloud to be data-mined.
That's such a silly overkill use of AI. I'm not having my mail server kick off a 100W GPU every time I receive an email just to extract text from a structured document, nor am I having my computer drain my battery the moment I receive an email. Outsourcing the ridiculous power consumption to the cloud as some kind of dataleak-as-a-service is even worse. I'd rather try to parse the HTML with regex.
Why do we need AI for that? Can’t we just strip html tags?
You could do that, actually. I brought up AI because it could result in slightly cleaner output than just the naive de-tagging, and because you can use it for general purpose text tasks - not just HTML to plaintext but also semantic message labelling/search, suggestion of task items in a to-do list, maybe some other things too.
Can't wait for half of my emails being hallucinated
Oh, but gmail also reveals to tracking services (i.e. virtual deliverability manager from aws ses) that you opened an email even when you disabled loading images.
This is not true, SES uses tracking pixels which are blocked if you disable external images: https://docs.aws.amazon.com/ses/latest/dg/faqs-metrics.html#...
No reasonable person would ever think that Google preserves their privacy. Perhaps Google preserves it enough so they can sell whatever information they're hiding, but that's about it.
I thought Google loaded all content from all external sources upon your seat, so the sender doesn't know whether you opened it or not.
Thinking of Apple?
This was a big announcement with Apple Mail Privacy Protection, included in iOS 15 (Sept. 2021). Sent marketers into a small panic.
If Gmail did so as well, should’ve been bigger news and figure they’d remind us we could disable the load remote content option.
It does, and as usual, Apple catched up a decade later. It was called Google Image Proxy for GMail (or something like that) when it was released, much to the chagrin of email marketers.
One of the earliest (2013) mentions I could find: https://gmail.googleblog.com/2013/12/images-now-showing.html
Found in this old article about the initial launch: https://words.filippo.io/how-the-new-gmail-image-proxy-works...
Thank you. So, important difference!
Since 2013, marketers haven’t known WHERE their readers are simply from users opening an email in Gmail.
But today, marketers don’t know IF their readers even open an email if users use Apple Mail.
Partial quote from the second article: “The issue is that the single most useful piece of information a sender gets from you[/the proxy] loading the image is that/when you read the email. And this is not mitigated at all by this system [b/c] when you open an email the server will see a request. Mix that with the ubiquitous uniquely-named images … and you get read notifications.”
(I want _neither_ to leak my IP _nor_ to have “Read Receipts” enabled when I get spam or whatever.)
That still tells the sender it’s a valid email address though?
You can literally ask any SMTP MX server if an email address is valid, and it'll tell you yes/no. Emails send to invalid addresses are in general not silently discarded.
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team[…]
<https://news.ycombinator.com/item?id=23117242>
Politicians are masters of this tactic of deflection. The nastier, the better they are at it.
Calling it out is the best one can do without getting trapped in a cycle of low-effort premises and high-effort responses.
Although, as usual in HN, the premises come from different accounts, so both are valid. And it probably reveals valid addresses when the image URL is unique for each email.
Definitely happens a lot on HN, but I think that's just the nature of a mix of different opinions. Better IMHO to just treat them as individual arguments and reply accordingly
> moving the goalposts
I'm really not (honestly!) trying to invalidate anyone's point or win any argument - my post is more of a question-in-disguise: the GP post I was replying to concerns message-read tracking; whereas my post invokes the entirely separate matter of external actors being able to determine the validity or existence of a gmail address.
I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
> I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
Analogously, the issue would be out of bounds then, as the issues are distinct, and so a failure mode that discloses the existence of an email account is not a failure you can lay at the feet of any particular provider of email accounts, but is partly an implementation detail of how different email providers respond to emails to nonexistent addresses. That particular failure (disclosure of the existence of an email address) and any potential solution is considered out of the scope of the problem in the thread (disclosure of the opening of an HTML email due to loading tracking pixels).
Erm, last I checked GMail literally reads all your emails to profile you.
Do you know if I’m safe using Apple Mail with the relevant privacy features enabled? (w/Gmail account)
Edit: one marketing site describes a new category of Apple Opens (vs. Human Opens), so sounds like the feature’s effective
Obviously if you're reading gmail on the web or in the official phone app, then of course every click is observable.
But you can read gmail in thunderbird or any other email client, and in that case gmail still doesn't know anything more than that your client performed a sync, which it might be doing periodically at all times and so isn't meaningful.
Source?
Yeah, I wonder too. Just checked the docs, they use tracking pixels. So blocking images should block it 100%?
I tested it myself. You are welcome to do the same.
What platform (web, android, ios) did you test on, and how did you test? I used emailprivacytester.com on a few email services and gmail wasn't susceptible to any of the attacks.
I tested it by sending an email using ses and virtual deliverability manager to my gmail account which is configured to not load images automatically. Then I observed how the open is registered in the virtual deliverability manager’s dashboard.
HTML as a mail format is a horrifying mess. What you want is a rich text format for displaying static text and maybe some images and links and stuff. What we got is the entirety of the modern web application development environment stuffed into our mail clients, with maybe 1/100th the attention to standards compliance and bug fixing that real browsers get, and a metric ton of "Oh Wait Not That" workarounds to plug the obvious security gaps inherent in the "run web apps from any attacker who has your email address" metaphor.
This is one of the big reasons why email has pretty much died for casual use. Even in work environments almost everyone uses chat clients these days.
> This is one of the big reasons why email has pretty much died for casual use. Even in work environments almost everyone uses chat clients these days.
I don't see how this follows. Yes, HTML email fucking sucks. But most people are using Gmail, Outlook, Apple Mail, etc, all of which do a pretty good job at handling HTML emails - especially between each other. How do you go from "html emails are bad" to "html emails led to IM replacing email"?
In the 1990s it was common to exchange short, 1-line, emails - or even emails where the entire message fits in the subject line.
…you can still do that on internal email systems; but over the internet any kind of unsolicited short email will probably be dropped by Bayesian filters on the recipient’s side because the information-capacity of a short email is… well, short, making it harder to discern from short spam/attack emails.
Also, email clients are getting heavier and slower: (Classic) Outlook M365/2025/Etc somehow takes a grating 10+ seconds to fully load and warm-up on my brand new machine, while double-clicking an email to open it makes the whole thing awkwardly hang for 2-3 seconds, even when working offline. It’s given me a huge aversion to using email in general, so I’m not going to send a 1-liner via Outlook.
> …you can still do that on internal email systems; but over the internet any kind of unsolicited short email will probably be dropped by Bayesian filters on the recipient’s side because the information-capacity of a short email is… well, short, making it harder to discern from short spam/attack emails.
I do this all the time. I don't think I've ever had a dropped email, because I always get a response.
> Also, email clients are getting heavier and slower: (Classic) Outlook M365/2025/Etc somehow takes a grating 10+ seconds to fully load and warm-up on my brand new machine, while double-clicking an email to open it makes the whole thing awkwardly hang for 2-3 seconds, even when working offline. It’s given me a huge aversion to using email in general, so I’m not going to send a 1-liner via Outlook.
Does your average human really care though?
Also, mobile email clients (Gmail, Apple Mail) load roughly as fast (or faster) than popular IM apps (Whatsapp, Slack, Discord). Discord in particular is a huge resource hog, with very noticeable load times, and semi-advertisement popups that you have to click through. I have not seen any evidence that this diminishes Discord's popularity.
In my personal experience, while the experience you're describing is frustrating, it didn't feel connected. I don't see a connection to prevalence of HTML being a driving factor. Even when I was using pine I'd use irc or aim if available.
For me, it was simply the lack of adoption of messaging options that made email the default tool. Once cell phones came along and people got accustomed to instant quick messaging that was generally ubiquitous, email was out, whether you were using pine, outlook, or something in between.
> (Classic) Outlook M365/2025/Etc
Why would you subject yourself to that torture? Thunderbird is like LibreOffice is to MS Office, meaning you will have to adapt, but it is still lean for being a contemporary email client.
> Why would you subject yourself to that torture?
MS can take my VBA macros from my cold, dead, fingers: the JS-based replacement in New Outlook is incredibly neutered, such as local filesystem access or managing message attachments.
> Even in work environments almost everyone uses chat clients these days.
I'm not sure how this is better though. With chat clients you are completely locked into their ecosystem. Email at least is an open protocol and interoperable.
There are also some email programs that do not support HTML. I use a email program that does not support HTML.
I do the same.
Not only does my mail usage not generate any outbound network traffic, nor follow any links, but I can also inspect and edit URLs without following them.
This has been true since the beginning of HTML email. It hasn't stopped it from proliferating. It hasn't stopped it from being de-facto mandatory, and has no chance of reversing the course now.
HTML is going to be inseparable part of e-mail for as long as e-mail lives, and yeah, it seems more likely than e-mail will die as a whole rather than get any simpler technically.
At this point we can only get better at filtering the HTML.
Between my network ad blocker and VPN, I’m lucky for an email that is anything beyond formatted text to render properly anymore.
I’ve practically given up on clicking any sort of links from marketing emails as they are full of multiple redirect trackers. Which, is a shame, as these are obviously from companies I care to keep up with and support.
Email will always have its place, but I agree the default email experience we all know shouldn’t default to essentially a viewport.
Mine blocks any external resources unless you choose to download them with a button on the top of the email. Helps lower their ability to track as well, on top of the other precautions.
But yeah, it's pretty horrendous by default.
> Even in work environments almost everyone uses chat clients these days.
Maybe in your bubble, but globally this is just false.
No kidding. If your org is large enough, you have to communicate with nontechnical people sometimes. Unless you're a Microsoft shop, they probably aren't using your chat platform of choice. Email is still the first stop where I work. Not to mention talking to people _outside_ of my org, which is _most_ communication for me.
I'm pretty sure that the real reason is spam. Nobody is composing e-mail with complex designs to send their colleagues.
I feel like the major problem with almost everything that has a feed these days is the feed. Real state is a finite resource victim of the tragedy of commons: to be visible, you must post, but if others post, you are less visible, so to be even more visible, you post more, which prompts others to post even more, and anyone who doesn't play this game loses.
This happens with all feeds: chronological feeds on Tumblr, e-mail, RSS, etc.
One project I've seen that has tried a novel approach to this was https://fraidyc.at/ Essentially instead of putting all posts in a line, it's an RSS client that just tells you who has posted recently but not what they have posted.
> I'm pretty sure that the real reason is spam. Nobody is composing e-mail with complex designs to send their colleagues.
There is a use case of using HTML for transactional emails:
- enhance company branding with design - embed call to action items via hrefs
[dead]
I'm glad that he is raising the flag after the devs failed to take it seriously. Evolution is going to have to do PR damage control soon and talk about how they're changing things to avoid this in the future.
They're called allowlists now
> The sender can look at their DNS logs to see if you’ve read your email, and the IP address of your DNS resolver at that time, which may indicate your location. [..] An attacker could look at the SNI header during the TLS negotiation
I suppose, but AFAIK no one is really doing that. So in that sense it's a "if a tree falls in the forest, but no one is around to hear it"-type issue.
And the response seems reasonable by the way; they set the correct flag. WebkitGTK has a bug and it doesn't work. It's not great, but you can't expect people to fix everything, especially for fairly minor issues like this.
>It's not great, but you can't expect people to fix everything, especially for fairly minor issues like this.
1. It's not a minor issue that a privacy feature doesn't work.
2. OP clearly stated ( https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_... ) that they know the fixes are not trivial, so at the very least they want the application and website to make it clear that the privacy feature doesn't work, so that users are not misled.
Does turning off this option[1] not fix it?
1: https://webkitgtk.org/reference/webkit2gtk/stable/property.S...
You forget about targetted tracking, stalkers, and the very simple reality that this is a certain way to see if people looked at the email.
Handwaving this away because "nobody will do this" is in the same family of issues as "I have nothing to hide" or "what can they really do with my data?"
> you can't expect people to fix everything, especially for fairly minor issues like this.
The feature is called "Load Remote Content". Turning that off should have predictable consequences. The fact that it doesn't do what people would rightly assume it should do is not a "fairly minor issue".
People who blindly accept problems, who accept a lack of concern about privacy, both as a right and as a preference, who handwave away poor behavior aren't helping anyone. Tech companies rarely DTRT on their own, so people need to hold their feet to the fire. Those companies don't need apologists.
Anyone know if they have a disclaimer on the Load Remote Content toggle?
(Seems reasonable to link to the bug report or something, but this is not my domain.)