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

Issue 760647 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

chrome-error:// URLs are marked insecure

Project Member Reported by rdevlin....@chromium.org, Aug 30 2017

Issue description

Note: only works with marking http as insecure.

What steps will reproduce the problem?
1. Visit a nonexistent URL in an incognito browser (http://nonexistent.example.com will work)
2. Look at the omnibox

What is the expected result?
Since chrome-error:// pages are internal to chrome, I'd expect them to be secure.

What happens instead of that?
The omnibox reads "Not Secure" in the omnibox, which is a bit disconcerting.

Alex, assigning this to you for now, since you added the chrome-error:// scheme.  Feel free to reassign as appropriate.
 
Cc: elawrence@chromium.org alex...@chromium.org
Owner: est...@chromium.org
chrome-error:// is already marked as a secure scheme (see RegisterContentSchemes), but I think the "Not Secure" here is because we are still committing the original URL instead of the error page URL, and it's an http URL in your example.  Although I did change error pages to use chrome-error:// in r494809, this problem isn't new - I've just verified that it also happens with the old error page URL (data:text/html,chromewebdata) if I revert my change.

Although chrome-error:// is internal to chrome, we still display the nonexistent http URL in the omnibox and allow the user to reload it (which might load the http page if the error was temporary).  So I don't know whether it makes sense to make an exception to not show "Not Secure" in that case.  Over to estark@ and elawrence@ for further triage and opinions.  Feel free to reassign to me if we do need to make an exception for chrome-error://.  

Comment 2 by est...@chromium.org, Sep 29 2017

Status: Started (was: Assigned)
Yeah, this is kinda weird. Fixing it on iOS is going to be annoying, but https://chromium-review.googlesource.com/#/c/chromium/src/+/691237 at least fixes it on desktop/Android.
Project Member

Comment 3 by bugdroid1@chromium.org, Sep 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8

commit a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8
Author: Emily Stark <estark@google.com>
Date: Sat Sep 30 23:28:32 2017

Do not show Not Secure chip on incognito error pages

It's confusing/unnecessary to show Not Secure on http://nonexistent.test in
Incognito mode, so this CL gives GetSecurityInfo() a way to distinguish error
pages and not mark them as Not Secure.

The fix isn't implemented on iOS yet because it's a bit tricky to tell if we're
on an error page (have to set up a WebStateObserver and track navigations).

Bug: 760647
Change-Id: Ifdfdf7bd2546f79efcb354437b829fdeb4323d53
Reviewed-on: https://chromium-review.googlesource.com/691237
Commit-Queue: Emily Stark <estark@chromium.org>
Reviewed-by: Eric Lawrence <elawrence@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505474}
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/chrome/browser/ssl/security_state_tab_helper_browser_tests.cc
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/chrome/browser/ssl/ssl_browser_tests.cc
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/components/security_state/content/content_utils.cc
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/components/security_state/core/security_state.cc
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/components/security_state/core/security_state.h
[modify] https://crrev.com/a04c72aaf1051817f76d2f41bf0ef1ee1777ddf8/components/security_state/core/security_state_unittest.cc

Sign in to add a comment