Firefox follows Chrome and prepares to block insecure downloads
therecord.media
therecord.media
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?
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.
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.
[0] https://www.ghacks.net/2018/04/16/how-to-verify-digital-sign...
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)
1: https://sectigo.com/ssl-certificates-tls/code-signing
2: https://github.com/MicrosoftDocs/windows-driver-docs/issues/...
3: https://github.com/MicrosoftDocs/windows-driver-docs/issues/...
This Firefox change sounds reasonable to me. Why would this not be 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.
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.
It depends what you mean by centralizes. I can buy an SSL certificate from any number of companies.
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.
The S in HTTPS guarantees things. If those guarantees are loosened, that can cause bad problems.
It's not unheard of, that root certs are revoked for unsecure behaviour. It seems like the system works to me.
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.
Only to be removed in the next release (possibly)...
Luckily a few promising alternative browsers are popping up.
anything not based on chromium?
https://github.com/qutebrowser/qutebrowser/commit/c022893a76...
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 !
Really appreciate it
Thanks for the nice words, much appreciated too!