Re: Blocking high-risk non-secure downloads

We are looking at exes, dmgs, and crxs as executables, and
zip/gzip/rar/tar/bzip/etc. as archives. You can see how our current metrics
are classifying mime types here
<https://cs.chromium.org/chromium/src/components/download/internal/common/download_stats.cc?sq=package:chromium&g=0&l=718>
.

On Tue, Apr 9, 2019 at 12:21 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> Emily – can you give some idea of the list of filetypes that you would
> thinking of blocking?
>
>
>
> Leonard
>
>
>
> *From: *Emily Stark <estark@google.com>
> *Date: *Tuesday, April 9, 2019 at 11:30 AM
> *To: *WebAppSec WG <public-webappsec@w3.org>
> *Cc: *Mike West <mkwst@google.com>, Joe DeBlasio <jdeblasio@chromium.org>,
> "cthomp@chromium.org" <cthomp@chromium.org>
> *Subject: *Blocking high-risk non-secure downloads
> *Resent-From: *<public-webappsec@w3.org>
> *Resent-Date: *Tuesday, April 9, 2019 at 11:29 AM
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.android.com%2Fsecurity%2Freports%2FGoogle_Android_Security_2018_Report_Final.pdf&data=02%7C01%7Clrosenth%40adobe.com%7Cefa52096384c4a60b59808d6bd197188%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636904314310205375&sdata=yDpr%2BhdTCLweZQqho5qHzDfLcUWwZ9R%2Fcns9oU%2BAz8Q%3D&reserved=0>
> 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
>