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.
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.
>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.
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.
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.
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.
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.).
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.
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.
>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.
This website was pretty nasty to my browser history and pretty much kidnapped my tab on mobile safari.
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.
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.
Would a hard isolation model for HTML email be a better long-term solution, or is that impractical for reasons I’m missing?
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.
> 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.
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.
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.).
There's no reason to require JavaScript to render rich text especially when it's an article about CSS prowess.
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.
> In this section I targeted Fastmail, ProtonMail, Gmail, Cowork and Slack.
Oh that's all, is it?