Closed Bug 1672106 Opened 4 years ago Closed 2 years ago

Experiment auto upgrading passive mixed content in nightly/beta

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
108 Branch
Tracking Status
firefox108 --- disabled
firefox109 --- disabled
firefox110 --- fixed

People

(Reporter: ckerschb, Assigned: t.yavor)

References

(Depends on 2 open bugs, Blocks 2 open bugs, Regressed 1 open bug)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(2 files, 1 obsolete file)

Within Bug 1633743 we are considering auto upgrading in Nightly, this one is meant for release.

Depends on: 1674727
Blocks: 1447011
Depends on: 1695173
Depends on: 1703847

Are there any plans to ship this? It's been shipping in Chrome for >6 months now.

(In reply to estark37 from comment #1)

Are there any plans to ship this? It's been shipping in Chrome for >6 months now.

Hey Emily, thanks for reaching out. There are no real plans to ship mixed content auto upgrading at this point - for now we are going to disable even in Nightly (see Bug 1703847). It's on our radar though and we keep evaluating pros and cons.

Assignee: ckerschb → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]

This is now breaking images on ASUS's site, and users are noticing the "insecurity" of Samsung sites but thinking it's a Firefox issue. I think we should revisit this before it becomes a webcompat issue too big for us to ignore.

Flags: needinfo?(dveditz)

This is going to be a topic at TPAC 2022. I'm not sure why we backed off of it even in Nightly (e.g. bug 1703847). Possibly because we thought "HTTPS-only" would be a better (more secure) solution? But that breaks enough stuff that it requires some fiddly UI bits so users can override and therefore is likely to remain "opt-in". We should reconsider doing this.

can't needinfo Christoph so I'll assign it to him for re-triage :-)

Assignee: nobody → ckerschb
Flags: needinfo?(dveditz)
Whiteboard: [domsecurity-backlog1]

Currently security.mixed_content.block_display_content is set to false but I agree, we should enable this feature in Nightly again. We are definitely interesting in shipping this eventually.

Tom I think we are interested in investing in this feature. Is this something you are interested in?

Assignee: ckerschb → nobody
Flags: needinfo?(tschuster)
Whiteboard: [domsecurity-backlog1]

Looks like this is basically "mixed content level 2"?

Blocks: 1779757

