[jackfranklyn]

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.

[zahlman]

> But the reality is most banks treat their digital infrastructure like legacy plumbing - it works well enough that nobody wants to risk touching it.

They don't seem to have nearly the same concern for their online banking web UIs, though. Or even the UIs presented on screen at ATMs.

[lcnPylGDnU4H9OF]

Not that it justifies arbitrary UI updates but that has a different risk profile. It would be a potentially existential crisis for a bank to (for example) push an update to backend systems that credits one account without debiting another, especially at scale. In comparison, changing the graphical interface of clients which connect to those systems has a rather isolated blast radius.

[1vuio0pswjnm7]

"Someone had to actively choose to serve content over http in 2026."

To be fair, people actively choose to do this every day

For example, millions of people actively choose to do this for HTTP-01 ACME challenges

https://www.ietf.org/rfc/rfc8555.txt

https://letsencrypt.org/docs/challenge-types/

Certificate authorities also actively choose to do this for

1. TLS Certificates

For example, http://www.ssl.com/repository/SSLcom-RootCA-ECC-384-R1.crt

2. TLS Certifcate Revocation Lists (CRLs)

For example, http://crls.ssl.com/ssl.com-ecc-RootCA.crl

3. Online TLS Certificate Status Protocol (OCSP) responses

For example, http://ocsps.ssl.com

NB. If the statement was more specific, something like, "HSBC chose to use HTTP for return receipts in 2026" then I would have no reason to comment. Instead the statement suggests HTTP is no longer a useful nor appropriate choice for _anyone_. That of course is false, as shown above

[sam_lowry_]

I choose to serve my blog over HTTP, because we need no intermediaries to publish content on the Internet.

[1vuio0pswjnm7]

For end users of websites ("users") one problem with so-called "WebPKI", as this "WebPKI" is currently implemented, is

(a) it forcefully "delegates" trust to third parties, i.e., commercial CAs

(b) these CAs, for a fee, are happy to trust sites that the user would not trust if given the choice of which sites to trust, e.g., ad servers, tracking servers, etc.

(c) popular browsers pre-install (trust) third party commercial CA certificates^1

(d) popular browsers distrust the user's freely-generated CA certificates

The efforts of the user who wants to sign a small number of certificates from sites that he trusts are deliberately hindered by (d). For example, browser warnings, interstitials, TLS failures. The user is effectively discouraged perhaps even prevented from trusting himself, i.e., his own CA, while being forced to trust pre-installed third party commercial CAs

One might reason this problem could be avoided by not using popular browsers. However, website owners, and today, "Content Delivery Networks" (CDNs), attempt to coerce or force users accessing websites to use popular browsers. The CDNs terminate TLS connections and substitute their own server certificates . These certificates are signed by CAs approved by the browser vendor. This produces no browser warnings, interstitials, or TLS failures

However if the user terminates TLS connections and substitutes her own free certificate signed by her own free CA,^2 then this will trigger browser warnings, insterstitials and/or TLS failures. The practice of the user trusting herself more than third parties is deliberately hindered

From this state of affairs, one might conclude that TLS termination is acceptable under this "WebPKI" so long as the CA is approved by the browser vendor and the user is not the one doing the termination

1.

These pre-installed certificates in (c) are also distributed by a popular browser vendor as a "bundle" for installation in operating systems, non-browser software, etc.

In other words, users get these CA certificates not from the CA but from another third party, i.e., a browser vendor

But it's also possible to get the CA certificates directly from the CAs

This can be done over HTTP (cf. HTTPS)

2.

I do this using a loopback bound TLS forward proxy. I use TLS failures as an additional way to block undesired connections, e.g., to Google servers (another form of so-called "de-Googling")

The proxy performs _many_ different functions for me, allowing far more control and versatility than a popular browser. Plus I can modify and compile the proxy myself even on underpowered computers; it's only several MB. Whereas compilation of a popular browser is impractical by comparison. Compiling a so-called "modern" browser consumes too much time, CPU, RAM and storage space

One function is sending all HTTP requests over TLS, so, e.g., an http:// URL as in this story about HSBC would be sent as HTTPS^3

This applies to all software sending HTTP requests on the computer, not only browsers

I have a file that lists sites for which I do not want to go over HTTPS. This file is loaded into the proxy's memory and these sites will be forwarded by the proxy without using HTTPS. This is a short list but an important one

I use rinetd and DNS to send TCP and HTTP traffic to the proxy as opposed using the firewall. As such it's still possible to reach non-HTTPS sites via IP address, even in popular browsers

3.

If HSBC used IP addresses rather than a domain name, then this could bypass the proxy

[xtiansimon]

> “Every bank formats their statements differently…”

In my experience with bank data, on the downstream side, banking data is available in the OFX specification, which is a consistent transaction data format. Unfortunately, memo’s do get truncated to different char lengths by different banks, even though the specification allows 255 characters. AMEX, amazingly, switches NAME and MEMO properties. It's a dog breakfast of compliance, but there is a standard.

https://en.wikipedia.org/wiki/Open_Financial_Exchange

https://www.financialdataexchange.org/FDX/FDX/About/About-FD...

[direwolf20]

How do you get OFX data from your bank?

[crazygringo]

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.

[cryptonector]

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]

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.

[majkinetor]

I don't think it matters at all.

HTTPS doesn't encrypt query parameters. Content of the image itself is irrelevant, as its only purpose is to get request URL into the server logs.

[chowells]

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

[wolfi1]

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

[sandeepkd]

More than likely its a third party service managing the tracking of the email. Serving content over http just requires them to ask HSBC to add a domain entry for their (cName) server. HTTPS would increase the amount of work required.