Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

On Mon, Dec 15, 2014 at 5:50 PM, Christian Heutger <christian@heutger.net>
wrote:
>
>   > So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs
> communicate to the user the lack of security guarantees from HTTP.
>
>  I would recommend here as mentioned:
>
>  No padlock, red bar or red strike, … => no encryption [and no
> validation], e.g. similar to SHA1 deprecation in worst situation
> Only vs. HTTPS: Padlock => everything fine and not red, „normal“ address
> bar behavior
> With EV differentiation: Padlock, yellow bar, yellow signal, … => only
> encryption, e.g. similar to current mixed content, …
> EV: Validation information, Padlock green bar, no extras, … => similar to
> current EV
>
>  Red-Yellow-Green is recognized all other the world, all traffic signals
> are like this, explanation on what signal means what can be added to the
> dialog on click. (Red) strike, (yellow) signal, (green) additional
> validation information follow also the idea to have people without been
> able to differentiate colors to understand what happens here.
>

Please don't try to debate actual presentation ideas on this list.  How UAs
present various states is something the individual UA's design teams have
much more context and experience doing, so debating that sort of thing here
just takes everyone's time to no benefit, and is likely to rapidly become a
bikeshed in any case.

As the very first message in the thread states, the precise UX changes here
are up to the UA vendors.  What's more useful is to debate the concept of
displaying non-secure origins as non-secure, and how to transition to that
state over time.

PK