Mixed content level 2

[estark37]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Mixed Content Level 2
• Specification URL: https://w3c.github.io/webappsec-mixed-content/level2.html
• Explainer (containing user needs and example code)¹: n/a as this is not a new web feature; please see Introduction of spec and advise if a separate explainer would be helpful
• GitHub issues (if you prefer feedback filed there): https://github.com/w3c/webappsec-mixed-content/issues/
• Tests: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/mixed-autoupgrade/ (need to port to WPT)
• Primary contacts (and their relationship to the specification): @estark37, @mikewest, @carlosjoan91

Further details:

• Relevant time constraints or deadlines: Planning to ship in Chrome in early 2020, ideally need approvals in next 6 weeks
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WebAppSec

You should also know that...

This change has been running in Chrome as an experiment for several months (currently at 50% of beta channel).

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[dbaron]

I think an explainer would be useful, to answer the questions of what's new in level 2, and why are you doing a level 2 at all? Presumably there are underlying user needs that motivate that?

Also, I'd note that you ask for feedback in github issues, but the spec draft itself asks for feedback as email. Which is preferred?

[dbaron]

And, for what it's worth, I'm fine with the explainer being in the spec introduction, but right now I think there's only a single sentence of explainer there, at least in terms of "what's new in level 2" rather than "what's in either level 1 or level 2":

This specification updates and extends [MIXED-CONTENT] to provide better security and privacy guarantees while minimizing breakage.

It seems like the rest of the introduction is describing level 1 or 2... although I might be misreading it.

[estark37]

Thanks for the quick feedback! I expanded the introduction to more clearly explain what user problem we're trying to solve (lack of confidentiality and integrity for subresources, poor security UX), what's new in level 2, and to mention some alternatives we considered. Please let me know what you think.

[estark37]

Also, I'd note that you ask for feedback in github issues, but the spec draft itself asks for feedback as email. Which is preferred?

Either is fine, and I updated the spec to reflect that.

[hadleybeeman]

Thanks, @estark37! Much more helpful intro now. I can see what you're trying to do and why!

Note on 5.1: You might want to amend the text to say "...directive is not obsolete because it also allows developers to upgrade blockable content". As it is, we thought it sounds like this note was ignoring optionally-blockable content.

We appreciate the risk you've outlined in section 6. It was on our minds too. It's the same risk as in upgrade-insecure-requests.

This is a logical step on the path to the HTTPS-only web. Thanks for sharing it with us!

[kleinkk76]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Mixed Content Level 2
• Specification URL: https://w3c.github.io/webappsec-mixed-content/level2.html
• Explainer (containing user needs and example code)¹: n/a as this is not a new web feature; please see Introduction of spec and advise if a separate explainer would be helpful
• GitHub issues (if you prefer feedback filed there): https://github.com/w3c/webappsec-mixed-content/issues/
• Tests: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/mixed-autoupgrade/ (need to port to WPT)
• Primary contacts (and their relationship to the specification): @estark37, @mikewest, @carlosjoan91

Further details:

• Relevant time constraints or deadlines: Planning to ship in Chrome in early 2020, ideally need approvals in next 6 weeks
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WebAppSec

You should also know that...

This change has been running in Chrome as an experiment for several months (currently at 50% of beta channel).

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

#924