New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 799163 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Feature
Team-Security-UX



Sign in to add a comment

HTTP sites should eventually be even more aggressively distinguished as not secure

Reported by 93m4qau...@gmail.com, Jan 4 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
N/A

What is the expected behavior?
HTTP sites are always marked with an orange open padlock and orange text "Not secure". The orange should be dark enough so that it is easily readable and does not blend in with the white background. Furthermore, when someone clicks on a text box on the insecure page and is about to start typing their social security number or whatever, Chrome could add a red open or diagonally striked-through padlock next to the text box. If someone clicks on a dropdown, Chrome could add a red open or diagonally striked-through padlock next to the dropdown.

What went wrong?
At the moment, HTTP sites are marked with a gentle information icon and "Not secure" text is only displayed upon typing on the insecure page. Even though "Not secure" does expand once someone starts typing their credit card number into the insecure site, no one will ever notice it unless they are already paying attention to the verbose chip. Furthermore, if someone uses dropdowns to select their date of birth and then submits it through the open, no "Not secure" expands for that.

Did this work before? No 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

HTTP is insecure and should be aggressively distinguished by Chrome. I doubt my suggestion will be accepted, though.
 
Cc: sc00335...@techmahindra.com
Labels: -Type-Bug Triaged-ET M-65 Needs-Triage-M63 OS-Linux OS-Mac Type-Feature
Status: Untriaged (was: Unconfirmed)
93m4qau783@ Thanks for the issue.

From the original comment, looks like this is a feature request.

Hence marking this as Untriaged for further updates from Dev.

Thanks..
Components: -UI UI>Browser>Omnibox>SecurityIndicators
Cc: emilyschechter@chromium.org
Status: WontFix (was: Untriaged)
Thanks for the suggestion and thoughts!

What is described is our current plan, however we need to get HTTP usage to a reasonable level before we can implement this plan (to avoid freaking out 99% of the internet using population). I don't know what the particular level is, emilyschechter@ might be able to share more.

Aggressive efforts are under way to improve HTTPS usage over HTTP, and this is having a material effect, so hopefully HTTP-bad-everwwhere isn't too far off.
+1 to Ben's comment. What is described is our current plan. We don't have a specific timeline yet but hope to share more soon.

Sign in to add a comment