hckrnws

I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so.

Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.

I worked for a short time for an American company. They had periodic phishing test from Mitnick. The links in those emails was not to be clicked as it would trigger a mandatory training. The emails also had a header saying they were a phishing test, so I deleted all those emails in a filter.

The company also ran a mail filter called Baracuda or something similar that followed links in emails to see if they were malicious.

I was quite annoyed when I was called to do the mandatory training as "I" had clicked a link (on an email I hadn't seen) and more so when told I had no other recourse than to sit through it.

I resigned shortly afterwards.

Did everyone get flagged then thanks to Barracuda? You’d think they’d realize there’s a problem if there’s a 100% fail rate.

Edit: also, to be fair, you basically told them you had opted out of the test, so it’s not completely ridiculous for them to ask you to do the training instead.

to be fair someone started using computers and has x worthelss security certificates but yes he will teach me how to use computer/Internet...okidoki... I just move to trash all their tests as it's just spam.

The test is whether you can successfully identify phishing attempts bu approximating what they look like in the wild. Bypassing the test entirely means there's no data on whether you're susceptible to this, and just because someone knows there's a header and how to bypass something doesn't mean they aren't also the kind of person to be distracted and click on stuff they shouldn't.

This method of test passing wasn't okay when Volkswagen did it, and it's not appropriate for employees at a company that asks them to take the test, for the exact same reason.

There’d be a bigger problem for the security training folks if there was a 100% pass rate.

Those knowb4me or whatever supposed security lessons are terrible. In our case the emails included links to external domains (to knowb4) that you were actually required to click, as in really not as a test to see who did it. And you presume to teach me Fing security...

Hmm, mixed feelings.

Sure you are being clever, but (and I don't know the state of art science wrt effectivity of these fake phishing emails), you are defying a measure that was taken by management to try to make the company safer. Sure it may feel, and even be, a waste of time. But you are also putting yourself above the rules in a way. Your assumption is that these programs will actually NOT make the company safer, with 100% certainty. Because even of it makes the company 1% safer, it is management's responsibility to go ahead with these measures or not.

I don't know what to think of how you acted, as much as I hate most mandatory course, at least some if my knowledge comes from them. Obviously the company pays you normally while you take the course. And somewhere I feel that "work is work".

Of course, in this case, you have shown the system to be erroneous, while showing yourself to feel superior. Difficult... As manager I'd like you to seek a conversation with me.

Edit: Of course, you are 100% free to leave this company, are you 100% free to cheat on cyber security measures? I don't think I agree with you there.

As said, mixed feelings.

> you are defying a measure that was taken by management to try to make the company safer.

> are you 100% free to cheat on cyber security measures?

Why do you think that implementing an email filter like that is "defying a measure" or "cheating"? What value do you think there would be in individually, manually, reviewing each such email, if you've already identified the pattern they all follow and their purpose? You're essentially arguing for wilful inefficiency, which is "cheating" the organization out of useful labor.

The other reply to you may have been less than perfectly polite, but they certainly had a point.

Come on, certainly the "spirit" of the "training" is to learn to disseminate phishing emails from real ones using subtle ques. Not to learn how to write an email filter.

Nowhere am I saying that I agree with the chosen methods, especially not the part that sounds like punishment. But there are better ways to deal with the disagreement than suggested here.

This could go straight on r/LinkedInLunatics, the PMC is insane

Hmm, never been there, but it never feels good to be lumped in with some group (especially when they have lunatics in the name) instead of receiving feedback that may point at errors in judgement.

I'm generally considered knowledgeable and I'm just thinking from the perspective of owning a company and employees taking these actions instead of coming to talk to me, showing evidence of my poor management decisions.

This whole text reeks of a employee vs employer situation, which is never good (you're in it together), so probably it is good that the person left the company, for both parties.

Perhaps I'm naive, or not American enough, US work culture seems harsh to me sometimes, especially wrt work ethic and hierarchy.

I'm off now to find what PMC is, thank you.

Edit: Looked around for sometime, no idea still what PMC is.

Professional-Managerial Class, as opposed to working class or proletariat.

Thanx, I don't consider myself PMC, but, I guess that's the internet of today, slap a label onto anyone and anything based on ~160 chars.

I guess lyu07282 is what I have taken to calling a "Judger". Always labeling, always judging, always seeking the moral high-ground, never realizing the lack of nuance that must exist in short texts. Never thinking "what if this was meant in a kind way." Oh, and I see the irony, it is intentional (feels bad right?).

I think it's what tearing the US apart at this very moment. Always Us against Them. Most people are kind you know. I really thought I did my best to add nuance.

Some of the big providers already do this, notably Apple and Gmail:

https://www.litmus.com/blog/gmail-prefetching-images

Gmails prefetch is terrible for privacy because it honors http cache headers, which means tracking companies simply use a "no-cache, must-revalidate" header to defeat it.

Which is completely stupid since images in an email should never change.

Why shouldn't they? There's plenty of scenarios where you might want to swap images after a period of time has elapsed, or to fix a mistake.

The ability to swap images but not text seems arbitrary.

You could imagine a system more like the notification tray on iOS/Android where at any time a notification can appear, be edited, timeout, or be deleted.

Your email inbox could be like that. The email saying "Your parcel has been dispatched" could be edited to say "Your parcel has been delivered".

When you refund something you've bought, the original purchase receipt could be crossed out or hidden. When you get invited to a wedding but then the wedding is cancelled, the original invite could be deleted, etc.

It's counter to the principle of what e-mail is. It's supposed to be static. Just because you can doesn't mean you should.

> It's supposed to be static.

Says who? It's not in the original RFC as far as I'm aware.

I'm pretty sure the original RFC (RFC 821) does not include remote resources and it was written far before HTML or HTTP was invented.

It was text delivered over SMTP.

specifically to prevent this kind of tracking

I know of an invoicing system that updates the image when it's paid. Seems pretty useful to me.

And yes, that means that an image with an amount is publicly accessible, so what, there's no information about the invoice in there as that's in the text of the email.

Bet they send a separate mail when you paid though, in which case updating the picture is not much more than a means for them to hide errors.

I subscribed to the daily headlines from a newspaper, they delivered them as a remote picture in the mail. Only it was always the same remote picture each day, just updated. So if you didn't open the mail each day too bad: you snooze you loose, those past headlines are gone.

That sounds like a feature, not a bug, given where Google’s revenue comes from.

Google's revenue comes from Google's ads, not other people's ads, and they already know when you open your emails. They should block remote loading, to ensure their ad platform works better than other people's.

I think the problem is what is an image?

I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.

I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.

What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.

Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...

[1]: https://github.com/geocar/firewall.js

[2]: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...

Why on earth does the HTML sanitiser allow blacklisting?! That can't ever be safe to use, the set of HTML elements can always change.

Note that the API is split into XSS-safe and XSS-unsafe calls. The XSS-safe calls [0] have this noted for each of them (emphasis mine):

> Then drop any elements and attributes that are not allowed by the sanitizer configuration, and any that are considered XSS-unsafe (even if allowed by the configuration)

The XSS-unsafe functions are all named "unsafe". Although considering web programmers, maybe they should have been named "UnsafeDoNotUseOrYouWillBeFired".

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...

I mean, at least they eventually came to their senses, but it does not inspire confidence!

https://developer.chrome.com/blog/sanitizer-api-deprecation/

That's the old sanitizer API. That was already removed and what you linked earlier is the new sanitizer API.

> What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data

multipart/related already exists.

> multipart/related already exists.

Which web browsers render multipart/related correctly served over https?

What is stopping them from doing so instead of going with a NIH solution?

Never mind the context is e-mail, which is not served to a browser over HTTPS.

Got it: So none.

As to why I prefer one thing that doesn’t exist over another thing that doesn’t exist depends on my priors. You might as well be asking my opinion and making fun of it before you know the answer.

What do you think the impact would be if Content-Location: would be if it suddenly gained the interpretation I suggest?

What do you think a script in the package can do to reference a part of the URL is constructed by code?

I knew the people who were setting this up for Yahoo like 10 years ago. Lots of major providers do it now.

I think this is what icloud does. Seems like an easy way to make tracking useless if every client did it.

That still provides “human” vs “bot” feedback to the sender.

An automated system processing emails isn’t going to be fetching images or rendering attached SVGs.

I think I might be misunderstanding. Why wouldn’t it? It’s not like the human is manually decoding the SVG or getting the PNG.

I mean I don't think that's exactly true in the age of LLMs.

That is still signal that the email address is valid. I'd prefer something like the server immediately sending a SMTP 550 5.1.1 (unknown recipient error), for anything that's immediately recognized as spam (or marked as spam in the past by the user). That gives no signal at all and might even persuade some scammers to remove your email address from their list.

If you don’t follow spam links, then it lets the spammer probe your spam filter, and try stuff until you follow links.

A better approach is to follow all links always (even to non-existent recipients) if you must play this game.

That reminds me: I should make sure all my mail clients are still set to plain text rendering.

I hereby remind you of a bet you lost: https://news.ycombinator.com/item?id=39186555 :)

my contact info is in my profile to arrange settlement

That's not enough. As the article explains, SVGs can reference external resources. So you also need to prefetch those external resources, recursively, if you want to be thorough.

To add to this, those external resources aren't limited to images, they can be basically anything, foreignObject allows video.

I'm also wondering if you could (ab)use SMIL mouse events to bypass this approach.

From reading a little bit of the code it sounds like Roundcube's sanitizer is much closer to a blacklist than a whitelist. Any attempt to sanitize HTML with a blacklist is doomed to failure. Even if you read the current HTML spec (including referenced specs like SVG) and do a perfect job there are additions over time that you will be vulnerable to.

Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.

SVGs are just the tip of the iceberg of how hard it is to sanitize email content. There aren't any purpose-built good libraries for email sanitization either. Something that would handle SVG, CSS, HTML, everything.

Put it in an iframe with a Content-Security-Policy header?

Some providers do that.

But you still have to dynamically allow or disallow external content such as images. It also makes any operations based on the content more convoluted. Like adding event invites to calendar and so on.

I have added a test for this to https://www.emailprivacytester.com

This is why SVG isn't supported well for email clients.

https://www.caniemail.com/features/html-svg/

Slightly related, but fraudsters love using .svg attachments, typically the mails purport to be for an invoice which you need to log into your Microsoft account to be able to “securely” view.

I’m not sure if Exchange Online doesn’t scan them or something, but I landed up making a rule which blocks all emails with either .svg or .htm(l) attachments and to notify me when blocked.

Happens a couple of times per month for the our small company, no false positives yet.

I know someone who embeds an SVG of his signature in their emails. Looks pretty cool, renders inline, and it's sad that the state of things means they'll probably have to remove it because it triggers spam filters.

I don't block embedded SVGs, just ones included as attachments, so I don't think it would affect your friend's use case.

Hmm, I wonder, if roundcube was the exception (w.r.t feImage), or if soon other webmail clients will need to be patched

Author here! I have looked at Thunderbird. I'll go and look at some others as well, should have probably done that earlier.

I wouldn't vouch 100% for my PHP understanding but it looks like SnappyMail removes `<svg>` elements entirely (`BuildHtml` in `snappymail/v/2.38.2/app/libraries/MailSo/Base/HtmlUtils.php`)

Too bad CORS doesn't fix this. It would be awesome to be able to sandbox a page completely.

You can use CSP for this:

    Content-Security-Policy: img-src 'self';

Nice catch!

I am trying to read as less _online_ as possible nowadays. I essentially have dovecot in my crontab, and read it off roundcube. It's been working great, RoundCube is dead simple to setup and use, the UI and search are very fast.

You disclosed this the day roundcube was patched. Isn’t it usual to give us time to deploy updates before disclosing details?!

The patch disclosed details pretty clearly already.

https://github.com/roundcube/roundcubemail/commit/26d7677

You give the developer time to develop a patch. Once the patch is out, attackers can already deduce the vulnerability by looking at what changed and at that point you either want to immediately install the patch or you want to know what the vulnerability actually is so you can do something to mitigate it if there is some reason you can't immediately install the patch.

I wondered what obscure part of the SVG spec included fel mages for a minute, damn sans serif.

Not disputing the article, nor insinuating that there's some ulterior motive, but it's curious that this blog has only one post; and the About page suggests a lengthier history (with references to what would have been previous posts).

Author here! Are you referring to the "What’s inside this vendor’s VMware images?" on the about page? That is merely an illustration of what goes on inside my head. This is the first article on my blog.

Yes, those were the suggestions which made me think there was a disparity between the About and the posts (or lack thereof).

Best of luck to you on your blog. I would suggest you also add a "welcome to my blog" post where you give a little background about why you're writing the blog and what kinds of content readers can hope to see in the future. There's no denying that you have little content, so you might as well make it clear to readers _why_ that is. Plus, it sets them up to be interested to see what's coming next.

Good suggestion! Thanks. I'll go write up a welcome post soon :)

SVGs are such an amazing attack vector. Nearly every webapp I've seen that allows image or SVG uploads is vulnerable to XSS. If the Roundcube implementation allows for remote image fetching, it's probably worth checking it for XSS vulnerabilities.

Also: what's the legal status of this kind of tracking? How does it jibe with the GDPR?

whatever happened to read receipts? I wouldn't mind allowing a sender who wants to know if I've opened their email, access to a read receipt about it.

They still exist. Surprisingly, most folks aren't interested in letting every newsletter and promotion know that they were seen. So a surveillance arms race ensues instead.