The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385

commit c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385
Author: felt <felt@chromium.org>
Date: Thu Sep 15 14:09:21 2016

Add a new flag for HTTP-bad Phase 1 development work

This extends the #mark-non-secure-as flag to use for the HTTP-bad phase
1 (passwords and CC form detection) work. It currently behaves exactly
like the existing kMarkNonSecureAsNeutral switch, although presumably
that will change as we make progress.

BUG= 646221 

Review-Url: https://codereview.chromium.org/2337103002
Cr-Commit-Position: refs/heads/master@{#418860}

[modify] https://crrev.com/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385/chrome/app/generated_resources.grd
[modify] https://crrev.com/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385/chrome/browser/about_flags.cc
[modify] https://crrev.com/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385/components/security_state/security_state_model.cc
[modify] https://crrev.com/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385/components/security_state/switches.cc
[modify] https://crrev.com/c7a6a6f68877cc8346cb7fa6bfa9e5eab7148385/components/security_state/switches.h

If I want to direct engineers to this flag, is there a specific hashtag? Would I sent them to this Bug?

Re #3: #mark-non-secure-as with the non-secure-passwords-cc switch

also point them to this bug so they can see where the switch is to work with it

felt@: What should "Always mark non-secure origins as neutral" do for expired.badssl.com? It currently shows as bad.

Re #6: "non-secure" = HTTP and equivalent. It doesn't do anything to HTTPS sites, validated or otherwise.

That sounds wrong to me.

Broken HTTPS is also non-secure by definition of the word "secure".
And the flag choices are "Mark non-secure origins as *non-secure*" vs. "Mark non-secure origins as neutral."

I think we should avoid using "non-secure" to mean "HTTP or downgraded [e.g. mixed content] HTTPS" to avoid any potential for confusion.

This is how they've always been named; I didn't introduce any new naming scheme here, just continued with it for consistency. But I can update the strings in the dropdown.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ddc621c75ee7aba48a886d48201052047212b780

commit ddc621c75ee7aba48a886d48201052047212b780
Author: felt <felt@chromium.org>
Date: Fri Sep 23 23:23:00 2016

Rename HTTP bad-related flags to be more clear

The previous names used "non-secure", which is precise and correct
(anything that is not a secure context) but confusing (does that include
a supposedly secure context that is invalid?). This renames them to say
"Http", but leaves the actual name of the flag the same because it's
already widely documented.

BUG= 646221 

Review-Url: https://codereview.chromium.org/2344043003
Cr-Commit-Position: refs/heads/master@{#420780}

[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/chrome/app/generated_resources.grd
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/chrome/browser/about_flags.cc
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/chrome/browser/ssl/ssl_browser_tests.cc
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/components/security_state/security_state_model.cc
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/components/security_state/security_state_model_unittest.cc
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/components/security_state/switches.cc
[modify] https://crrev.com/ddc621c75ee7aba48a886d48201052047212b780/components/security_state/switches.h

Security>UX component is deprecated in favor of the Team-Security-UX label