
Blocking high-risk non-secure downloads - slim
http://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html
======
chainsaw10
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.

~~~
gambler
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.

~~~
bigj0n
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.

~~~
gambler
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.

~~~
ehutch79
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?

~~~
Crinus
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.

------
grezql
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.

~~~
floatingatoll
Google found a threat model where attackers inject [http://](http://) .exe
links into [https://](https://) web pages. This exposes a flaw in mixed-
content handling, where web pages don’t allow [http://](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://](http://) sites can link [http://](http://)
executables, but [https://](https://) sites cannot.

~~~
mfoy_
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
A properly behaving site would not. One hacked by malware distributors could.

~~~
kemitche
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_
Why? Why not serve the ISO over HTTPS?

~~~
sneak
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.

------
billpg
What if this was allowed: (Please excuse non-angle brackets.)

[A
HREF="[http://example.com/SomeProgram.exe"](http://example.com/SomeProgram.exe")
ExpectedSha256="..."]Download[/A]

If clicked, the download is checked and is quietly discarded if the hash is
wrong.

~~~
grenoire
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.

~~~
floatingatoll
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

~~~
everfree
Yeah, you could use 20 hashes.

/s

~~~
giornogiovanna
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.

------
peterwwillis
Malware authors are all already moving their payloads to https sites, so this
will be useful for about a year until it's been worked around.

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!

------
maccard
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](https://trustedsite.com),
and they link to [http://trustedsitesortof.com](http://trustedsitesortof.com),
my browser should warn me.

~~~
Crinus
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.

------
lightedman
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.

~~~
maccard
Yes it should - if I'm on [https://trustedsite.com](https://trustedsite.com)
and they link to
[http://notsotrustedsite.com/someexe.exe](http://notsotrustedsite.com/someexe.exe)
you are vulnerable.

~~~
gpm
Linking from [https://trustedsite.com](https://trustedsite.com) to
[https://nottustedsite.com/someexe.exe](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.

------
nukeop
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.

~~~
rob74
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.

------
MisterTea
> $ 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.

