1614969 - Consider blocking mixed content downloads

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement, P3)

Description

[Christoph Kerschbaumer [:ckerschb]]

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

Comment 1

[Eldmannen]

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

Comment 2

[Sebastian Streich [:sstreich]]

Attachment: Bug 1614969 - Check download with MixedContentBlocker r=ckerschb

Depends on D67351

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3685f83e0dc0
Check download with MixedContentBlocker r=ckerschb

Comment 4

[Atila Butkovits]

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

Comment 5

[mac198442]

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

Comment 6

[Sebastian Streich [:sstreich]]

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.

Comment 7

[mac198442]

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

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a10fc7b299ff
Check download with MixedContentBlocker r=ckerschb

Comment 9

[Razvan Maries]

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

Comment 10

[Sebastian Streich [:sstreich]]

Fixed the bustage, sorry about that.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2df0c2a2f866
Check download with MixedContentBlocker r=ckerschb

Comment 12

[Atila Butkovits]

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

Comment 13

[Sebastian Streich [:sstreich]]

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

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b1b3a41c110
Check download with MixedContentBlocker r=ckerschb

Comment 15

[Dorel Luca [:dluca]]

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

Comment 16

[Simona Badau, Desktop QA]

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!

Comment 17

[Sebastian Streich [:sstreich]]

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

Comment 18

[Tom S [:evilpie]]

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.

Comment 19

[Aidan Harris]

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.

Comment 20

[Christoph Kerschbaumer [:ckerschb]]

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?

Comment 21

[Ronan Jouchet]

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

Comment 22

[Tom S [:evilpie]]

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