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

Issue 682291 link

Starred by 3 users
Status: Duplicate
Merged: issue 543864
Owner: ----
Closed: Apr 2017
Cc:
rbyers@chromium.org
█ sigbjo...@opera.com
Components:
EstimatedDays: ----
NextAction: 2017-02-01
OS: ----
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

chrome://settings shows secure; but devtools shows it isn't

Reported by rfe...@gmail.com, Jan 18 2017 
Chrome Version       :Version 55.0.2883.87 m
 
Google Chrome is up to date.

URLs (if applicable) :chrome://settings/
Other browsers tested: don't use these other browsers,  IE is not working properly since ms update - another issue
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari:
    Firefox:
         IE:

What steps will reproduce the problem?
(1)
(2)
(3)

What is the expected result?
if Chrome says pages are secure, I would expect them to be

What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

Chrome settings pages are not secure... but the link indicates a secure page; also what are the uber scripts?  I see them when the pages are not secure.

Comment 1 by rbyers@chromium.org, Jan 18 2017

Labels: Needs-Feedback
NextAction: 2017-02-01
Your screenshot is a duplicate of the one in  issue 682295  (about /deep/).  Are you able to reproduce a scenario involving the settings page that shows the window.postMessage warning?  I don't see any issue on Chrome 57.

Regarding chrome://settings being marked insecure - I've filed  issue 682458  to discuss changing that.

The "uber scripts" (chrome://uber-frame) are just an implementation detail of how the settings UI is broken up into different iframes.

Comment 2 by rbyers@chromium.org, Jan 18 2017

Cc: rbyers@chromium.org

Comment 3 by ajha@chromium.org, Jan 24 2017

Labels: Needs-Triage-M55

Comment 4 by dtapu...@chromium.org, Feb 2 2017

Summary: chrome://settings shows secure; but devtools shows it isn't (was: Deprecate and remove: WebKit legacy window.postMessage() overload)
I think the issue that the user is reporting is that ombibar shows the page as secure; but if you look in devtools it reports that it isn't. This is about consistency.

Unfortunately I don't have M57 available at the moment to check if the resolution of  issue 682458  fixes the issue on the devtools security tab.

Comment 5 by dhw@chromium.org, Feb 15 2017

Labels: -Needs-Feedback -Needs-Triage-M55
Status: Available (was: Unconfirmed)
Unfortunately no, the resolution of  Issue 350634  (dup of  Issue 682458 ) does not fix the DevTools security inconsistency in Canary 58.
Chrome_Help_NotSecure.png
63.9 KB View Download

Comment 6 by rtoy@chromium.org, Feb 15 2017

Components: -Blink Platform>DevTools>Security

Comment 7 by lgar...@chromium.org, Feb 15 2017 

This is similar to how we show bad stuff for net errors, and maybe localhost. I can't find another bug specific to chrome:// URLs, so I'll keep this bug, too.

Comment 8 by mea...@chromium.org, Mar 10 2017 

Another option is to change the page info text, instead of "secure Chrome page" it could say "internal Chrome page".

Comment 9 by elawrence@chromium.org, Apr 11 2017

Mergedinto: 543864
Status: Duplicate (was: Available)
►

Sign in to add a comment