Hacker News Reader

Comment by mfoy_ | Hacker News Reader

I don't see why a https:// site would serve up a http:// download link to an .exe in the first place.

Mixed-content rules would block even loading http:// images on a https:// page, so wouldn't you think that blocking .exe downloads from http:// sources on an https:// location would also be blocked?

I don't love Google, but this doesn't seem like a bad idea.

View on HN

Actually, right now, neither Google Chrome, nor Safari would warn the user at all, if you download ANY content via HTTP from a HTTPs encrypted website, it's a bug I filed for both browsers, but they didn't get resolved yet. I wrote in more depth about this topic over her https://krausefx.com/blog/trusting-sdks

A properly behaving site would not. One hacked by malware distributors could.

Malice is certainly possible, but someone simply making a mistake is another easily plausible cause. Many sites don't correctly redirect all URLs to from http to https.

Mistakes will be fixed pretty quickly if this policy gets implemented, so I don't see it as a problem.

Yeah, it's going to be a nice forcing function to fix these mistakes.

Counter-example: Ubuntu serves their ISO via an HTTP link on an HTTPS page. They supply a gpg signature as a way to validate that the file was not tampered with.

Why? Why not serve the ISO over HTTPS?

The hostname resolves to a bunch of different mirrors run by different people who don’t all share a secret key between them.

There are workarounds for this (using a redirector service and unique hostnames) but that is an additional request of donors who are providing them a lot of bandwidth for free.

It’s not a great reason, but it is a reason.

ISO files are not considered a common (if not most common) vector for malware delivery. While it’s dumb that they serve it over HTTP (don’t use CNAME-based mirror setups, everyone) it’s also neither putting anyone at significant risk to allow it nor under consideration for blocking.

Reply on news.ycombinator.com