(In reply to Frederik Braun [:freddy] from comment #9)

Looks like this is basically "mixed content level 2"?

Correction, security.mixed_content.upgrade_display_content is level 2.

Assignee: nobody → tschuster
Flags: needinfo?(tschuster)

Hi Tomer! Freddy said you would probably be looking into shipping mixed content blocking.

Assignee: tschuster → nobody
Flags: needinfo?(lyavor)

Kind of.
security.mixed_content.upgrade_display_content seems like mixed content level 2.
Only thing differs for now is that the flag is upgrading also same-host iframes and scripts which is not included in mixed content level 2 (since these are active subresources).

Flags: needinfo?(lyavor)
Assignee: nobody → lyavor
Status: NEW → ASSIGNED
Attachment #9298364 - Attachment description: Bug 1672106 - Consider auto upgrading passive mixed content in Release r=freddyb → WIP: Bug 1672106 - Consider auto upgrading passive mixed content in Release r=freddyb
Attachment #9298364 - Attachment description: WIP: Bug 1672106 - Consider auto upgrading passive mixed content in Release r=freddyb → Bug 1672106 - Consider auto upgrading passive mixed content in Release r=freddyb
Attachment #9298364 - Attachment description: Bug 1672106 - Consider auto upgrading passive mixed content in Release r=freddyb → Bug 1672106 - future-proofing tests for upgrading passive mixed content & HTTPS-only r=freddyb
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bf2033f42e0f
future-proofing tests for upgrading passive mixed content & HTTPS-only r=freddyb
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

The landed patch is test-only. Is this bug really fixed?

@Tomer: If this was the last test case needing a fix, please flip the pref for nightly and early beta.

Status: RESOLVED → REOPENED
Flags: needinfo?(lyavor)
Keywords: leave-open
Resolution: FIXED → ---
Summary: Consider auto upgrading passive mixed content in Release → Experiment auto upgrading passive mixed content in nightly/beta
Attachment #9301282 - Attachment description: Bug 1672106 - Flip pref for mixed content level 2 in beta and nightly. r=freddyb → Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb
Flags: needinfo?(lyavor)
Attachment #9301282 - Attachment description: Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb → Bug 1672106 - Flip pref for mixed content level 2 in beta and nightly. r=freddyb
Attachment #9301282 - Attachment description: Bug 1672106 - Flip pref for mixed content level 2 in beta and nightly. r=freddyb → Bug 1672106 - Enable mixed content level 2 in nightly. r=freddyb
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/33c1077876b0
Enable mixed content level 2 in nightly. r=freddyb

Backed out for causing wpt failures on element-audio.https.sub.html

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | /fetch/metadata/generated/element-audio.https.sub.html | sec-fetch-site - HTTPS downgrade-upgrade, no attributes - promise_test: Unhandled rejection with value: object "Error: Failed to query for recorded headers."
Flags: needinfo?(lyavor)

I somehow missed that.
But actually it seems like a normal site effect of Mixed content level 2.

I have to take some more time to understand the failing subtest.

Flags: needinfo?(lyavor)
Attachment #9301282 - Attachment description: Bug 1672106 - Enable mixed content level 2 in nightly. r=freddyb → Bug 1672106 - Flip pref for mixed content level 2 in beta and nightly. r=freddyb
Attachment #9301282 - Attachment description: Bug 1672106 - Flip pref for mixed content level 2 in beta and nightly. r=freddyb → Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb
Attachment #9304696 - Attachment is obsolete: true
Attachment #9301282 - Attachment description: Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb → WIP: Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb
Attachment #9301282 - Attachment description: WIP: Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb → Bug 1672106 - enable mixed content level 2 in beta and nightly. r=freddyb
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/941f7fe27b76
enable mixed content level 2 in beta and nightly. r=freddyb

Backed out for causing causing mochitest failures on browser_103_preload.js

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | netwerk/test/browser/browser_103_preload.js | test_103_preload_insecure_cor: unexpected amount of normal request made expected 1 ({"hinted":0,"normal":1}), got 0 ({"hinted":0,"normal":0}) - false == true - JS frame :: resource://testing-common/early_hint_preload_test_helper.jsm :: request_count_checking :: line 34
Flags: needinfo?(lyavor)

I looked into the new failure. The latest try push was apparently not uplifted since December 3rd and thus a new test wasn't caught. The test requires loading images over HTTP and HTTPS, which is behavior that we are changing with this patch.

Given that the new test for early-hints does not require and is not written with Mixed Content Lvl2-related HTTP->HTTPS upgrades for images, I would recommend disabling the pref in the browser_103_preload.js, to keep the expected behavior for that test.

There are apparently no other test failures in the push above. I recommend relanding with that fixed.

Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d5ad10a5df3
enable mixed content level 2 in beta and nightly. r=freddyb,necko-reviewers,kershaw
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Keywords: leave-open
Resolution: --- → FIXED
Flags: needinfo?(lyavor)

(In reply to Pulsebot from comment #26)

Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d5ad10a5df3
enable mixed content level 2 in beta and nightly.
r=freddyb,necko-reviewers,kershaw

Should that be mentioned in our Nightly release notes?

Flags: needinfo?(lyavor)

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

Should that be mentioned in our Nightly release notes?

Yes! We'll keep on Nightly for another cycle before we let it ride the trains though.

Flags: needinfo?(lyavor)

We have nightly-only release notes, release notes addition process is documented at https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla

Blocks: 1806080
Blocks: 1806114

Bug 1787576 was marked as duplicate of this one but the change did not fix bug 1787576. Is that expected?

bug 1787576 shouldn't be marked as duplicate IMO. Since this bug is about enabling mixed content display upgrading, the other one is about the interaction of csp and this pref.

This patch does not fix bug 1787576.
Thanks for pointing it out, probably there should be a decision regarding bug 1787576 if it should be fixed or not. So far as I understand the discussion in bug 1787576 the unpleasant outcome is expected behavior and because of that it was marked as "resolved".
But for sure we should keep an eye on such problems since it could lead to complains by users.

Release Note Request (optional, but appreciated)
[Why is this notable]: This feature is upgrading mixed display content (audio, img and video) to https if possible, otherwise the content gets blocked.
[Affects Firefox for Android]: No
[Suggested wording]: Mixed content upgrading of display content
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
Blocks: 1808701
Depends on: 1808883

Note added to our 110 nightly notes (only). Thanks.

Depends on: 1819898
Depends on: 1820474
See Also: → 1848571
Depends on: 1863310
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: