Slashdot Mirror
Google Chrome Wants To Block Some HTTP File Downloads (zdnet.com)
An anonymous reader writes: Google wants to block some file downloads carried out via HTTP on websites that use HTTPS. The plan is to block EXE, DMG, CRX, ZIP, GZIP, BZIP, TAR, RAR, and 7Z file downloads when the download is initiated via HTTP but the website URL shows HTTPS.
Google said it's currently not thinking of blocking all downloads started from HTTP sites, since the browser already warns users about a site's poor security via the "Not Secure" indicator in the URL bar. The idea is to block insecure downloads on sites that appear to be secure (loaded via HTTPS) but where the downloads take place via plain ol' HTTP.
Google said it's currently not thinking of blocking all downloads started from HTTP sites, since the browser already warns users about a site's poor security via the "Not Secure" indicator in the URL bar. The idea is to block insecure downloads on sites that appear to be secure (loaded via HTTPS) but where the downloads take place via plain ol' HTTP.
Why oh why does Google think that they know better than everyone? Give a warning, sure, and then let the user decide. Just the same way it handles an HTTP page vs an HTTPS page.
But http or https doesn't really matter these days, even malicious sites are using https..
As long as you get a warning when downloading and you are still able to download the file, I don't have anything against it. But if they just block download completely because it isn't coming from an https site, than I won't be using Chrome anymore.. As I said, https doesn't say anything about the file being safe.
Ok, and how exactly do they expect people to be able to download software, or other files?
Apparently in Google's world everyone has gigabit fibre so very large log files (for example) is not an issue. But for those of us in the real world, being able to compress stuff before sending is still incredibly valuable.
(And for anyone that plans to latch onto the log file example like starving dog on a steak and say "Well you should be splitting up your log files!", I kindly invite you to eff off in advance. I'm talking about the real world, where shit happens on a routine basis...)
Is that we could all agree on some sort of standard whereby from a secure site you could initiate a download, have that download be unencrypted, but the download link would include a sha256 checksum that would be checked automatically by the browser once the download was complete.
This would allow popular downloads to be cached closer to the user, while providing for verification of the download integrity.
...si hoc legere nimium eruditionis habes...
Most sites provide their file hashes over HTTPS. If I'm going to verify the file on my end anyway, there's no real reason for the site to waste CPU encrypting the entire ISO every time someone downloads it.
Digital signatures and hash verification address the same security concerns with less impact.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
It brings back bad memories of when Google decided that certain filetypes were too dangerous to be handled by gmail, so suddenly I could no longer access a bunch of .js files a buddy had sent me long ago that I had in my mailbox. I was not impressed.
Considering how many are downloading from wifi or untrusted router, it doesn't make sense to use http because you can get you file change during the download. HTTPS wont slow you down and will offer basic security against the hacker next door. For web hosting, https://letsencrypt.org/ offer free SSL certificates.
Including .EXE but forgetting about .SCR, .COM, .BAT, .LNK, and possibly other extensions that are treated just like .EXE files?
(Yes, .BAT files which are valid PE executables will run as executables, and it won't try to execute it as a command prompt script)
The idea is not to prevent to download them but to prevent the ISP, rooter, internet cafe or guy next door to change the content of that .exe during the download.
I think there's actually a push to encrypt too much. It's got obvious benefits for privacy and security, but encrypted traffic can't use the internet's caching infrastructure which would benefit popular downloads, which tend to be ZIPs, EXEs, TARs and such. What I'd really like to see is browser integration to insecurely download files and securely confirm its fingerprint.
That said, informing the user aware of an unencrypted download from an encrypted site would be good. Blocking it would be bad.
... web site to go through all their web pages and make sure that no instances of "http:" are accidentally left in pages where downloads are available?
It might be easier for web sites to merely add a browser detector to their pages to warn the user that they're using a product from a vendor that's actively trying to make their use of the Internet into a royal pain in the behind?
CUR ALLOC 20195.....5804M
The Google Chrome engineer who posted this ask to the W3C mailing list ( https://lists.w3.org/Archives/... ) also made a social media poll, https://twitter.com/estark37/s...
Essentially, they're reinforcing their own echo-chamber effect to only listen to confirmations of their conceived notion of correctness rather than truly encouraging discourse on the matter. Her poll options are, "yes" and "yes" -- and several Twitter replies have been deleted.
Personally, it seems they are an engineer looking for a problem to solve to help justify their job... and that's just sad in itself.
Google are doing it in a standards based way though, Microsoft didn't.
If you visited the site using another browser, you can still do the download. Once the website admin jumps through Google's hoops, the download will still work correctly in any other browser that properly follows the HTTPS standard.
*router
It's getting close to a point where we need to make our own web and web browsers, with blackjack and hookers (but seriously!). There are lots of free TCP ports left, let's just choose another one and walk away from the HTTP2/3/AMP/QUIC bullsh$t. Make a translator gateway if someone wants to visit the "Google-web" with all of its limitations.
This is a clear violation of stack layers -- a general purpose APP for browsing and fetching online content should NOT attempt to be the gatekeeper for what the TRANSPORT is trying to send. This is equivalent to an email program refusing to forward mails with the (non)-word 'alot' in it, because the programmers want to stamp out bad grammar. It's NOT THE PROGRAM'S PLACE TO DECIDE.
It already blocks .torrent files on certain sites. Says they are dangerous. Orly?
If there was a virus that would render 4chan's foul spawn unable to get on the Internet, I'd be all for it. Even if you're joking, you're still a disgusting piece of crap.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Yeah, if you ask 10 random people what TLS is, you'll find out why Google security engineers think that they know security better than thr average consumer does. It's their. JOB to know security, so they SHOULD be much better informed than the average user. They shouldn't forget that fact when they make *defaults* and *warnings*.
On the other hand, I've been an internet security professional for twenty years. I can reasonably decide to override the defaults in selected situations. I am not a typical user in that regard.
On the contrary, i have some recollection of some nation-states poisioning downloads of "encrypted" communication apps to be able to eavesdrop. (Egypt? Iran?).
If you had a physical safe, 2,000 pounds, which would open whenever someone tapped it on the left side, that would be a defective product. Since you probably bought the safe to protect valuables, you'd want to know if it doesn't offer any security. A security warning about that safe would be warranted.
A cardboard box would not be defective of it could be opened easily. You don't store gold in a cardboard box and expect high security.
By applying TLS, the site operators are essentially declaring that the content needs to be protected and claiming that it is protected. If it's not actually protected as claimed, users may want to know about that.
The problem is that you suggest the common user can tell the difference between a cardboard box and a safe. They can't (thus the green locks and such), and yet we're still treating a safe with potentially no lock (or potentially the best lock of all, if you roll your own cert, verify keys out-of-band, and save them) as a less secure container than a cardboard box. Which it in no way is.
"When information is power, privacy is freedom" - Jah-Wren Ryel
The purpose of the cert is for the browser to know whether they are talking to your server, or to my MITM proxy which I made on a Raspberry Pi, ans presents itself as a WiFi network "Convention Guest WiFi".
If you don't tell the browser WHICH cert you've rolled, it's unable to distinguish your cert from my imposter cert, and therefore you have almost zero security.
> you suggest the common user can tell the difference between a cardboard box and a safe. They can't (thus the green locks and such)
I suspect users can see a green lock and have some idea what it means.
The green lock is there because the user doesn't know the difference between http: and https: in the URL bar. As such, the browser should display the green lock for an HTTPS connection with a valid cert and not display one for an HTTP connection or an HTTPS connection with an invalid cert. It's even easier for your RasPi to MITM an HTTP connection, but the browser will happily use that protocol without complaint.
"When information is power, privacy is freedom" - Jah-Wren Ryel
If you visited the site using another browser, you can still do the download.
Another browser won't even run on a pre-Crostini Chromebook.
You just get one of hundreds of CAs to issue you a cert by MITMing their automated DNS/Website flag planting procedure
Would these be CAs that submit all issued certificates to Certificate Transparency or CAs that do not?
.exe files are harmless on Linux
Unless the user has installed Wine. Valve's Proton distribution of Wine will only make Wine more commonplace among users of X11/Linux.
What does the neighborhood of Hollywood or even the US movie industry have to do with HTTPS? Let's Encrypt offers free certificates to anyone who owns a domain name.
encrypted traffic can't use the internet's caching infrastructure which would benefit popular downloads
A CDN contracted by the operator of the origin server, such as CloudFront or Cloudflare, can cache HTTPS just as easily as cleartext HTTP.
Why on earth would one want to protect a file download against third parties?
Two reasons:
A. Protect a proprietary work from being downloaded by third parties who have not paid for access to the work
B. Protect a work from being modified in transit
[TLS] is only a transport PRIVACY measure against third-parties interposed between the two end-points (who may not be who you think they are)
My reply depends on what attack model you had in mind that results in the parties not being "who you think they are". Does it involve defrauding a CA? Typosquatting? Something else that you'll describe?
Hmm Yiddish is actually 80% German. I am German and I can understand it. It sounds like a German dialect, and I only fail to understand some of the Hebrew and Polish words sprinkled in. This such a plain and well-known fact and even that you get wrong. Sheesh.
There are two rules for success:
1. Never tell everything you know.
It's what the body craves.
There are two rules for success:
1. Never tell everything you know.
Same stupidity for .dmg files on the Mac. Unless you open it, double click on the app contained within and then enter your password on the following dialogue to grant the app admin rights, nothingâ(TM)s gonna happen with that file.
There are two rules for success:
1. Never tell everything you know.
As long as it continues to let me download FirefoxSetup.exe, we're good.
why not include office documents and pdf's as well? they've been a source of infections too.
well, not much else is left except pure media (video/audi/pictures) files.
On a long enough timeline, the survival rate for everyone drops to zero.