#420: Mixed content level 2

Visit on Github.

Opened Sep 6, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details:

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]

Discussions

Comment by @dbaron Sep 6, 2019 (See Github)

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?

Comment by @dbaron Sep 6, 2019 (See Github)

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.

Comment by @estark37 Sep 6, 2019 (See Github)

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.

Comment by @estark37 Sep 6, 2019 (See Github)

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.

Comment by @hadleybeeman Sep 11, 2019 (See Github)

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!

Comment by @kleinkk76 Jan 6, 2024 (See Github)

こんにちはTAG!

I'm requesting a TAG review of:

Further details:

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