Re: Blocking high-risk non-secure downloads

Hi

I realize the question was directed towards other browser vendors but I
figured its on webappsec so I will chime in :)

It is a bit weird that the platform will continue allowing http downloads
from an http page; but not http download from an https page. If the https
page includes a hash/fingerprint of the download and asks users to check
it, you can imagine a world where this is a secure flow. Especially, if we
can add support for downloads in SRI
<https://github.com/w3c/webappsec-subresource-integrity/issues/68>. In
contrast, there is no way for the http download from http pages to be safe.

Now, that might be fine---something is better than nothing. My worry though
is that this could add more roadblocks for people trying to migrate to
https. Further, if the download is really on a different server that
doesn't even support HTTP (for whatever reason), then I also think a
security engineer's time is better spent getting some sort of integrity
check/verification than trying to get that page to support HTTPS.

Has Chrome considered blocking HTTP downloads on HTTP pages first?

--dev


On Tue, Apr 9, 2019, 2:00 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Tue, Apr 9, 2019 at 11:30 AM Emily Stark <estark@google.com> wrote:
>
>> Over in Chrome land, we've been considering how to drive down non-secure
>> downloads, particularly high-risk ones like executables. I wanted to see if
>> other browsers would be interested in joining us on this adventure.
>>
>
> I would be very happy to push in this direction, limited by the amount of
> breakage and user-pushback we can expect. Any statistics you can share
> would be a huge help. Insecure downloads from the secure sites of companies
> who ought to know better are distressingly common ("but the executables are
> signed!").
> -Dan Veditz
>