[9dev]

Nobody wanted to buy them because the pricing was just ridiculous. I’m sure as hell not dropping 1.5 grand per year to display a freaking logo next to our mails. Had they been less greedy, this could have actually worked. But the way it is, it’s just a money grab from the same guys that used to sell you overpriced SSL certificates.

> (BIMI is still a tracking pixel in every mail, BTW.)

It doesn’t have to be. Email platforms and clients should have servers in place to fetch logo images and cache them for their users; no direct correlation between users and requests in that case.

[netsharc]

To abuse the email system even more, wouldn't it be possible to add a header to the email with a base64 encoded image? I suppose with HiDPI, the image might need to have quite a high resolution. And then someone will find an exploit involving image decoding/displaying.. like one Outlook had years ago while parsing manipulated timestamps.

Edit: reading one example, the hosted image can be an SVG, so that would not be so heavy to be embedded into the header..

[teddyh]

Such standards exist already:

1. The ancient “X-Face” header: 48×48 black or white pixels: <https://en.wikipedia.org/w/index.php?title=X-Face&oldid=1220...>

2. The “Face” header, from 2005: 48×48 PNG image <https://quimby.gnus.org/circus/face/>

[teddyh]

> Email platforms and clients should have servers in place to fetch logo images and cache them for their users; no direct correlation between users and requests in that case.

So, all email servers and clients should be rewritten to avoid user tracking. Got it.

This will never happen. If it came even close to happening, BIMI would magically and coincidentally grow a new user-tracking feature.

[9dev]

Coming to think of it… How would you implement user tracking with an image that must be served from a static URL defined in a DNS record and no request parameters to go by? Other than applying heuristics to match the time frame between sending a mail and receiving a request for the logo endpoint, I don't see how that would even work.

Additionally, platform providers have a huge incentive to cache the logos on their end—otherwise, they'd be required to verify the cryptographic signature every single time the logo were required to be drawn on the screen.

[tssva]

Some email platforms already cache images to prevent tracking.

[teddyh]

Let me guess: Those platforms just happen to be web-based, so the platform owners can track users there anyway?

[tssva]

Any email provider can track you pretty successfully whether web based or using another protocol such as IMAP. Most email is at best protected by encryption only while in transit after all. For personal email you get to choose your email provider and whether you are ok with them tracking you or trust them not to track you.

But an example of a non web based email client which provides privacy protections regarding images in email is Apple Mail and its mail privacy protection features.

[teddyh]

And Apple Mail displays BIMI images? Does it cache them?

[tssva]

Whether Apple Mail supports BIMI is not really relevant since my original comment was regarding email.platforms supporting caching of images and not BIMI specific. If an email client supoorts caching of images extending that to also include BIMI logos while adding BIMI support is minimal effort.

That being said Apple Mail has supported showing BIMI logos since iOS 16 and macOS Ventura. Do they use caching for doing so when mail privacy protection is enabled as they do for other images? I have not specifically done an in depth dive to determine but what exactly would the motivation be for Apple to bypass the image caching functionality for just this type of images?