Blocking high-risk non-secure downloads(lists.w3.org)
lists.w3.org
Blocking high-risk non-secure downloads
http://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html
96 comments
jason2015(2)
From my reading, it looks they're considering this for only non HTTPS downloads initiated from an HTTPS page
Relevant quotes:
> ... we will likely start by treating certain high-risk downloads initiated from secure contexts as active mixed content and block them.
> We're not planning to focus on non-secure downloads initiated from non-secure contexts at the moment, because users at least see the "Not Secure" omnibox badge on those pages.
Relevant quotes:
> ... we will likely start by treating certain high-risk downloads initiated from secure contexts as active mixed content and block them.
> We're not planning to focus on non-secure downloads initiated from non-secure contexts at the moment, because users at least see the "Not Secure" omnibox badge on those pages.
Clever. This means users won't be able to easily download software from websites not plugged into CA tree. One more step towards eradicating the ability of people to independently host websites altogether.
Increasingly, I see that the web no longer fulfills any of its original goals. On the other hand, if I look at it as a software delivery/execution platform I see a horrible mess that could have been designed a zillion times better if that was the goal to begin with.
Increasingly, I see that the web no longer fulfills any of its original goals. On the other hand, if I look at it as a software delivery/execution platform I see a horrible mess that could have been designed a zillion times better if that was the goal to begin with.
Couldn't you add additional certificate authorities to your browser at will?
The CA system is decentralized by nature. If the existing authorities start trying to manipulate your internet by controlling who they verify, which hasn't really happened that I'm aware of, you can always add a new root certificate. Or consumer browsers can offer new CA roots out of box.
The CA system is decentralized by nature. If the existing authorities start trying to manipulate your internet by controlling who they verify, which hasn't really happened that I'm aware of, you can always add a new root certificate. Or consumer browsers can offer new CA roots out of box.
The point isn't what you can do as a user. The point is that Google adds more and more hurdles to running a website without plugging into the CA chain.
CA chain is centralized. Plus, it requires you to have a domain name. DNS is also centralized (although to a somewhat lesser extent).
Effectively, we're seeing yet another step in hyper-centralization of the web.
CA chain is centralized. Plus, it requires you to have a domain name. DNS is also centralized (although to a somewhat lesser extent).
Effectively, we're seeing yet another step in hyper-centralization of the web.
How many websites do you actually use don't have a domain name?
also, as above, there is no one root CA. you can add and remove any ca from your system. most users don't because why would you trust a random ca from some random site.
What's the actual problem here?
also, as above, there is no one root CA. you can add and remove any ca from your system. most users don't because why would you trust a random ca from some random site.
What's the actual problem here?
That i do not want some third party's permission to make my site and desktop applications available to everyone.
Note the one you asked, but i have the same issues with the certificate mafia.
Note the one you asked, but i have the same issues with the certificate mafia.
[deleted]
Getting modern browsers to accept your CA is a huge pain, different per browser and OS, and barely anyone will do it.
The moment anyone starts a community CA for this they'll just blacklist it.
The moment anyone starts a community CA for this they'll just blacklist it.
Are you implying there aren't a lot of CAs to choose between?
How would you design it a "zillion times better"?
How would you design it a "zillion times better"?
That's not how I read it. The nonsecure download from a secure page is their starting point. The end goal is to block all unsecure downloads of high risk types.
Is it possible to disallow all non secure/https requests in Chrome?
The EFF's httpseverywhere extension works well, you need to set it to block if it can't upgrade the connection to tls
Great concept but the plugin is an absolute memory hog, and they've been unable to fix it.
They closed the old bug for no real reason:
https://github.com/EFForg/https-everywhere/issues/1775
Then let the new bug rot:
https://github.com/EFForg/https-everywhere/issues/12232
They've now started deleting new comments on the new bug. I'm just not using it anymore.
They closed the old bug for no real reason:
https://github.com/EFForg/https-everywhere/issues/1775
Then let the new bug rot:
https://github.com/EFForg/https-everywhere/issues/12232
They've now started deleting new comments on the new bug. I'm just not using it anymore.
The DuckDuckGo Privacy Essentials¹ extension is a great alternative that I switched to.
¹ https://chrome.google.com/webstore/detail/duckduckgo-privacy...
¹ https://chrome.google.com/webstore/detail/duckduckgo-privacy...
The easiest way to do that is to use your OS provided firewall to block all outgoing HTTP requests from chrome and only allow HTTPS.
That's how I read it as well. Boiling the frogs.
I agree with your reading. I've flagged this post as the title is misleading.
I dont understand why they are doing this.
.exe files are known to be dangerous so usually when one downloads it you make sure its from a safe website.
How is blocking non-https .exe downloads making this any safer for end-user?
I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
Also when I think about this, this only hurts legacy windows applications which probably is hosted on a non-http site. I dont like this move at all.
I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
Also when I think about this, this only hurts legacy windows applications which probably is hosted on a non-http site. I dont like this move at all.
Google found a threat model where attackers inject http:// .exe links into https:// web pages. This exposes a flaw in mixed-content handling, where web pages don’t allow http:// resources to be loaded - but DO allow resources to be downloaded. Addressing that flaw for all file types would probably break a lot of the internet, but not for .exe (in their apparent estimation). I look forward to hearing what the Firefox and Edge teams think of this.
TLDR: In this approach, http:// sites can link http:// executables, but https:// sites cannot.
TLDR: In this approach, http:// sites can link http:// executables, but https:// sites cannot.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
[deleted]
> I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
I second this. Their market share affords them far too much luxury with not nearly enough impartial oversight.
> I dont understand why they are doing this.
I do understand why they're doing this. Me and you are smart enough to know to only trust a download from a secure connection. Others don't. I've fixed two computers THIS MONTH from people who opened email attachments and then proceeded to click past all of the Office security warnings. Both of them were Kovter droppers. The average user doesn't know what the padlock means, and if you hid a non secure download behind an https redirect they wouldn't even know.
Another story, just last week, my town of 9k people has a "social network" based on dotNetNuke on some sketchy shared/co-hosted server without HTTPS. They tried to spam their network on a local FB group recently and they don't even have an SSL cert. Still, the sheer volume of idiots who visited and posted comments like "there's a bug, I can't create an account" or "just signed up!" was disgusting. I posted a stark warning and chewed out the spammer for not taking the 10 minutes to get a free SSL cert, which was when I learned of their sketchy hosting situation.
So you see, not only do regular users not know what their looking at on the internet; other web developers also have no idea and don't really care. They insisted to me they have their own security measures which negate the liablity of not encrypting traffic; to which I responded that I could setup a fake AP at the local coffee shop and start stealing passwords if he didn't beleive me. The post was deleted after that, but most of the country bumpkins in my town stood BEHIND HIM!!! They thought I was being mean to a local business.
The boogey-man can't sneak up on us, but many people are just going through life and need someone to watch their back digitally. Besides, the only time you initiate a non-secure download of an application from a secure connection is when you've injected payload fetching code into an XSS vulnerability. I can see literally no other use-case unless the developer is an idiot (see paragraph 3).
I second this. Their market share affords them far too much luxury with not nearly enough impartial oversight.
> I dont understand why they are doing this.
I do understand why they're doing this. Me and you are smart enough to know to only trust a download from a secure connection. Others don't. I've fixed two computers THIS MONTH from people who opened email attachments and then proceeded to click past all of the Office security warnings. Both of them were Kovter droppers. The average user doesn't know what the padlock means, and if you hid a non secure download behind an https redirect they wouldn't even know.
Another story, just last week, my town of 9k people has a "social network" based on dotNetNuke on some sketchy shared/co-hosted server without HTTPS. They tried to spam their network on a local FB group recently and they don't even have an SSL cert. Still, the sheer volume of idiots who visited and posted comments like "there's a bug, I can't create an account" or "just signed up!" was disgusting. I posted a stark warning and chewed out the spammer for not taking the 10 minutes to get a free SSL cert, which was when I learned of their sketchy hosting situation.
So you see, not only do regular users not know what their looking at on the internet; other web developers also have no idea and don't really care. They insisted to me they have their own security measures which negate the liablity of not encrypting traffic; to which I responded that I could setup a fake AP at the local coffee shop and start stealing passwords if he didn't beleive me. The post was deleted after that, but most of the country bumpkins in my town stood BEHIND HIM!!! They thought I was being mean to a local business.
The boogey-man can't sneak up on us, but many people are just going through life and need someone to watch their back digitally. Besides, the only time you initiate a non-secure download of an application from a secure connection is when you've injected payload fetching code into an XSS vulnerability. I can see literally no other use-case unless the developer is an idiot (see paragraph 3).
You are baffled that they reacted this way, that you became the villain? It's hard sometimes, but I've found it helpful to try to perceive both myself and the digital obstacles from the shoes of users I'm trying to help (calibrating more as I proceed), and adjust myself accordingly.
Affording someone the ability to save face is among the reasons to consider making a private approach. And when irritated, slighted or indignant, when amped up somehow, not disengaging to cool down is the sort of thing I tend to regret.
It's a tall order to expect people to interpret an offer to steal passwords in a coffee shop to assert their need of your acumen as a beneficent act.
Affording someone the ability to save face is among the reasons to consider making a private approach. And when irritated, slighted or indignant, when amped up somehow, not disengaging to cool down is the sort of thing I tend to regret.
It's a tall order to expect people to interpret an offer to steal passwords in a coffee shop to assert their need of your acumen as a beneficent act.
Thanks. I think I am actually going to benefit from this.
>I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
Here is a reply from Mozilla representative in that very thread:
"I would be very happy to push in this direction, limited by the amount of breakage and user-pushback we can expect."
http://lists.w3.org/Archives/Public/public-webappsec/2019Apr...
Here is a reply from Mozilla representative in that very thread:
"I would be very happy to push in this direction, limited by the amount of breakage and user-pushback we can expect."
http://lists.w3.org/Archives/Public/public-webappsec/2019Apr...
It doesn't matter if the website is "safe" if the download happens over plaintext HTTP. Any middleman could replace the executable with anything, or worse: just inject malicious code into the executable so you don't notice anything is amiss.
And break the code signature in the process, thus causing Windows to display a large nasty warning about the exe being unverified.
What, you mean this warning? https://files.brightside.me/files/news/part_46/468060/205938...
I don't know any normal user who would think twice about clicking "Yes" on a prompt like that when they're trying to install a program they just downloaded. There are plenty of legitimate programs that don't have a signature, and plenty of malicious programs that do.
I don't know any normal user who would think twice about clicking "Yes" on a prompt like that when they're trying to install a program they just downloaded. There are plenty of legitimate programs that don't have a signature, and plenty of malicious programs that do.
A big problem is that it's so difficult (and expensive) to get a code signing certificate that's valid under Windows that many developers just don't bother:
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
>A big problem is that it's so difficult (and expensive) to get a code signing certificate that's valid under Windows that many developers just don't bother:
That's for EV certificates. Regular certificates are a lot more affordable: https://comodosslstore.com/ca/code-signing (~$100/yr). For comparison, apple developer program is also around $100/yr. Certum also provides discounted certificates for open source projects (around $30).
>Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
The only reason that letsencrypt can be free is that domains can be validated at 0 marginal cost. Code signing certificates are issued to persons or corporations, not domains. Because of that, the issuer has to do a bunch of manual checks that drives up the marginal cost of each certificate.
Also, letsencrypt has many corporate sponsors who directly benefit from https adoption. Who benefits from microsoft code signing certificate adoption? Only microsoft.
That's for EV certificates. Regular certificates are a lot more affordable: https://comodosslstore.com/ca/code-signing (~$100/yr). For comparison, apple developer program is also around $100/yr. Certum also provides discounted certificates for open source projects (around $30).
>Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
The only reason that letsencrypt can be free is that domains can be validated at 0 marginal cost. Code signing certificates are issued to persons or corporations, not domains. Because of that, the issuer has to do a bunch of manual checks that drives up the marginal cost of each certificate.
Also, letsencrypt has many corporate sponsors who directly benefit from https adoption. Who benefits from microsoft code signing certificate adoption? Only microsoft.
> Certum also provides discounted certificates for open source projects (around $30).
The Certum ones turn out to be about 135 Euro, after the mandatory super expensive (and super slow) postage for the key fob to store the key on is included.
They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
The Certum ones turn out to be about 135 Euro, after the mandatory super expensive (and super slow) postage for the key fob to store the key on is included.
They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
>The Certum ones turn out to be about 135 Euro, after the mandatory super expensive (and super slow) postage for the key fob to store the key on is included.
I heard that you could use any smartcard/hsm, not just their fob, so there might be same savings there.
>They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
What's the issue here? Certum is the CA so they can already issue whatever certificates they want. They don't need to steal your cloud keys. The only real threat is if their service gets hacked, but at that point the hacker could also re-issue your certificate with his keys.
I heard that you could use any smartcard/hsm, not just their fob, so there might be same savings there.
>They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
What's the issue here? Certum is the CA so they can already issue whatever certificates they want. They don't need to steal your cloud keys. The only real threat is if their service gets hacked, but at that point the hacker could also re-issue your certificate with his keys.
Just my general lack of trust in things stored "securely" in the Cloud, vs securing it locally offline ourselves. :)
There are plenty of examples of stuff that should be secure, being leaked.
Also, if Certum "gets hacked" that's not a generic blanket giving complete access to every one of their systems. It's entirely possible they could get "hacked" and the hackers would only obtain read only access to stuff, without penetrating whatever signing systems there are.
Using a local fob circumvents several of those particular threats.
The weirdly expensive and slow postage option makes me curious about other things though. But that's probably just my paranoia revealing itself. ;)
There are plenty of examples of stuff that should be secure, being leaked.
Also, if Certum "gets hacked" that's not a generic blanket giving complete access to every one of their systems. It's entirely possible they could get "hacked" and the hackers would only obtain read only access to stuff, without penetrating whatever signing systems there are.
Using a local fob circumvents several of those particular threats.
The weirdly expensive and slow postage option makes me curious about other things though. But that's probably just my paranoia revealing itself. ;)
Not saying this is the right solution but the vast majority of Chrome users likely do not know exe files can be dangerous.
[deleted]
If you download an exe from a nonsecure connection. You cannot be sure the exe is the one offered by the site or one provided by a man in the middle. I know there are CRC checks but, this protection is not for user that understand that.
As a PSA, CRC checks are insufficient to prevent tampering. CRC checks are designed to detect accidental corruption, not deliberate. Cryptographic hashes, provided over a secure connection (not http), are the basic minimum.
Do note that even then, there have been demonstrated exploits of package managers downloading over http, where the parsers were demonstrated to be compromised.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462
(nice summary of the above CVE https://www.securityweek.com/code-execution-vulnerability-im...)
Do note that even then, there have been demonstrated exploits of package managers downloading over http, where the parsers were demonstrated to be compromised.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462
(nice summary of the above CVE https://www.securityweek.com/code-execution-vulnerability-im...)
[deleted]
> I dont understand why they are doing this.
They want people to fear the desktop since they have no control over it nor way to monetize it and move them to the web where the only way to monetize software is through ads and subscriptions and they provide solutions for both (as well as the hosting/infrastructure for implementing those applications).
They want people to fear the desktop since they have no control over it nor way to monetize it and move them to the web where the only way to monetize software is through ads and subscriptions and they provide solutions for both (as well as the hosting/infrastructure for implementing those applications).
Don't block anything excepting drive-by downloads. If I click on something with the intent to download it, it shouldn't matter what the source is.
This is why I use FireFox.
This is why I use FireFox.
Yes it should - if I'm on https://trustedsite.com and they link to http://notsotrustedsite.com/someexe.exe you are vulnerable.
Linking from https://trustedsite.com to https://nottustedsite.com/someexe.exe doesn't seem to be much better. Nottrustedsite.com can serve you a malicious exe either way.
Https protects you against network MITMs, not evil sites sending you evil executables.
Https protects you against network MITMs, not evil sites sending you evil executables.
I also use Firefox, but this discussion should probably not be the reason to do so: Mozilla has stated that they are tentatively onboard with the approach proposed by the Chrome team: http://lists.w3.org/Archives/Public/public-webappsec/2019Apr...
So, the thing is, they are working to ensure that is true. If you download it from a non-secure source, it can be changed on route. What you intend to download and what you actually download are different.
Hash checks, file signatures, etc. make that a non-issue.
At this point, with all the restrictions happening, how about we just require a license to use the internet? Just skip all this crap because that's about where we're heading now.
At this point, with all the restrictions happening, how about we just require a license to use the internet? Just skip all this crap because that's about where we're heading now.
This seems like a direction Firefox would go in too. Web security is important, and preventing downloading of insecure executables is an easy win for security.
Firefox's nannying isn't much less irritating (forced plugin signing, etc.)
Until you fall victim to clickjacking.
I actually read the URL in the status bar when I hover over things to click. Not once in my nearly 40 years of life have I ever fallen prey to clickjacking.
I wonder why the focus is just on downloads from https pages. I've not thought about this for very long but why is it ok for https pages to link to http pages? If I navigate to https://trustedsite.com, and they link to http://trustedsitesortof.com, my browser should warn me.
That doesn't make sense, think HN/Reddit/etc, which are HTTPS and primarily link to other sites which can (and very often are) HTTP. There is no security compromised here nor any other link between the two than one referring to another.
Linking resources (like images, files, etc) is another topic, but it doesn't make much sense to put a barrier for pages. If nothing else, you get annoying warnings that people learn to ignore.
Linking resources (like images, files, etc) is another topic, but it doesn't make much sense to put a barrier for pages. If nothing else, you get annoying warnings that people learn to ignore.
> my browser should warn me
I remember those dialogs in Netscape 4. They were incredibly annoying.
I remember those dialogs in Netscape 4. They were incredibly annoying.
It used to warn you. IE6, I believe, used to say "you're about to leave a secure site", or something along those lines. But the world was different then, and HTTPS wasn't as common as it is today. I strongly suspect that that sort of warning will soon be coming back.
What if this was allowed: (Please excuse non-angle brackets.)
[A HREF="http://example.com/SomeProgram.exe" ExpectedSha256="..."]Download[/A]
If clicked, the download is checked and is quietly discarded if the hash is wrong.
[A HREF="http://example.com/SomeProgram.exe" ExpectedSha256="..."]Download[/A]
If clicked, the download is checked and is quietly discarded if the hash is wrong.
Now every time I want to update the contents of some file I am serving I need to also update my web content. This would work, but also be frustrating. Would managing this actually be easier than just serving the file over https?
Chances are, you're updating a version number in the filename anyway. Especially if you're using http to allow for distributed http caches. I dunno, does anybody run those to reduce network use when they have a low bandwidth connection anymore?
See also universal SRI, which is sadly not making progress at this time. It’s possible that’s because embedding hashes in pages doesn’t scale properly in practice (as CSP nonces also seem to reflect).
Then you'd know that you're downloading the right malware?
You might like subresource integrity.
This exact mechanism is already used for linking scripts/stylesheets from third party websites.
Quiet discarding might not always be possible in a reasonable timeframe. You still have to get all the bytes to sha256 the payload, and so what? Do you expect the user to waste bandwidth and wait the check out? Often bandwidth and time both have costs attached.
It could still download it as normal, but show a warning at the end after it computes the hash and compares. Just like getting around a bad HTTPS cert, the browser could allow you to say "I know what I'm doing".
Edit: To clarify, I mean it could show the warning before the browser does the rename of the file from the temporary download file to the final filename.
Edit: To clarify, I mean it could show the warning before the browser does the rename of the file from the temporary download file to the final filename.
Considering EXEs specifically (entirely dismissing tarballs and such packages which can easily go up to several gigabytes), you cannot rely on everybody being able to download files in a reasonable time frame. I'm lucky to reside in a country that allows me to download hundreds of megabytes in double-digit seconds, alas that is not true for everybody else out there.
Have we yet constructed a hashing algorithm that maps the file left to right onto the hash in a way that’s provably correct at milestones other than “entire file only”?
If I could prove that the first 5% of a file is intact given the final hash, and repeat that proof continuously as the download proceeds, then it wouldn’t be wasteful.
IANAC
If I could prove that the first 5% of a file is intact given the final hash, and repeat that proof continuously as the download proceeds, then it wouldn’t be wasteful.
IANAC
The chaotic nature of hashing algorithms is desirable here because even a couple 'random' bytes changed in the assembly could yield drastically different computations. I don't think you can hash something without going through the whole blob.
Can we mathematically prove that, given
100% hash: 12344567
10% hash: 7251abed
That the 10% hash is a valid candidate for eventually becoming 12344567, assuming the other 90% checks out?
100% hash: 12344567
10% hash: 7251abed
That the 10% hash is a valid candidate for eventually becoming 12344567, assuming the other 90% checks out?
Not to my knowledge, no. I don't even think that you could do that with the most basic checksum algorithm.
Courtesy of Wikipedia on the matter, at the MD5 page:
Someone with more street cred on this matter, please correct me if I'm wrong!
EDIT: What about a "Hey, server! I'm 2MBs in, and I got hash blahblohblablablaaah; am I doing fine?" protocol? #terribleideas
Courtesy of Wikipedia on the matter, at the MD5 page:
MD5("The quick brown fox jumps over the lazy dog") =
9e107d9d372bb6826bd81d3542a419d6
MD5("The quick brown fox jumps over the lazy dog.") =
e4d909c290d0fb1ca068ffaddf22cbd0
Someone with more street cred on this matter, please correct me if I'm wrong!
EDIT: What about a "Hey, server! I'm 2MBs in, and I got hash blahblohblablablaaah; am I doing fine?" protocol? #terribleideas
You are correct that there is no such single hash; there can't be without it being longer, because then the parts could be brute forced separately.
However, a second hash of 10% of the file would work fine. You can even truncate it if saving a few bytes is that important (since you will check the full file hash later), although I suspect even a page with a bunch of downloads would be fine with a couple of extra hashes per file. While most APIs don't expose this possibility, most hash algorithms can spit out the full hash of the file up to any intermediary points with very little additional work. Or there could be seperate hashes for different blocks of data like P2P protocols do and store them all in a separate file on the https site.
However, the main issue is that these days it is very easy to just use https, most likely easier than any other solution. Browsers encouraging people to care by showing warnings should be very helpful in increasing the number of sites using https.
However, a second hash of 10% of the file would work fine. You can even truncate it if saving a few bytes is that important (since you will check the full file hash later), although I suspect even a page with a bunch of downloads would be fine with a couple of extra hashes per file. While most APIs don't expose this possibility, most hash algorithms can spit out the full hash of the file up to any intermediary points with very little additional work. Or there could be seperate hashes for different blocks of data like P2P protocols do and store them all in a separate file on the https site.
However, the main issue is that these days it is very easy to just use https, most likely easier than any other solution. Browsers encouraging people to care by showing warnings should be very helpful in increasing the number of sites using https.
Torrent files do that, a file is split into chunks each hashed separately.
That sounds like the Parchive index files that are popular on Usenet.
Yeah, you could use 20 hashes.
/s
/s
Why is that a bad idea? I mean, if you're downloading 1GB, your file is split into 1MB chunks, and each hash is 256 bits, that's only 32KB. I doubt anyone would complain about that.
That is exactly what bittorrent does, files are split into chunks and each one is hashed separately.
Years pass, we have sci-fi level technology, and the main method of distributing programs to users on Windows is still downloading .exes from random sites and being on the lookout for the browser toolbar trying to sneak by when installing. I don't know what's worse, this, or Google trying to wrestle yet another group of website owners into obedience.
Well, at least under Windows (and MacOS) you are still able to distribute your application using an installer which users can download from your own site, rather than being forced to use a centralized "app store". And policies like these are making this more difficult. However they won't stop shady sites which "re-bundle" open source applications and add spyware - those will have no problem getting an HTTPS certificate.
What would be a solution to that that wont end up giving 3rd parties practical control over what you can and cannot run in your own computer?
(the practical bit is because in theory you can blessed repositories/app stores that users can setup, but in practice this means that the vast majority of users will keep the default repositories and thus if you want your program to be used you'll need the permission of whoever owns these default repositories - ending up with a walled garden even if in theory the walls are low and you can jump over to other gardens)
(the practical bit is because in theory you can blessed repositories/app stores that users can setup, but in practice this means that the vast majority of users will keep the default repositories and thus if you want your program to be used you'll need the permission of whoever owns these default repositories - ending up with a walled garden even if in theory the walls are low and you can jump over to other gardens)
> $ man 5 exe
man: No entry for exe in section 5 of the manual.
Looks like I'm safe.
Though seriously, I don't see how this is going to stop people from getting infected. For a short time I did computer "repair" which was 99% removing malware/reinstalling Windows or fixing some silly configuration error the user made. One dude had downloaded 'jessia_alba_nude.exe' or something like that and infected his machine. I can totally see him following directions like "download jessica_alba_nude.jpg, rename to .exe, and double click to view" People are woefully ignorant and just want the carrot on the stick.
Looks like I'm safe.
Though seriously, I don't see how this is going to stop people from getting infected. For a short time I did computer "repair" which was 99% removing malware/reinstalling Windows or fixing some silly configuration error the user made. One dude had downloaded 'jessia_alba_nude.exe' or something like that and infected his machine. I can totally see him following directions like "download jessica_alba_nude.jpg, rename to .exe, and double click to view" People are woefully ignorant and just want the carrot on the stick.
Fun fact: https is a great way to mask your malware payload from filtering proxies. So now corporate laptops have client-side HTTPS filtering, which have really stupid filter rules that break existing valid use cases of downloading files. So the users then turn the filters off, and now all the malware gets through. Yay https! We may not be secure, but we've got privacy, damn it!