Intent to Deprecate and Remove: Block-all-mixed-content CSP directive

[Carlos IL]

Contact emails

carl...@chromium.org

Explainer

None

Specification

https://www.w3.org/TR/mixed-content/#strict-checking

Summary

block-all-mixed-content is a CSP directive that causes Chrome to hard block all http resource loads on https sites. After the launch of autoupgrades for passive mixed content, the directive is a no-op since passive (image, video, and audio) mixed content is autoupgraded to https before block-all-mixed-content is evaluated (and fails to load if not available over https), and active mixed content is hard blocked by default. block-all-mixed content still has an effect when a user has allowlisted a site (using the "Insecure Content" site setting toggle) to allow mixed content, but that is a fairly niche use case (and it seems unlikely that sites are relying on that functionality). block-all-mixed-content was previously defined in the MIX spec, but was marked as obsolete when MIX and MIX2 were merged and the concept of autoupgrades was introduced. It is already marked as deprecated in MDN docs.

Blink component

Blink>SecurityFeature>MixedContent

Motivation

block-all-mixed content is already marked as obsolete in the Mixed Content spec, is a no-op in most cases, and removing it would simplify Chrome's mixed content handling code.

Initial public proposal

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The spec change that made this directive obsolete went through comments in webappsec and has already been merged to the spec (since 2020)

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5199363708551168

[Yoav Weiss]

Any use counters for when it is used?

On Saturday, February 4, 2023 at 12:46:16 AM UTC+1 Carlos IL wrote:

Contact emailscarl...@chromium.org

ExplainerNone

Specificationhttps://www.w3.org/TR/mixed-content/#strict-checking

Summary

block-all-mixed-content is a CSP directive that causes Chrome to hard block all http resource loads on https sites. After the launch of autoupgrades for passive mixed content, the directive is a no-op since passive (image, video, and audio) mixed content is autoupgraded to https before block-all-mixed-content is evaluated (and fails to load if not available over https), and active mixed content is hard blocked by default. block-all-mixed content still has an effect when a user has allowlisted a site (using the "Insecure Content" site setting toggle) to allow mixed content, but that is a fairly niche use case (and it seems unlikely that sites are relying on that functionality).

So this can have a visible effect when users explicitly allow mixed content *and* the site is trying to prevent that? And the effect in this case would be that the mixed content resources are not broken?

block-all-mixed-content was previously defined in the MIX spec, but was marked as obsolete when MIX and MIX2 were merged and the concept of autoupgrades was introduced. It is already marked as deprecated in MDN docs.

Blink componentBlink>SecurityFeature>MixedContent

Motivation

block-all-mixed content is already marked as obsolete in the Mixed Content spec, is a no-op in most cases, and removing it would simplify Chrome's mixed content handling code.

Initial public proposal

TAG review

TAG review statusNot applicable

Risks

Interoperability and Compatibility

The spec change that made this directive obsolete went through comments in webappsec and has already been merged to the spec (since 2020)

Gecko: No signal

WebKit: No signal

Did other vendors ship this? If so, are they planning to unship it?

[Rick Byers]

It sounds like the only potential concern is a security one - where content previously blocked at the site's request was no longer blocked. Is that right? If so then I'd defer to security reviewers and approve from a web compat perspective without any metrics.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a73276e-a3d4-45d3-b3fb-751f9edd6d09n%40chromium.org.

[Daniel Bratell]

It sound like the user has already agreed to seeing "insecure" and possibly compromised content in that case, but it could absolutely make something worse.

Is there a use counter for how often a user demands to see an "insecure" page? That would act as an upper limit, and maybe it's already small enough. (Or maybe not).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_%3DHGk4vyuTMa72sRCAapQ3mYOknDDSQyB%3DgC6df2wY2A%40mail.gmail.com.

[Carlos IL]

Thanks all for the comments, replied inline below:

On Wed, Feb 8, 2023 at 9:18 AM Daniel Bratell <brat...@gmail.com> wrote:

It sound like the user has already agreed to seeing "insecure" and possibly compromised content in that case, but it could absolutely make something worse.

Is there a use counter for how often a user demands to see an "insecure" page? That would act as an upper limit, and maybe it's already small enough. (Or maybe not).

Unfortunately we don't have a use counter tied to the setting, we only log mixed content used counters when the actual content is loaded. 

/Daniel

On 2023-02-08 17:24, Rick Byers wrote:

It sounds like the only potential concern is a security one - where content previously blocked at the site's request was no longer blocked. Is that right? If so then I'd defer to security reviewers and approve from a web compat perspective without any metrics.

Yeah, there are no compatibility concerns here since this won't prevent anything from loading or functioning

 

Rick

On Wed, Feb 8, 2023 at 10:01 AM Yoav Weiss <yoav...@chromium.org> wrote:

Any use counters for when it is used?

Unfortunately we do not have one for block-all-mixed-content, just for the actual loading of mixed content (which doesn't help in this case since it's being blocked from loading).

Thanks again,

-Carlos 

[Chris Harrelson]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfVOkk%2BT%2BBCtRGjejUxYBhKqqvbGC1mPvdUg8DPVGM%3DaXQ%40mail.gmail.com.

[Yoav Weiss]

LGTM2 - this doesn't feel like it has any compat risk, so we shouldn't block on usecounter data.

[Rick Byers]

LGTM3 - looks like there aren't concerns from Chrome security