Re: Blocking high-risk non-secure downloads

On Thu, Apr 11, 2019 at 7:26 PM Yan Zhu <yan@brave.com> wrote:

> On Tue, Apr 9, 2019 at 11:30 AM Emily Stark <estark@google.com> 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.
>
> Hi Emily! Brave Desktop tries to address this issue by showing the
> origin of the download in the downloads bar at the bottom of the
> browser and a little red insecure icon next to HTTP. Our designers are
> not a fan of this approach since it adds ~10px to the download bar
> height and looks a bit cluttered :). Screenshot attached.
>

Yep, we've considered an approach like this, but as I just mentioned in my
reply to Dev, we're not confident that anyone would actually notice or
understand it, and we don't want to have a proliferation of confusing http
warnings. This is probably a place where a different design decision makes
sense for Brave vs Chrome due to differences in user base; I'd expect Brave
users to be more technically savvy on average.


>
> >
> > 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 against malicious APKs.
> >
>
> I think this is a good idea in terms of user safety but more
> questionable in terms of the incentives for developers to migrate to
> HTTPS, as Dev stated. If Chromium has a heuristic for high-risk
> filetypes, Brave would strongly consider blocking files matching that
> heuristic over HTTP regardless of the context.
>

See my reply to Dev about incentives for migrating.

On a somewhat philosophical note, I'll also say that personally, I think
HTTPS adoption has progressed to the point where we can slightly back off
on making it as easy as possible to migrate, and start pushing more on the
quality of HTTPS deployments. (See also the mixed content autoupgrading
experiment <https://chromestatus.com/feature/5557268741357568> we're
running.) There's no point moving everyone to HTTPS if it has holes
everywhere, and I think now is the time to start thinking about closing
some of the holes.


>
> > 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
>