I approve of asking the customer to confirm the download.
I have a huge problem with the Chrome implementation: it fails silently. The only way to see what happened after you hammer a download link but your download does not start is to look at the dev console for logged browser errors!
That UX is terrible for customers dealing with legacy sites. It's even worse than the UX for dealing with self-signed certificates - surely an HTTPS site linking to an HTTP download deserves at least the same chance that a self-signed HTTPS site gets?
This all makes perfect sense from a market perspective.
Why tell the user what is wrong, when you can silently fail and make the user blame the website?
The goal of Google is to gaslight users away from using technologies that Google does not like.
And of course they prefer that you use an unencrypted connection over a self signed certificate. They want you be connected to a larger system in order to benefit from TLS.
If Google were to just cut to the chase, they would just forbid downloads from any domains that they didn't charge a fee to approve. Malware will of course get through sometimes, but Google will still get paid. They want to turn the web into an app store.
But the saddest thing of all, is that Mozilla will replicate whatever dark patterns Google implements, without any benefit to themselves or their users.
Long time downloader of things from `http / port 80` here. I treat every Windows binary I download as if it's a trojan or something with some malicious behavior in it. One heuristic to look at is: Does this binary have a 'digital signature'[0]? If not, why does the author of the software not add one, and does not having a signature make the binary suspicious?
Even with a signature present, I still upload the .EXE to Virustotal[1] to scan for malware. I don't trust modern AV software that sits in your machine since it is a privacy concern, but Virustotal is a website that runs in the cloud and doesn't scan every file on my computer and report back to HQ.
The biggest thing with digital signatures is that getting one trusted by Windows means entertaining a racket enabled by Microsoft.
There are two types of code signing certificates: regular, and EV. With regular certificates, all you get is effectively a way to carry your antivirus-based reputation with you as you continue to sign new binaries with it. At first sight, Windows will still throw up smartscreen warnings about it being potentially dangerous, until it's seen the certificate enough to trust it for new binaries.
With EV certificates, everything is smooth sailing - only if actual malware is reported does your certificate get slammed by antivirus reputation, otherwise you can sign anything and it'll instantly bypass all AV software and Windows smartscreen prompts.
The issue with getting either of these is that absolute cheapest one you can get is $59 a year for 3 years via a reseller[0] of Sectigo certificates, and that is only for regular code signing. If you want an EV certificate, it's going to be $219 a year for 3 years at the minimum via the same reseller (do not try to go through the regular channels or you'll likely be paying 2x-3x more[1]).
Thankfully Microsoft is aware of these concerns[2,3] and there is a potential solution coming up called Azure Code Signing[4] however no new public information has been released since that video went up.
0: https://codesigncert.com/brand (this is just the cheapest site I've found - I am not affiliated with them beyond being a customer)
The modern take that TLS only is required and must be enforced for everything, combined with the fact that TLS cert providers operate with normal power law popularity, means that by blocking HTTP sites and making mixed HTTP+HTTPS sites unusable in ways like this large segments of the web will have single points of technical or political failure.
TLS-*only* centralizes. LetsEncrypt's charter is made to resist corruption but as it's scale and the money involved grows it will probably end up going bad like dot Org did. That would be very bad for the web. Keeping HTTP and HTTP+HTTPS support around without stigmatizing or hiding it behind 2+ clickthrough warnings would prevent that failure mode.
Your comment suggests you may think this is blocking all downloads over HTTP; it’s not: it’s only blocking a HTTPS → HTTP downgrade. I don’t believe any browser is making any noise at all about blocking HTTP sites, or is likely to try in the coming decade at least, though I do hope for them to start warning more about it, with more prominent “Insecure” labels and the likes.
That's why I explicitly keep all by websites accessible both via HTTP and HTTPS. I don't care what Google thinks about it and how they choose to punish me. Some of my visitors value the transparency, prevalence and accessibility of HTTP, some value the privacy and integrity of HTTPS. Nobody will force me to give up on HTTP.
Can I ask, which protocol do your users get by default? I would like to enable http on my personal website, but then browsers seem to give most users the http version.
In other words, I would like to serve http://example.com if and only if the user explicitly inputs the http protocol; anyone who types example.com should get https://example.com. I haven't found a way to do this.
> There has to be some initial root point of trust.
For security critical web apps, this makes sense. For mere documents and simple sites without authentication or sensitive information, self-signed certificates should become acceptable, IMO.
How does a browser know which URLs are 'critical web apps' so that it can, if necessary, throw a big scary warning to the user? What stops a random website from self-identifying as critical (or not)?
The S in HTTPS guarantees things. If those guarantees are loosened, that can cause bad problems.
My root certificates are provided by a Debian package, not Google, so if I'm trusting anyone, I'm trusting them. (And their judgement of the root certificates).
It's not unheard of, that root certs are revoked for unsecure behaviour. It seems like the system works to me.
As long as they plan to keep the option up download over HTTP forever, I think this is a good idea.
However, I fear the day Mozilla will consider HTTP downloads obsolete the same wah they did away with FTP. The direction Mozilla is taking Firefox makes me distrust any barriers they're throwing up that are coined as "security" features.
I run Nightly and it had the very annoying issue that overruling the browser to actually download the HTTP-only download would fail 100% of the time. I hope they fixed that because there are still hundreds of valuable, older resources out there that I regularly download documents from.
Firefox Nightly did just block the downloads for a while. I think this implementation must have been based on feedback from that very annoying experiment.
Mozilla is being forced to follow the industry leaders here. And if ever HTTP is completely removed, that will first happen from their tech giants and browser choke hold, and Mozilla will have little choice but to follow behind.
The option to continue to allow non TLS should alleviate concerns. I can think of cases where vendor managed internal self signed certs are problematic and some IoT don't do TLS. Without getting into ideological debates, having a way to work around old, incomplete or clunky systems may be important to keep the browser relevant or useful.
If the big strong boy does it, it must be good. Who is firefox to decide about my actions ? Why a stoopid program prone to RCE shall know better ? Why do i have to go to about:config and disable safe browsing to be able to surf the web ?
Firefox will have a setting. Chrome, maybe not. Console-wise, try axel or similar offerings which are far more modern than wget in offering parallel multi-socket downloads (huge speed increase in many situations).
Tl;dr: the browser will alert the user when they try to download a file from an HTTP link within an HTTPS page ("mixed content"). Users will have to explicitly confirm the download if they want it to proceed. And there will be an about:config option to disable this warning altogether. Seems like a sensible choice to me.
Thank you for listing that alternative browser, although I'm not sure why it marked your post as dead? We need as many non-Chrome based alternatives as possible.
Thanks a lot for your work !
You’re the reason i could bring a 10-12 yr old laptop of mine back to life with a gui browser to go along with it , and also being able to use vi-keybindings !
I have a huge problem with the Chrome implementation: it fails silently. The only way to see what happened after you hammer a download link but your download does not start is to look at the dev console for logged browser errors!
That UX is terrible for customers dealing with legacy sites. It's even worse than the UX for dealing with self-signed certificates - surely an HTTPS site linking to an HTTP download deserves at least the same chance that a self-signed HTTPS site gets?