Reading the article, I kept thinking: "could you defeat this with an iframe?", and indeed:
> One of the best methods to protect against these attacks is strict isolation. If you isolate the email message using sandboxed iframes you restrict the ability to break out of trusted boundaries. If you are not using sandboxed iframes, always be careful when allowing custom attributes and check for HTML/CSS gadgets. Use a strict allow list of characters when validating keywords and names to avoid mutation when using the CSSOM.
iframes should be the first layer of any defense-in-depth against user-submitted content.
The frustration with the Gmail triager is typical unfortunately. Google teams have outsourced almost all user issue triage to contractors and the actual engineers don't interact with the community or users. Hopefully some Googler sees this and can get the Gmail team to fix it. The image proxy is useless if emails can trivially work around it.
Can you elaborate? What happened to your browser history? It seems odd that browsers would even let websites cause problems like this but maybe I'm misunderstanding because I'm not sure what the problems are.
I view email in Thunderbird and have uBlock installed. Sadly the CSS Exfil addon for Firefox does not exist for Thunderbird but I view emails in plain text either way. I suppose I "miss out" on backgrounds, themes, animated GIFs. For me personally plain text is the way to go. Am I the only one using an email client these days? I prefer the client so I can keep my emails off the server and manage my own backups.
Using a email a free email provider with Thunderbird is a pain nowadays
You can get away with not giving your phone only with google and outlook but you will need recovery addresses. For those I am using proton mail, they don't require anything and for those I have the recovery key saved somewhere.
Also you will get error messages in thunderbird from outlook that it doesn't work... but it does work !
I did all that in anger but if I had to do it again I would just use one of those super cheap provider where you pay 1$ a month or even by usage and use TB with that.
Hey mail, fastmail, they all look great but I don't even pay that much to my bank or any other services so no way I am spending 5 euros or more a month for email
>When the user types this command Atlas will open some browser tabs and exfiltrate the victim's name from the current web page and send it to a remote server via the hash.
But the remote server doesn't see the hash? This casts doubt into the content, since the attack was clearly not tested. Am I missing something?
It's a pretty interesting post though, but hardly surprising - touching and rendering untrusted content is always risky.
It was never allowed. Microsoft just started doing it in their email client and obnoxiously made it default. There was no standards process where anyone spent time considering the potential downsides with the aim of making HTML email practical and secure.
HTML email is just something that people semi-randomly do. It should be rejected/ignored if you are at all concerned about privacy and/or security.
There was one, in the IETF. It went like this: "We should have a HTML profile, somewhat restricted, so that the people who want to send bold and italic and a little more can do that, and composers can know what's okay, and javascript isn't" and a little discussion, and then came people shouting "EVERYTHING EXCEPT TEXT/PLAIN IS THE DEVIL'S WORK!" and the whole thing dissolved due to the noise.
Not sure what you're saying — do you have an actual production MUA with text/enriched support, or is it something else? Send me an example of whatever it is, please. Something with boldface but without HTML.
Just regular Thunderbird rendering some common elements in plaintext mails. Just like e.g. Markdown is rendered on Github. This is what Markdown comes from after all.
Most articles submitted here do work without JS in my experience, including this one. I just tried the current top five articles and all work, except that github does not load everything (the main text does load, the commit message and time for each file or directory does not).
I do not understand the anti-JavaScript folks here. This is a forum that celebrates all sorts of automation, but now when a website wants to run automations that is agitating?
I guess my question would be why does something so benign and common aggravate you so much? That feels like an exhausting way to live.
There are several reasons someone might prefer to use websites that work without JS:
- The page will load noticeably faster (and likely be faster in a number of other ways).
- The semantics are more predictable (buttons, links, scrolling, text selection, find-in-page, etc. all behave the same as on other websites).
- The page will work in Tor Browser's "maximum security" setting.
- The page is more likely to work better in screen readers or with other less-commonly used web browsing tools.
- The page is more likely to work in older browser versions.
- It used to be that a JS-free page had lighter CPU usage, though newer CSS features and browser setTimeout/setInterval throttling have changed the balance somewhat.
- The page does not require running untrusted/proprietary code on your computer (the browser sandbox is a small comfort).
Most webpages that function as simple documents can be built without JS. If you build webpages, you probably have an intuition for what kind of functionality necessitates JS. When a webpage requires that users enable JS, then, when it doesn't seem like it should need it, that's a signal of either developer laziness or nefarious behind-the-scenes activity (tracking, etc.).
After writing a long article, creating videos, images, and no doubt doing multiple rounds of edits... why should an author also have to ensure that their publication works without JS?
From what I can see, they're doing so codeblocks have proper highlighting but also can be copied & pasted. It's a reasonable choice.
They're not lazy. They even have long, accurate alt tag descriptions for all their images.
If I would guess, they have an inherent desire to see their work viewed in exactly the way it was intended, so they deliberately refuse progressive enhancement when it's a matter of reader choice. The visually impaired who have no choice are accommodated. Anti-JS readers are not.
The Web is a document format, it does not need a client side turing complete language. Granted, now-a-days people also use it to ship applications, and I have nothing against using JS for that, but for a document it is really dumb to require code execution in order to just view the document.
Reading the article, I kept thinking: "could you defeat this with an iframe?", and indeed:
> One of the best methods to protect against these attacks is strict isolation. If you isolate the email message using sandboxed iframes you restrict the ability to break out of trusted boundaries. If you are not using sandboxed iframes, always be careful when allowing custom attributes and check for HTML/CSS gadgets. Use a strict allow list of characters when validating keywords and names to avoid mutation when using the CSSOM.
iframes should be the first layer of any defense-in-depth against user-submitted content.
Lol, should we go back to browsing "With Frames" or "Without Frames"
I have my frame buster buster buster buster ready.
The frustration with the Gmail triager is typical unfortunately. Google teams have outsourced almost all user issue triage to contractors and the actual engineers don't interact with the community or users. Hopefully some Googler sees this and can get the Gmail team to fix it. The image proxy is useless if emails can trivially work around it.
This website was pretty nasty to my browser history and pretty much kidnapped my tab on mobile safari.
That is not good, I’ll get it fixed. Thanks for flagging.
Fixed now! Thanks again.
Thanks for fixing it! Confirmed working for me.
Can you elaborate? What happened to your browser history? It seems odd that browsers would even let websites cause problems like this but maybe I'm misunderstanding because I'm not sure what the problems are.
Yes, it breaks the back button on iPad/Safari
Email rendering is such a mess. It’s insane that the standard way to lay out an HTML email in 2026 is with tables.
If you look at https://www.caniemail.com/scoreboard/ there are even different results for the same client on desktop vs mobile.
It seems like browsers moved with the times and email got stuck in 2005.
I view email in Thunderbird and have uBlock installed. Sadly the CSS Exfil addon for Firefox does not exist for Thunderbird but I view emails in plain text either way. I suppose I "miss out" on backgrounds, themes, animated GIFs. For me personally plain text is the way to go. Am I the only one using an email client these days? I prefer the client so I can keep my emails off the server and manage my own backups.
Using a email a free email provider with Thunderbird is a pain nowadays
You can get away with not giving your phone only with google and outlook but you will need recovery addresses. For those I am using proton mail, they don't require anything and for those I have the recovery key saved somewhere.
Also you will get error messages in thunderbird from outlook that it doesn't work... but it does work !
I did all that in anger but if I had to do it again I would just use one of those super cheap provider where you pay 1$ a month or even by usage and use TB with that.
Hey mail, fastmail, they all look great but I don't even pay that much to my bank or any other services so no way I am spending 5 euros or more a month for email
> Using a email a free email provider with Thunderbird is a pain nowadays
How so? I host my own stuff, and I never had much problems.
Isn't hosting your own email server different from using a "free email provider"?
Email clients have a much better UI too.
>When the user types this command Atlas will open some browser tabs and exfiltrate the victim's name from the current web page and send it to a remote server via the hash.
But the remote server doesn't see the hash? This casts doubt into the content, since the attack was clearly not tested. Am I missing something?
It's a pretty interesting post though, but hardly surprising - touching and rendering untrusted content is always risky.
One thing I've found that purports to address (some of) these risks: https://mail.cock.li/cock-mail/
Haven't tried it yet though, done some reading but don't know enough to be sure their proposed paradigm is valid.
Allowing anything other than plain text in email bodies was a terrible mistake.
It was never allowed. Microsoft just started doing it in their email client and obnoxiously made it default. There was no standards process where anyone spent time considering the potential downsides with the aim of making HTML email practical and secure.
HTML email is just something that people semi-randomly do. It should be rejected/ignored if you are at all concerned about privacy and/or security.
There was one, in the IETF. It went like this: "We should have a HTML profile, somewhat restricted, so that the people who want to send bold and italic and a little more can do that, and composers can know what's okay, and javascript isn't" and a little discussion, and then came people shouting "EVERYTHING EXCEPT TEXT/PLAIN IS THE DEVIL'S WORK!" and the whole thing dissolved due to the noise.
MUAs do render italics/bold, headlines, citations, etc. , so for just bold and italic HTML isn't required.
Not sure what you're saying — do you have an actual production MUA with text/enriched support, or is it something else? Send me an example of whatever it is, please. Something with boldface but without HTML.
arnt@gulbrandsen.priv.no.
Just regular Thunderbird rendering some common elements in plaintext mails. Just like e.g. Markdown is rendered on Github. This is what Markdown comes from after all.
It was allowed before HTML even existed: MIME was invented for email.
> It should be rejected/ignored if you are at all concerned about privacy and/or security.
This is actively harmful advice that could easily get someone fired.
Feel free to use https though, it's a self-signed cert. http://athena.m3047.net/pub/fwm/rfc-tree.pdf
Ecommerce loves html in email, it would be interesting seeing them reverting to plain text but the backlash would be too great
Would a hard isolation model for HTML email be a better long-term solution, or is that impractical for reasons I’m missing?
[flagged]
> This page requires JavaScript for an enhanced user experience.
Yeah no shit.
You're certainly welcome to browse the internet without JavaScript.
But when most of the articles submitted here don't work without JavaScript, this comment seems really irrelevant.
Most articles submitted here do work without JS in my experience, including this one. I just tried the current top five articles and all work, except that github does not load everything (the main text does load, the commit message and time for each file or directory does not).
I do not understand the anti-JavaScript folks here. This is a forum that celebrates all sorts of automation, but now when a website wants to run automations that is agitating?
I guess my question would be why does something so benign and common aggravate you so much? That feels like an exhausting way to live.
There are several reasons someone might prefer to use websites that work without JS:
- The page will load noticeably faster (and likely be faster in a number of other ways).
- The semantics are more predictable (buttons, links, scrolling, text selection, find-in-page, etc. all behave the same as on other websites).
- The page will work in Tor Browser's "maximum security" setting.
- The page is more likely to work better in screen readers or with other less-commonly used web browsing tools.
- The page is more likely to work in older browser versions.
- It used to be that a JS-free page had lighter CPU usage, though newer CSS features and browser setTimeout/setInterval throttling have changed the balance somewhat.
- The page does not require running untrusted/proprietary code on your computer (the browser sandbox is a small comfort).
There's no reason to require JavaScript to render rich text especially when it's an article about CSS prowess.
Most webpages that function as simple documents can be built without JS. If you build webpages, you probably have an intuition for what kind of functionality necessitates JS. When a webpage requires that users enable JS, then, when it doesn't seem like it should need it, that's a signal of either developer laziness or nefarious behind-the-scenes activity (tracking, etc.).
After writing a long article, creating videos, images, and no doubt doing multiple rounds of edits... why should an author also have to ensure that their publication works without JS?
From what I can see, they're doing so codeblocks have proper highlighting but also can be copied & pasted. It's a reasonable choice.
They're not lazy. They even have long, accurate alt tag descriptions for all their images.
If I would guess, they have an inherent desire to see their work viewed in exactly the way it was intended, so they deliberately refuse progressive enhancement when it's a matter of reader choice. The visually impaired who have no choice are accommodated. Anti-JS readers are not.
> After writing a long article, creating videos, images, and no doubt doing multiple rounds of edits...
Because that doesn't include writing JS, that's a separate step.
They’re using a plugin to get the effect they want and for analytics.
Presumably this is easier than a non js solution or they couldn’t find one.
I dislike JS, because I don't want to let random websites to run arbitrary code on my machine.
Most importantly, enabling JS makes it much easier to spy on users, so I automatically assume that the website tries to spy on my and feel attacked.
I agree it's not healthy, and I didn't care about privacy that much in the past. I guess this may be caused by my work experience.
The Web is a document format, it does not need a client side turing complete language. Granted, now-a-days people also use it to ship applications, and I have nothing against using JS for that, but for a document it is really dumb to require code execution in order to just view the document.
JavaScript is an RCE vulnerability. Browsers literally execute it as "run this malicious code in a vm, then nuke the whole thing from the orbit".
[flagged]
We've banned this account.
> In this section I targeted Fastmail, ProtonMail, Gmail, Cowork and Slack.
Oh that's all, is it?
Here is an idea...
Why don't we give up on HTML in emails and just use markdown instead? It is readable and writable by humans and doesn't have insane security problems.
It seems to be our AI overlords' preferred communication format too so it would future proof email for the aipocalypse.
This would, alas, make the the people sending you marketing emails very unhappy. Maybe they could attach a PDF instead, I'm sure that would be safe.
/s