1685479 - Let Mixed Content Download Blocking ride the trains

Status: VERIFIED FIXED

(Core :: DOM: Security, enhancement)

Description

[Sebastian Streich [:sstreich]]

Its currently nightly only, let it ride the trains :)

Comment 1

[Sebastian Streich [:sstreich]]

Attachment: Bug 1685479 - Flip pref dom.block_download_insecure r=ckerschb

Comment 2

[Justin Peter]

I ran into this on nightly while downloading something a couple days ago, and I was wondering if there was any chance Firefox could try downloading over https before blocking the download. Simply changing the protocol worked for me, but I doubt most non-technical users would understand enough to do that.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Justin Peter from comment #2)

I ran into this on nightly while downloading something a couple days ago, and I was wondering if there was any chance Firefox could try downloading over https before blocking the download. Simply changing the protocol worked for me, but I doubt most non-technical users would understand enough to do that.

We are working on auto-upgrading recources from http to https, it's not on by default as of now, but you could enable https-only mode which upgrades all resources to https, see https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/

Comment 4

[Romain Testard [:RT]]

Mike, is this something that would require an enterprise policy?

Comment 5

[Justin Peter]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #3)

(In reply to Justin Peter from comment #2)

I ran into this on nightly while downloading something a couple days ago, and I was wondering if there was any chance Firefox could try downloading over https before blocking the download. Simply changing the protocol worked for me, but I doubt most non-technical users would understand enough to do that.

We are working on auto-upgrading recources from http to https, it's not on by default as of now, but you could enable https-only mode which upgrades all resources to https, see https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/

Yes, I am familiar with both https-only and https-first modes. (It looks like bug 1704453 is the bug for the latter?)

My thought was that it might be a better user experience if https-first could in some way be enabled with this, or at least for downloads. I have no idea of the exact numbers (I don't know if there's an easy way via telemetry to tell if a download blocked due to this is also available via https), but this caught me off-guard a few days ago when I was downloading something from a link to microsoft.com, and it took me a second of wondering if I had run across some safe browsing blacklist or something before I tried changing the protocol to https, and it worked.

That's a rather long-winded way of saying: I bet in a significant portion of cases (potentially a majority) you could improve security while also scaring/confusing non-technical users less by silently upgrading the connection.

Actually: this specifically mentions mixed content, am I correct in taking that to mean an http download linked from an https page? In that case, I would say that almost certainly a significant majority would also be available via https.

Comment 6

[Justin Peter]

(In reply to Justin Peter from comment #5)

it took me a second of wondering if I had run across some safe browsing blacklist or something

Oh hey that's bug 1701810.

Comment 7

[Mike Kaply [:mkaply]]

The Chrome policy has the ability to do it per URL:

From:

https://blog.chromium.org/2020/02/protecting-users-from-insecure.html

"Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download."

As well as setting a default to always block:

https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#defaultinsecurecontentsetting

Do we have any ability to enable this on a per URL basis?

Comment 8

[Sebastian Streich [:sstreich]]

Do we have any ability to enable this on a per URL basis?

Currently there is no option to allow/block on a per URL basis.

Comment 9

[Mike Kaply [:mkaply]]

All dom. prefs are settable via policy, so I think we're ok on this for now.

If we feel it needs its own policy, we can revisit.

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

Leaving this as a placeholder for now. I'll update once we get closer to the release, the high level overview is that we will start blocking mixed content downloads.

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]:
[Suggested wording]:
[Links (documentation, blog post, etc)]:

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0bee3935efcb
Flip pref dom.block_download_insecure r=Gijs

Comment 12

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/0bee3935efcb

Comment 13

[Pascal Chevrel:pascalc]

(In reply to Christoph Kerschbaumer [:ckerschb, back on Sept. 13th] from comment #10)

Leaving this as a placeholder for now. I'll update once we get closer to the release, the high level overview is that we will start blocking mixed content downloads.

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]:
[Suggested wording]:

Can we have the wording now for our Beta release notes? Thanks

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Pascal Chevrel:pascalc from comment #13)

Release Note Request (optional, but appreciated)
[Why is this notable]:

Protects users against insecure downloads

[Affects Firefox for Android]:

No

[Suggested wording]:

Insecure Download Protection: Firefox now protects against insecure downloads by blocking downloads relying on insecure connections.

Comment 15

[Alin Ilea, Desktop QA]

Hello,
We managed to finish the Mixed Content Downloads Blocking spot-check in Beta 93, as requested, using the following OS-es: Windows 10, Ubuntu 20 and macOS 10.15.
There were no issues encountered. The spot-check was performed around this bug and its dependencies. Also we covered the interaction of the Mixed Content Downloads Blocking feature with HTTPS-First Mode and HTTPS-Only Mode features, both in normal and private browsing. An exploratory and regression testing was also part of our testing, to ensure that the non-mixed content downloads and other related areas are still working as expected.
Based on the details above, I will mark this as verified.
Thanks.