Re: Blocking high-risk non-secure downloads

Not sure there can be a false positive about a http download from a https page!

Can you give an example of how blocking such a download could cause a problem?

Cheers,

Scott.
________________________________
From: Michaela Merz <michaela.merz@rollofone.com>
Sent: 09 April 2019 20:43
To: Emily Stark
Cc: WebAppSec WG; Mike West; Joe DeBlasio; cthomp@chromium.org
Subject: Re: Blocking high-risk non-secure downloads


Hi Emily -

I wasn't really talking about my particular problem. It is simply an example about a false positive that may also happen in other protection environments. I personally find the blocking of any kind of download extremely problematic - especially if the user doesn't know about it. In-transparent blocking - even with the best intensions - opens the door to all sorts of desires.

Just my two cents.

Michaela

On 4/9/19 2:36 PM, Emily Stark wrote:


On Tue, Apr 9, 2019 at 12:31 PM Michaela Merz <michaela.merz@rollofone.com<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrbug.com%2Fnew&data=02%7C01%7C%7C01943c48bef54ae45c8b08d6bd23d4a5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636904358914824122&sdata=yrC28huVCKwL0eBo0M4YnJ86Jxbe9mMRDiDtiO%2B94P8%3D&reserved=0> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.android.com%2Fsecurity%2Freports%2FGoogle_Android_Security_2018_Report_Final.pdf&data=02%7C01%7C%7C01943c48bef54ae45c8b08d6bd23d4a5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636904358914834127&sdata=p1dJ31a67mXnuuxCHt30o29TJ8jWLlK84n6J%2BurZPIQ%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

--
Email is unsafe. Send confidential text or data via
packfrog: https://packfrog.com/biotope?ee=92d26b3152b13a508b88d5ee575143b<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackfrog.com%2Fbiotope%3Fee%3D92d26b3152b13a508b88d5ee575143b&data=02%7C01%7C%7C01943c48bef54ae45c8b08d6bd23d4a5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636904358914844139&sdata=Pg22fOnzEQRBr0Jgdpg0%2Bcc%2F10FjyaLp0XVP8ceWqXI%3D&reserved=0>

--
Email is unsafe. Send confidential text or data via
packfrog: https://packfrog.com/biotope?ee=92d26b3152b13a508b88d5ee575143b<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackfrog.com%2Fbiotope%3Fee%3D92d26b3152b13a508b88d5ee575143b&data=02%7C01%7C%7C01943c48bef54ae45c8b08d6bd23d4a5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636904358914854156&sdata=18WoqeljIqKSDEUEsUvJFzcWupL9nonsTD%2Fu72%2FLOm4%3D&reserved=0>