Rendered at 13:56:09 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
PoignardAzur 1 days ago [-]
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.
purplemoonx 22 hours ago [-]
Lol, should we go back to browsing "With Frames" or "Without Frames"
throw1234567891 19 hours ago [-]
I have my frame buster buster buster buster ready.
esprehn 24 hours ago [-]
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.
Waterluvian 1 days ago [-]
This website was pretty nasty to my browser history and pretty much kidnapped my tab on mobile safari.
albinowax_ 22 hours ago [-]
That is not good, I’ll get it fixed. Thanks for flagging.
JacobKfromIRC 10 hours ago [-]
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.
Wistar 22 hours ago [-]
Yes, it breaks the back button on iPad/Safari
dabinat 20 hours ago [-]
Email rendering is such a mess. It’s insane that the standard way to lay out an HTML email in 2026 is with tables.
It seems like browsers moved with the times and email got stuck in 2005.
Bender 1 days ago [-]
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.
cassepipe 20 hours ago [-]
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
1718627440 4 hours ago [-]
> 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.
cassepipe 2 hours ago [-]
Isn't hosting your own email server different from using a "free email provider"?
graemep 22 hours ago [-]
Email clients have a much better UI too.
ksbd-pls-finish 1 days ago [-]
>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.
Haven't tried it yet though, done some reading but don't know enough to be sure their proposed paradigm is valid.
desro 1 days ago [-]
Allowing anything other than plain text in email bodies was a terrible mistake.
upofadown 24 hours ago [-]
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.
Arnt 23 hours ago [-]
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.
1718627440 4 hours ago [-]
MUAs do render italics/bold, headlines, citations, etc. , so for just bold and italic HTML isn't required.
chuckadams 22 hours ago [-]
It was allowed before HTML even existed: MIME was invented for email.
ranger_danger 21 hours ago [-]
> 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.
Ecommerce loves html in email, it would be interesting seeing them reverting to plain text but the backlash would be too great
ashurandi 1 days ago [-]
Would a hard isolation model for HTML email be a better long-term solution, or is that impractical for reasons I’m missing?
holydementor 22 hours ago [-]
[flagged]
pluc 1 days ago [-]
> This page requires JavaScript for an enhanced user experience.
Yeah no shit.
thunderbong 1 days ago [-]
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.
graemep 22 hours ago [-]
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).
appplication 1 days ago [-]
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.
wasmperson 20 hours ago [-]
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).
1718627440 4 hours ago [-]
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.
pluc 1 days ago [-]
There's no reason to require JavaScript to render rich text especially when it's an article about CSS prowess.
semolino 24 hours ago [-]
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.).
true_religion 22 hours ago [-]
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.
1718627440 4 hours ago [-]
> 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.
true_religion 3 hours ago [-]
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.
ksbd-pls-finish 1 days ago [-]
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.
GoblinSlayer 22 hours ago [-]
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".
javascripthater 1 days ago [-]
[flagged]
tomhow 8 hours ago [-]
We've banned this account.
fragmede 1 days ago [-]
> In this section I targeted Fastmail, ProtonMail, Gmail, Cowork and Slack.
Oh that's all, is it?
nickcw 21 hours ago [-]
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.
> 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.
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.
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
How so? I host my own stuff, and I never had much problems.
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.
Haven't tried it yet though, done some reading but don't know enough to be sure their proposed paradigm is valid.
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.
This is actively harmful advice that could easily get someone fired.
Yeah no shit.
But when most of the articles submitted here don't work without JavaScript, this comment seems really irrelevant.
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.
- 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).
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.
Because that doesn't include writing JS, that's a separate step.
Presumably this is easier than a non js solution or they couldn’t find one.
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.
Oh that's all, is it?
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