I think we should start warning about mixed content downloads and eventually start blocking mixed insecure downloads.

I proposed this 4 years ago.
Chrome is now implementing this in version 82.
https://www.theverge.com/2020/2/10/21132099/google-chrome-users-block-insecure-downloads-https-android-ios

Depends on D67351

Backout link: https://hg.mozilla.org/integration/autoland/rev/70c5a2c012c9200328b64295c84d8e51cc9a96e7

Can we have a preference to allow this? I thought Mozilla was supposed to be about empowering the user!

Hi! :) - My current patch adds a preference for that, for you to toggle.
Its dom.block_download_insecure and it's off by default for everyone except on nightly.

Sorry I missed that great idea to block by default though.

Backed out for build bustages.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=a10fc7b299ffd18d631962200447a5a47ee0b930&selectedTaskRun=GF6BhwmzQBeG5TwVDAyu1A.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307349752&repo=autoland&lineNumber=25116

Backout: https://hg.mozilla.org/integration/autoland/rev/dcf0f9b8d89da9d20c0bfc7bed4613df0d880922

Fixed the bustage, sorry about that.

Backedfor asertion failure on base/LoadInfo.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/73bbbedc0d59b1ec6367ff9958eafb93aa375933

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=Jhkq447lQrOTbNLk9CBtuw.0&revision=2df0c2a2f8662b3ed42c71673a83a2967a87b352&searchStr=bc

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308056098&repo=autoland&lineNumber=41392

Sorry,
Fixed the assertion, got a green try push now - https://treeherder.mozilla.org/#/jobs?repo=try&revision=0b0586d584c4527f46f23e49ef2aff28b12d80b5

https://hg.mozilla.org/mozilla-central/rev/2b1b3a41c110

Sebastian, could you please tell me how the latest Nightly 80.0a1 should behave if the mixed content download is made via drag and drop?

For instance, if I try to download a file from https://www.thinkbroadband.com/download by clicking on it, then the download is blocked (as the Opening dialog is never displayed). But if I drag the same file over the Downloads icon in the Navigation bar, then the download is completed. Is this expected?

Thanks!

Hey ! - :)
From my "user-perspective" i would argue that this is a bug. We should with our block rules be consistent.
From the tec side it's kind of expected as dropping a link onto the download button creates a new channel without the context of the original page.

Not connected - Just a note to the bug itself.
Mixed Content Download Blocking weill be staying as nightly only - until we have a better ux to communicate the blocking

Can we consider backing this out? The user has no idea why the download fails. I don't see how to current implementation is acceptable for Nightly users.

I'm just a user so it's not my call but would it make more sense to keep this but with dom.block_download_insecure defaulting to false (to be flipped to true at a future date)? The feature works, the problem is there's no UX so if you didn't explicitly enable it yourself you have no idea why downloads aren't working.

Please note that the mixed content blocking of downloads is currently enabled in Nightly only. I personally would prefer not to back this patch out, but I agree that we have to improve the user experience before this is ready for release.

Basti is currently working on improving the experience for end users when Firefox blocks insecure downloads.

@Basti, can you link to the right bugs here as well please?

(In reply to Christoph Kerschbaumer [:ckerschb, back on Aug 24th] from comment #20)

Please note that the mixed content blocking of downloads is currently enabled in Nightly only. I personally would prefer not to back this patch out, but I agree that we have to improve the user experience before this is ready for release.

Basti is currently working on improving the experience for end users when Firefox blocks insecure downloads.

@Basti, can you link to the right bugs here as well please?

FYI, a webcompat/archlinux bug couple caused by the lacking UX around this change: https://bugs.archlinux.org/task/67587 / https://github.com/webcompat/web-bugs/issues/56727 . Hope the UX improves soon, the silent blocking is very confusing.

I am going to remove the needinfo request. Bug 1656296 should solve this!