> 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.)
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.)