Remix.run Logo
jackfranklyn 2 hours ago

The http:// thing is what stands out to me. Someone had to actively choose to serve content over http in 2026. Even if the original template was ancient, any security review would have caught that - unless they skipped that step entirely, which honestly tracks.

I work with banking data day to day and the internal systems are often just as rough. CSV exports with inconsistent date formats between the same bank's own products. Transaction descriptions that are random truncated strings with no standardisation. Every bank formats their statements differently and some of them can't even stay consistent between their own account types.

You'd think with the regulatory pressure around data accuracy this stuff would be sorted by now. But the reality is most banks treat their digital infrastructure like legacy plumbing - it works well enough that nobody wants to risk touching it.

crazygringo an hour ago | parent [-]

Does HTTP really matter in this particular case though?

HTTPS still typically exchanges the Server Name Identification. So you know somebody is talking to HSBC. And the rest of the URL is just an anonymized tracking ID. So I'm having a hard time seeing what the threat is this particular instance.

chowells 26 minutes ago | parent | next [-]

The article addresses this, actually. Fetching any unsecured content is an attack vector. https://danq.me/2026/01/28/hsbc-dont-understand-email/#footn...

crazygringo 11 minutes ago | parent [-]

In this particular case, injecting content into the image to make someone read a false message doesn't seem possible. The pixel <img> tag has width and height set to one. This overrides whatever the image size is. No altered message will be readable.

cryptonector 44 minutes ago | parent | prev | next [-]

Yes it matters. First, there can be much much more metadata in the URI local part than just in the SNI -- just because it looks anonymized doesn't mean that it is. Second, ESNI is a thing and it's going to get more deployment. Third, DNS queries for ESNI can go over HTTPS/TLS/QUIC.

cess11 24 minutes ago | parent | prev | next [-]

The author put some text in base64 in the URL:s, perhaps the original had information encoded in such a way that might leak something interesting.

"Not the real HSBC", and "Also not real HSBC" respectively.

wolfi1 an hour ago | parent | prev [-]

as it's a tracking pixel it's personalized, if you are reading your email in the cafeteria with their wifi, potentially everybody in the cafeteria know more about you than they need

crazygringo an hour ago | parent [-]

What do you mean it's personalized? It's an anonymous identifier token specific only to that email.

Like I said, even with HTTPS everyone in the cafeteria theoretically knows you're connecting to HBSC as well.

So I don't see the difference.

danaris 10 minutes ago | parent | next [-]

What on earth makes you think it's anonymous?

It's trivial to encode each tracking pixel with a personalized hash of some sort linking it to the intended recipient of that particular email.

This is...just how tracking pixels work.

cryptonector 41 minutes ago | parent | prev | next [-]

You _think_ it's anonymous.

sharperguy an hour ago | parent | prev [-]

They know that you likely read some email from HSBC and if you happen to read the same one again they will know it was the same one.

crazygringo an hour ago | parent [-]

Right. But even over HTTPS it's not rocket science to figure out that connecting to www.email1.hsbc.co.uk pretty strongly suggests you've opened an e-mail with an image. And the number of times you request the same URL tells someone... what exactly? Because HTTPS still tells people the number of times you access any URL on a domain.

awesome_dude 35 minutes ago | parent [-]

Worst case scenario is the HTTP pixel request tells attackers that there is a verification chat happening.

HTTPS the attackers know a conversation is happening, but no idea what

But, I personally think the threat is being overblown (I am happy to be corrected though)