> Well, if the user actually checks the signatures and remembers from their last visit that their should be one coming along with the software, maybe. That's a big if though.

HTTPS+HSTS adds no security here.

The only (reasonable) way to validate a payload end-to-end is an offline signature validation. This is true regardless of transport-level security measures like HTTPS.

Doing this properly with gpg makes even more sense due to the service targeting the paranoid, who is exactly the group of individuals who are certain to validate a signature.

> Considering there's no disadvantage in deploying HSTS and there's no good reason to serve an insecure website, especially since they already have HTTPS set up, I'm baffled by that decision. Maybe it's just an oversight but that's not too reassuring either.

It's easy, but adds nothing in ways of security here. Just privacy.

(Not that privacy does not have value, of course, but that's an entirely different argument.)

Assuming your attacker can count bytes, there's no privacy added by using TLS to download static content from the Tarsnap website. There simply aren't enough similarly-sized files.

But such an attacker would need to know that the content was downloaded from the Tarsnap website, right? If TLS is configured with Encrypted SNI, the handshake no longer reveals server information and thereby TLS does add privacy.

(However, Encrypted SNI is not widely adopted yet.)

The IP address alone will tell you that they're accessing the Tarsnap website.

I had a wrong understanding of what Encrypted SNI does and does not do. Thank you for the response.