Re: Blocking high-risk non-secure downloads

Scott:

I may have misunderstood the suggestion. I am sorry. You are talking
about blocking HTTP downloads from within secure contexts? This is NOT
about blocking downloads based on signatures or other protection
mechanisms? If so - I bow out as I have spoken too early. My apologies.


Michaela


On 4/9/19 2:47 PM, Scott Helme wrote:
> 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>

-- 
Email is unsafe. Send confidential text or data via
packfrog: https://packfrog.com/biotope?ee=92d26b3152b13a508b88d5ee575143b