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 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
>
-- 
Email is unsafe. Send confidential text or data via
packfrog: https://packfrog.com/biotope?ee=92d26b3152b13a508b88d5ee575143b