So, it's like the [Spectre] attack against CPUs: trigger an access from a privileged context, check if the access has filled in some cache, infer privileged information from that.

It seems that time and again, security-enforcing procedures assume that many functions they invoke are pure, but in reality these functions have side effects, and these effects are observable much easier than the security requires.

The actual problem here that the secured area is only the stuff that came through the encrypted channel. Any access beyond it, like following a link, is obviously insecure. If the link was sent via the secure channel, it becomes even less secure because it allows to observe a correlation between the secure channel (otherwise impenetrable) and the insecure outside context, and allows to blow (some of) the cover. Opening links via Tor would mitigate it a bit.

The hard truth here is that almost everything may have observable side effects, so opsec needs to permeate all aspects of life, the more cover you need, the fuller. This is mostly incompatible with a convenient UX, but, to be popular, a secure messenger has to be reasonably convenient. This necessarily limits the level of security attainable by its casual use.

[Spectre]: https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...