Issue metadata
Sign in to add a comment
|
Make whitelist for local adresses
Reported by
ivan...@live.ru,
Mar 9 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3031.0 Safari/537.36 Steps to reproduce the problem: 1. Opened any local HTTP address which contains password entry. 2. The browser warns that the page and password entry are not secure. What is the expected behavior? What went wrong? I think need make an exception for the local zones of network. For example, I attached a screenshot of the address belonging to the router. Of course risks of vulnerabilities in this interaction still remain, but I do not think that all manufacturers will update the firmware and certificates in the consumer devices. In most cases the routers do not have the HTTPS login interface, since it does not make much sense. When the icon will change in the warning (https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html), this can cause a great misconception for novice and inexperienced users who will think that their devices is completely unsafe. Did this work before? N/A Chrome version: 59.0.3031.0 Channel: n/a OS Version: 10.0 Flash Version:
,
Mar 10 2017
Not sure the correct label for this. Note that the local network is not always trusted (Think an open wifi network at Starbucks, or an airport), so this is probably desired behavior.
,
Mar 10 2017
+estark
,
Mar 10 2017
Thanks for the report. I don't think we'll change this behavior: as comment 2 pointed out, local network addresses are not trusted. We already have an exception for localhost names (a password field on http://localhost does not get the Not Secure badge). So, I think this is working as intended. Ideally it would be easier for devices on the local network to to set up valid HTTPS connections to avoid this.
,
Mar 10 2017
I agree with these reasons, big thanks for attention. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Mar 10 2017