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.
"Not the real HSBC", and "Also not real HSBC" respectively.
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.
The only thing outside is the hostname, if the connection is not using the latest versions
Trying to MITM an existing tracker pixel when they're connected to public WiFi sounds like practically the hardest way to do it.
In this case, sending your malicious image through a fake email might get flagged, or even not opened by someone whos been trained in infosec enough to be suspicious of these things. But a tracking pixel in an email that is verifiably from a trusted entity will be opened no problem. Type of thing that will look pretty slick if you read about it being used
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.
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)
The main problem seems to be tracking pixel itself to deduce involvement. The suggested approach to send email to confirm email seem better, unless it contains link to login page (as it can be phished). So, the best seems to be that one should send email that explains user how to confirm e-mail by logging manually to the app.
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.