Re: Blocking high-risk non-secure downloads

On Tue, Apr 9, 2019 at 12:31 PM Michaela Merz <michaela.merz@rollofone.com>
wrote:

> Here's a very problematic situation I am discussing with the Firebox
> people (and filed a bug report): Our application allows folks to assemble
> files, pack them into a zip and download the data. Some combination of
> certain files, when packed and zipped, seem to create a situation where
> Chromium (and Firefox) believe the data to be dangerous. I guess it's based
> on the signature. Chromium marks the download as potentially dangerous but
> allows the download anyway - Firefox however downloads the file and
> zero-truncates it on disk without any warning. Here's my point: The browser
> should never be allowed to discard or corrupt any data without the user's
> expressed knowledge. It is not enough to only have a tick-box in settings.
> Warnings need to be displayed on any potentially dangerous file. It is not
> acceptable when the browser decides by itself whether or not do allow
> downloads and doesn't tell the user. Signatures or other detection
> mechanism can (and as my case shows, will) deliver false positives and it's
> creating a slippery slope that may, at some point, be misused for other
> reasons. It is however - perfectly ok to warn the user and let him/her
> decide for themselves.
>

Hi Michaela, this sounds like an issue with the Safe Browsing download
protection feature, which is unrelated to blocking http downloads which
we're discussing in this thread. Please consider filing a bug at
https://crbug.com/new about this issue.


> Michaela
> On 4/9/19 1:28 PM, Emily Stark wrote:
>
> Hi webappsec friends,
>
> 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.
>
> We want to achieve the right balance between compatibility/user-disruption
> and security improvements, so we will likely start by treating certain
> high-risk downloads initiated from secure contexts as active mixed content
> and block them. We're still finalizing our metrics before we can share them
> publicly, but right now it's looking like it will be feasible to block a
> set of high-risk filetypes (executables and archives as determined by the
> Content-Type header or sniffed mime-type). We will likely focus on
> protecting desktop users because Android and Safe Browsing already provide
> protection
> <https://source.android.com/security/reports/Google_Android_Security_2018_Report_Final.pdf>
> against malicious APKs.
>
> 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.
>
> Feedback welcome!
> Thanks,
> Emily
>
> --
> Email is unsafe. Send confidential text or data via
> packfrog: https://packfrog.com/biotope?ee=92d26b3152b13a508b88d5ee575143b
>
>