HTTP sites should eventually be even more aggressively distinguished as not secure
Reported by
93m4qau...@gmail.com,
Jan 4 2018
|
|||
Issue descriptionUserAgent: 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.
,
Jan 7 2018
,
Jan 12 2018
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.
,
Jan 17 2018
+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 |
|||
Comment 1 by sc00335...@techmahindra.com
, Jan 5 2018Labels: -Type-Bug Triaged-ET M-65 Needs-Triage-M63 OS-Linux OS-Mac Type-Feature
Status: Untriaged (was: Unconfirmed)