1877195 - Expand mixed-content download protection to all http downloads

Status: REOPENED

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

Description

[Christoph Kerschbaumer [:ckerschb}]

Within Bug 1614969 we started to block insecure (http) downloads on secure (https) pages. We should consider to expand our protection mechanism and start to warn generally for all http downloads, not only mixed content downloads.

Since we have the overrule mechanism which allows an end user to overrule the decision of Firefox, I suppose we just have to remove the mixed-content pre-condition.

Comment 1

[Christoph Kerschbaumer [:ckerschb}]

Attachment: Bug 1877195: Expand mixed-content download protection to all http downloads, r=freddyb,gijs

Comment 2

[Christoph Kerschbaumer [:ckerschb}]

FWIW, I filed a content review request (https://mozilla-hub.atlassian.net/browse/UXREQ-171) to get some support for the two strings we are updating.

Comment 3

[Christoph Kerschbaumer [:ckerschb}]

I have updated the patch to re purpose the pref dom.block_download_insecure. Here is the TRY run:
https://treeherder.mozilla.org/jobs?repo=try&revision=fa4955d59619a63ffc6bf1fc65522aa09c719d2b

Comment 4

[Christoph Kerschbaumer [:ckerschb}]

https://treeherder.mozilla.org/jobs?repo=try&revision=c696c5bce96fb8cd7a69bc6396cbc00414834613

Comment 5

[Christoph Kerschbaumer [:ckerschb}]

Attachment: data_review_request.txt

Comment 6

[Chris H-C :chutten]

Comment on attachment 9381008 [details]
data_review_request.txt

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

No. This collection will expire in six months.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.

---

Result: datareview+

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81bb704a27a1
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz

Comment 8

[Iulian Moraru]

Backed out for causing wpt failures on iframe_sandbox_navigation_download_allow_downloads.sub.tentative.html.

• Push with failures

• Failure log

• Backout link

Comment 9

[Christoph Kerschbaumer [:ckerschb}]

Freddy and I agreed to rewrite the wpt-test name to include https so the test runs relying on https rather than http.
In particular we renamed
iframe_sandbox_navigation_download_allow_downloads.sub.tentative.html to
iframe_sandbox_navigation_download_allow_downloads.sub.tentative.https.html

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a89ec49d7645
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44899 for changes under testing/web-platform/tests

Comment 12

[Christoph Kerschbaumer [:ckerschb}]

Release Note Request (optional, but appreciated)

[Why is this notable]:
We are expanding our download protection. Previously we blocked mixed content downloads. More precisely we blocked http downloads in https pages. Now we are expanding our download protection to block all downloads that do not rely on a potentially trustworthy URI. In practice and in most cases this translates to http downloads. FWIW, we initially block the load though offer the end user an option to overrule the decision of Firefox and allow the download to proceed.

[Suggested wording]:
Firefox expands download protection and initially blocks downloads relying URLs that are considered non potentially trustworthy.

[Links (documentation, blog post, etc)]:
We have and old blogpost, from the previous download protection: https://blog.mozilla.org/security/2021/10/05/firefox-93-protects-against-insecure-downloads/

Comment 13

[Sandor Molnar[:smolnar]]

Backed out for causing wpt failures @ the-iframe-element/iframe_sandbox_window_open_download_allow_downloads.tentative.html

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

Push with failures

Failure log -> TEST-UNEXPECTED-TIMEOUT | /html/semantics/embedded-content/the-iframe-element/iframe_sandbox_window_open_download_allow_downloads.tentative.html

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 15

[Christoph Kerschbaumer [:ckerschb}]

(In reply to Sandor Molnar[:smolnar] from comment #13)

Backed out for causing wpt failures @ the-iframe-element/iframe_sandbox_window_open_download_allow_downloads.tentative.html

Similar to comment 8, I fixed the problem by letting run the WPT test in question over https. In particular, I renamed
frame_sandbox_window_open_download_allow_downloads.tentative.html to
frame_sandbox_window_open_download_allow_downloads.tentative.https.html

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/20b5e4b2f448
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz

Comment 17

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/20b5e4b2f448

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx125 relnotes with some wording tweaks.

Firefox has expanded its download protection and now more proactively blocks downloads from URLs that are considered to be potentially untrustworthy.

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45784 for changes under testing/web-platform/tests

Comment 22

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out from autoland for breaking HTTP downloads:
https://hg.mozilla.org/integration/autoland/rev/6eb683460ad916c19b9925c30623c189c97e1f96

Comment 23

[Donal Meehan [:dmeehan]]

Backed out from mozilla-beta for breaking HTTP downloads:
https://hg.mozilla.org/releases/mozilla-beta/rev/86264e764b29445c4ae1d6b94b5354bd6d60f21e

Comment 24

[Ryan VanderMeulen [:RyanVM]]

And backed out from Release for Desktop 125.0.2 / Android 125.2.0 also.
https://hg.mozilla.org/releases/mozilla-release/rev/3840c3f2730f33a33f4325c30eddcf53ad23a48d

Comment 25

[Serban Stanca [:SerbanS]]

Backout merged to central : https://hg.mozilla.org/mozilla-central/rev/6eb683460ad916c19b9925c30623c189c97e1f96

Comment 26

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 27

[Christoph Kerschbaumer [:ckerschb}]

Thanks Aryx for backing it out. I guess we need to resolve the general download machinery issues and then we can tackle this bug again. Though I am on it.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

This should also go through more extensive QA when it re-lands. Please reach out to Tania or Tracy if you need help navigating the process for requesting that.

Comment 30

[Christoph Kerschbaumer [:ckerschb}]

Marking this Bug as dependent of Bug 1892069, because only once we have fixed our download manager we can-reconsider landing this Bug.

FWIW, we also need to ensure we integrate the RFC1918 exception mentioned within Bug 1892011 before re-landing.

Comment 31

[Christoph Kerschbaumer [:ckerschb}]

After re-discussing this feature during our HTTPS Adoption Strategy we decided to de-prioritize this download security enhancement and focus on other HTTPS adoption features.

In case we pick this up again, we should ensure:
(a) The POST/GET download problems form Bug 1892069 are resolved.
(b) We incorporate the RFC1918 carve-outs as discussed within Bug 1892011
(c) Eliminate user annoyance. E.g. remember the triggering origin when a user clicks 'allow download'. We could store that such information in the permission manager. Whenever a user then downloads something over HTTP from that same website (triggering origin/triggeringPrincipal), then the download would be allowed without Firefox interfering/blocking the download initially and having the end user to click the allow download exception.