W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2019

Re: Blocking high-risk non-secure downloads

From: Emily Stark <estark@google.com>
Date: Tue, 9 Apr 2019 12:36:17 -0700
Message-ID: <CAPP_2SaUtYninUs+GUXuOT=KQYKYuExamuMFoXwHyeOgHWxUsg@mail.gmail.com>
To: Michaela Merz <michaela.merz@rollofone.com>
Cc: WebAppSec WG <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Joe DeBlasio <jdeblasio@chromium.org>, cthomp@chromium.org
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
>
>
Received on Tuesday, 9 April 2019 19:36:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 April 2019 19:36:55 UTC