Should page info bubble distinguish between HTTP and broken HTTPS?
Reported by
val...@vt.edu,
Sep 13
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.9 Safari/537.36 Steps to reproduce the problem: 1. set #omnibox-ui-hide-steady-state-url-scheme-and-subdomains to 'disabled' 2. Note that it leaves https:// and similar unmolested most of the time. 3. Visit 'http://www.blacksburg.gov' and watch the http:// evaporate because the 'not secure' showed up. What is the expected behavior? If I tell Chrome to not strip URL schemas, it shouldn't do so - *especially* when: 1) Seeing it's an http:// tells my *why* it's an insecure site 2) Clicking on the 'Not Secure' doesn't tell me any actionable info (i.e. whether it was http: or if it was an SSL crypto mismatch, or expired cert, or....) It's particularly difficult to debug if you followed a link that didn't expose the http:// nature of the target (rather than entering the URL by hand) What went wrong? I asked it to not modify the URL in the omnibox and it did so anyhow, losing information needed to debug the problem. Did this work before? N/A Chrome version: 70.0.3538.9 Channel: n/a OS Version: Flash Version:
,
Sep 14
,
Sep 17
,
Sep 17
For reference, this bug reports two issues 1. raises the questions of much we want to support the flag #omnibox-ui-hide-steady-state-url-scheme-and-subdomains (and in particular setting it to disabled). Chrome always hid the http:// scheme. Now that we have a flag to enable/disable hiding scheme/domains (originally meant only to apply to https and "trivial" subdomains), this user is requesting that setting the flag to off also applies to "http". 2. complaints that the security chip doesn't mention the scheme. If the scheme is hidden, this can be confusing about why a page is labeled as "insecure" (http versus security validation issues).
,
Sep 21
We don't make guarantees about how flags work: they are not settings, but are tools to enable development. I believe with the second problem the user can click on the security chip to find out why a site isn't secure. Given that I suspect this might be WontFix but assigning to appropriate PM to decide.
,
Oct 1
Agreed with flags not being settings, but the second issue raises a good point (that might have already been considered?): The page info bubble looks exactly the same for HTTP as it does for broken HTTPS, would we want to show the cause of the Not Secure badge in it when it's clicked, or was it specifically decided to have the bubble be the same? (In which case this is most def a WontFix). As for alternate modes of distinguishing why a 'Not Secure' chip was shown, if the Not Secure chip is shown, and there is no striked-through 'https' in the omnibox, then the URL is HTTP.
,
Nov 20
The first issue is definitely WontFix. As previously noted, that behavior has existed for a long time now. Leaving open and renaming for consideration of the second question. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, Sep 14