5 ms·

I don't see why a https:// https:// site would serve up a http:// http:// download link to an .exe in the first place. Mixed-content rules would block even loa

by mfoy_ 8y ago

I don't see why a https:// https:// site would serve up a http:// http:// download link to an .exe in the first place. Mixed-content rules would block even loading http:// http:// images on a https:// https:// page, so wouldn't you think that blocking .exe downloads from http:// http:// sources on an https:// https:// location would also be blocked? I don't love Google, but this doesn't seem like a bad idea.

floatingatoll 8y ago
A properly behaving site would not. One hacked by malware distributors could.
- CydeWeys 8y ago
  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.
  - kemitche 8y ago
    Mistakes will be fixed pretty quickly if this policy gets implemented, so I don't see it as a problem.
    - CydeWeys 8y ago
      Yeah, it's going to be a nice forcing function to fix these mistakes.
- kemitche 8y ago
  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.
  - mfoy_ 8y ago
    Why? Why not serve the ISO over HTTPS?
    - sneak 8y ago
      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.
  - floatingatoll 8y ago
    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.
krausefx 8y ago
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 https://krausefx.com/blog/trusting-sdks

by mfoy_ 8y ago

floatingatoll 8y ago

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

CydeWeys 8y ago
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.
- kemitche 8y ago
  Mistakes will be fixed pretty quickly if this policy gets implemented, so I don't see it as a problem.
  - CydeWeys 8y ago
    Yeah, it's going to be a nice forcing function to fix these mistakes.
kemitche 8y ago
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.
- mfoy_ 8y ago
  Why? Why not serve the ISO over HTTPS?
  - sneak 8y ago
    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.
- floatingatoll 8y ago
  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.

krausefx 8y ago

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 https://krausefx.com/blog/trusting-sdks