1442990 - Consider allowing web extensions to upgrade display content

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P3)

Description

[Jonathan Kingston [:jkt] he/him]

In Bug 1435733 we added the ability to upgrade display content.

https://bugzilla.mozilla.org/show_bug.cgi?id=1435733#c53
> Can we expose this pref to WebExtensions?  There is a precedent for allowing WebExtensions to control certain privacy/security features: https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1397611.

Comment 1

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1442990 - Expose a websites.upgradeMixedDisplayContent pref that Web Extensions can toggle.

Review commit: https://reviewboard.mozilla.org/r/224882/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/224882/

Comment 2

[Jonathan Kingston [:jkt] he/him]

I don't think you had any concerns of exposing this last time we spoke other than we shouldn't prioritise working on it. Let me know if this has changed.

This should allow extension authors to contribute to telemetry for users in stable channel if we are blocking on shipping this to more users. I think this is worth having.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8955905 [details]
Bug 1442990 - Expose a websites.upgradeMixedDisplayContent pref that Web Extensions can toggle.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/224882/diff/1-2/

Comment 4

[Andrew Swan [:aswan]]

The request to create a WebExtension API doesn't include much detail.  How do you envision extensions using this?
Also, jkt, will this preference ever be exposed to users outside of about:config (if it is, we need to be more careful about conflicts between manual user settings and settings that come from extensions)

Comment 5

[Daniel Veditz [:dveditz]]

I'm not sure this makes sense as an extension API. Do we envision that this pref will exist permanently? If I'm understanding it the pref is a transition state and eventually either the browser will just do this, or it will fail and we won't.

Meanwhile extensions can already effectively upgrade requests: that's what the HTTPS Everywhere extension does. They can either use the request API and redirect, or they can modify incoming headers to add an "upgrade-insecure-request" CSP header.

Comment 6

[Daniel Veditz [:dveditz]]

note that HTTP Everywhere is unlikely to use the pref -- they've got a huge set of redirection rules because a simple http -> https swap causes lots of breakage. Any other extension that does use the pref would experience that breakage.

Comment 7

[Jonathan Kingston [:jkt] he/him]

> note that HTTP Everywhere is unlikely to use the pref

Bill is this the case? Do the HTTPS Everywhere complex rules apply to content or just top levels requests?

> Do we envision that this pref will exist permanently?

I think the code doesn't cause the same problems priming did or the same complexity so I envisage that we will flip this at some point, it's just a case of 'when'.

Comment 8

[William Budington]

> Bill is this the case? Do the HTTPS Everywhere complex rules apply to content or just top levels requests?

Jonathan, HTTPS Everywhere rulesets apply to all requests, not just first parties.  Additionally, we do send the "upgrade-insecure-request" CSP request header when the "Block all unencrypted connections" option is turned on in the add-on.  I see this useful for HTTPS Everywhere where we have insufficient coverage, and passive mixed content would have been blocked anyway.  In this case, HTTPS Everywhere opportunistically upgrading passive resources would be a nicety for users.

Comment 9

[William Budington]

That being said, if this is going to be turned on by default anyway at some point, I'd understand if this pref wasn't exposed to WebExtensions.

Comment 10

[Tanvi Vyas[:tanvi]]

Dan makes a good point; it doesn't make sense to expose this pref when we don't know the future of it.  Right now, it is a proposal for Mixed Content Level 2, and we are experimenting with it.  But we don't know for sure where its future lies, or if this the proposal that will eventually get spec'ed.

So in that case, making it a web extension, potentially temporarily, doesn't make sense.  I would leave this bug open and on the back burner until we figure out what we are doing with Mixed Content Level 2.

Comment 11

[Andrew Swan [:aswan]]

Comment on attachment 8955905 [details]
Bug 1442990 - Expose a websites.upgradeMixedDisplayContent pref that Web Extensions can toggle.

Clearing the review flag until we have an agreed-upon design here

Comment 12

[Tomislav Jovanovic :zombie]

Hey Johnatan and Tanvi, can we get an update on the status of this feature 2 years later?

Is this something we still want for extensions, or can we close this?

In any case, I don't think this needs docs for now, can always ask later.

Comment 13

[Jonathan Kingston [:jkt] he/him]

The latest update (as of a few weeks ago) is that MCB 2 is happening and this should be in it. It's unclear of the timeline and rollout though.

Ironically we would of benefited from this two years ago by having the telemetry. Maybe we should close this given that if we want a rollout addon it could use privileged code to do this.

Comment 14

[Tomislav Jovanovic :zombie]

Thanks, closing as per above discussion.