Intent to Ship: Strict mixed content checking.

90 views
Skip to first unread message

Mike West

unread,
May 12, 2015, 12:17:29 AM5/12/15
to blink-dev, Tanvi Vyas
# Contact emails

# Spec
# Summary
In order to give authors assurance that mixed content will never degrade the security UI presented to their users, authors may choose to enable a stricter variant of mixed content checking which will both block optionally-blockable and blockable mixed content, and suppress the user override options.
# Motivation
User agents generally allow "optionally blockable" mixed content (like images and media files) to load, but degrade the security UI of the site in order to show users that the guarantees of HTTPS aren't being completely upheld by a particular site. Web developers have the ability to ensure that their own sites don't load mixed content, but it can be difficult to ensure the same holds true for third-party content loaded in via frames.

The `block-all-mixed-content` CSP directive allows a site to assert that mixed content should never be loaded in its context, and provides assurance that third-party content can't break the promises the developer wishes to make.

#Compatibility Risk
Firefox: I didn't find a bug, but Mozillians were supportive of publishing the spec as CR, so I assume they intend to implement this flag. CCing Tanvi for clarity.
Internet Explorer: No public signals (but they also supported publishing the spec as CR).
Safari: Safari doesn't block any kind of mixed content, which is a shame.
Web developers: No public signals I can point to, but at least one Google property has expressed interest in offering this directive to its users as an option.
# Describe the degree of compatibility risk you believe this change poses
Low. The feature is part of the Mixed Content spec, which has advanced to candidate recommendation with broad support in the WebAppSec working group. Browsers that don't support the directive won't break; they simply will continue to block only "blockable" mixed content, as they do in the status quo. # Ongoing technical constraints
None

# Will this feature be supported on all six Blink platforms
Yes

# OWP launch tracking bug

# Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5823679871057920

# Requesting approval to ship?
Yes

Thanks!

-mike

Jochen Eisinger

unread,
May 12, 2015, 8:01:20 PM5/12/15
to Mike West, blink-dev, Tanvi Vyas
LGTM

Philip Jägenstedt

unread,
May 13, 2015, 5:26:57 PM5/13/15
to Jochen Eisinger, Mike West, blink-dev, Tanvi Vyas
LGTM2

LGTM
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
May 19, 2015, 12:46:23 PM5/19/15
to Philip Jägenstedt, Jochen Eisinger, Mike West, blink-dev, Tanvi Vyas
LGTM3

Tanvi Vyas

unread,
May 19, 2015, 1:51:26 PM5/19/15
to Mike West, blink-dev
Hey Mike,

We don't have this on our roadmap yet.  But we are working on upgrade-insecure-requests in https://bugzilla.mozilla.org/show_bug.cgi?id=1139297

Thinking about this more, wouldn't upgrade-insecure-requests have the same effect as block-all-mixed-content?  It would try and upgrade any http request to https.  If the upgrade fails, the resource will be blocked and the security UI of the top level page will not be compromised (lock is in tact, no shield to disable protection).  Why would a website choose block-all-mixed-content over upgrade-insecure-requests.  With upgrade-insecure-requests, there is more opportunity for a successful page load.

~Tanvi


On 5/11/15 9:17 PM, Mike West wrote:
# Contact emails

# Spec
# Summary
In order to give authors assurance that mixed content will never degrade the security UI presented to their users, authors may choose to enable a stricter variant of mixed content checking which will both block optionally-blockable and blockable mixed content, and suppress the user override options.
# Motivation
User agents generally allow "optionally blockable" mixed content (like images and media files) to load, but degrade the security UI of the site in order to show users that the guarantees of HTTPS aren't being completely upheld by a particular site. Web developers have the ability to ensure that their own sites don't load mixed content, but it can be difficult to ensure the same holds true for third-party content loaded in via frames.

The `block-all-mixed-content` CSP directive allows a site to assert that mixed content should never be loaded in its context, and provides assurance that third-party content can't break the promises the developer wishes to make.

#Compatibility Risk
Firefox: I didn't find a bug, but Mozillians were supportive of publishing the spec as CR, so I assume they intend to implement this flag. CCing Tanvi for clarity.
Internet Explorer: No public signals (but they also supported publishing the spec as CR).
Safari: Safari doesn't block any kind of mixed content, which is a shame.
Web developers: No public signals I can point to, but at least one Google property has expressed interest in offering this directive to its users as an option.
# Describe the degree of compatibility risk you believe this change poses
Low. The feature is part of the Mixed Content spec, which has advanced to candidate recommendation with broad support in the WebAppSec working group. Browsers that don't support the directive won't break; they simply will continue to block only "blockable" mixed content, as they do in the status quo.# Ongoing technical constraints
None

# Will this feature be supported on all six Blink platforms
Yes

# OWP launch tracking bug

# Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5823679871057920

# Requesting approval to ship?
Yes

Thanks!

-mike

PhistucK

unread,
May 19, 2015, 2:03:50 PM5/19/15
to Tanvi Vyas, Mike West, blink-dev
I agree with Tanvi. What makes them so orthogonal to require a whole new token?


PhistucK

Reply all
Reply to author
Forward
0 new messages