Issue metadata
Sign in to add a comment
|
Security status of website not shown when viewing full URL
Reported by
zapahj...@gmail.com,
Sep 7
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: 1. go to "half secure" website (e.g., https://livingwatersway.com/) 2. notice how omnibox shows the site as Insecure (i.e., lock icon is not shown) 3. double-click in the omnibox to display the full URL 4. with full URL displayed, notice how the omnibox now suggests the site is secure (i.e., https is shown but no security icon is present) 5. go to a full blown INSECURE site (e.g., type in the IP to an https router (that doesn't have a CA) in the local network: https://192.168.1.1) 6. notice how omnibox displays "Not secure" and also shows a red caution sign 7. double-click inside the omnibox so the full URL displays 8. with full URL displayed, notice how omnibox now suggests the site is secure (i.e., https is shown but no security icon is present) 9. go to a fully secure site (e.g., twitter.com) 10. notice how omnibox displays a lock icon 11. double-click inside the omnibox so the full URL displays 12. with full URL displayed, notice how omnibox suggests the site is secure (i.e., https is shown but no security icon is present) 13. now compare the following full-URLs: https://livingwatersway.com/ [site is "half secure"] https://192.168.1.1 [site is INSECURE] https://twitter.com [site is secure] 14. see how user is not getting necessary security information? 15. see Imgur link that I placed in "Any other comments" for screenshots that example what user is seeing. What is the expected behavior? The security status of the page should display at all times, even when viewing the full URL. Different security states can exist even when using https. What went wrong? No indication is given on the security status of the site when the full URL is being viewed. Did this work before? Yes 68 Chrome version: 69.0.3497.81 Channel: stable OS Version: Flash Version: Screenshots: https://imgur.com/a/SmMcXTw
,
Sep 7
punting into UI>Browser>Omnibox>SecurityIndicators queue, where it will likely be merged related bugs
,
Sep 9
,
Sep 10
Thanks for filing the issue! Able to reproduce the issue on reported chrome version 69.0.3497.81 and on the latest canary 71.0.3546.0 using Ubuntu 14.04 and Mac 10.13.1 Note: Issue isn't seen on Windows 10 Bisect Information: ------------------- Good Build: 68.0.3440.134 Bad Build: 69.0.3441.0 Providing the Change log from https://omahaproxy.appspot.com/ as this seems to be regressed in branched builds. https://chromium.googlesource.com/chromium/src/+log/68.0.3440.0..69.0.3441.0?pretty=fuller&n=10000 Suspecting: https://chromium.googlesource.com/chromium/src/+/bd1ec81a376c16ae7d10c9dcdd6094e256635691 Review URL: https://chromium-review.googlesource.com/c/chromium/src/+/1070466 @Avi Drissman: Please help in assigning it to the right owner if this is not related to your change. Note: Assigning it to Avi Drissman one of the reviewers, as we couldn't assign it to Emily Stark. Adding RB-Stable as this seems to be a recent regression, please remove if not required.
,
Sep 10
I would say this is working as intended. Clicking into the full URL view is intended for editing or copying the URL. The steady state will always be the non-editing view, when we show indicators. The steady state should be shown when the user is interacting with the website content itself. A design we might consider would be to strike-through the scheme for downgraded HTTPS security states (the same could apply for Safe Browsing states, but I'm not sure what the current behavior is there). I wouldn't consider this a release blocking regression though, rather something we should consider for future improvements.
,
Sep 10
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by meh...@chromium.org
, Sep 7Components: -UI UI>Browser>Omnibox