Open Bug 1877195 Opened 4 months ago Updated 20 days ago

Expand mixed-content download protection to all http downloads

Categories

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

enhancement

Tracking

()

REOPENED
Tracking Status
firefox125 --- wontfix
firefox126 --- wontfix
firefox127 --- affected

People

(Reporter: ckerschb, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: parity-chrome, Whiteboard: [domsecurity-backlog1], [wptsync upstream])

Attachments

(1 file, 1 obsolete file)

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.

Assignee: nobody → ckerschb
Severity: -- → N/A
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [domsecurity-active]

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.

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

Attachment #9381008 - Flags: data-review?(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+

Attachment #9381008 - Flags: data-review?(chutten) → data-review+
Blocks: 1303739
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/81bb704a27a1
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz

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

Flags: needinfo?(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

Flags: needinfo?(ckerschb)
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a89ec49d7645
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44899 for changes under testing/web-platform/tests
Whiteboard: [domsecurity-active] → [domsecurity-active], [wptsync upstream]

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/

relnote-firefox: --- → ?
Upstream PR was closed without merging

(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

Flags: needinfo?(ckerschb)
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/20b5e4b2f448
Expand mixed-content download protection to all http downloads, r=freddyb,Gijs,anti-tracking-reviewers,pbz
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
Upstream PR merged by moz-wptsync-bot

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.

Duplicate of this bug: 1303739
Regressions: 1892011
Regressions: 1892069
See Also: → 1892115
Regressions: 1892115
See Also: 1892115
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45784 for changes under testing/web-platform/tests

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 125 Branch → ---
Upstream PR merged by moz-wptsync-bot

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.

Flags: needinfo?(ckerschb)

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.

No longer blocks: 1303739
See Also: → 1614969
Duplicate of this bug: 1892011

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.

Depends on: 1892069

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.

Assignee: ckerschb → nobody
Priority: P2 → P5
Whiteboard: [domsecurity-active], [wptsync upstream] → [domsecurity-backlog1], [wptsync upstream]
No longer regressions: 1892069
Attachment #9377578 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: