Non-secure sites transition through secure green-lock state |
||||||
Issue descriptionChrome Version: 61.0.3137.0 OS: Android What steps will reproduce the problem? (1) Visit https://badssl.com in VR BBB (2) Click the "expired" link and watch the URL bar closely What is the expected result? URL bar transitions from https://badssl.com with a green lock to https://expired.badssl.com with a red triangle, with no intermediate states. What happens instead? URL bar flashes https://expired.badssl.com with green lock briefly before it shows the red triangle icon. This is not necessarily a bad bug in and of itself, but I'm worried that it might be indicative of some misalignment with how the normal omnibox works and might indicate that other, worse spoofing bugs are possible. If https://expired.badssl.com takes a long time to load, I wonder if the green lock with https://expired.badssl.com would show up in the omnibox for a long time?
,
Jun 22 2017
Emily, based on your comments, there could be two things at play here: 1. We don't get our URL and security state from the ToolbarModel. 2. We don't trigger visual updates the same way Android and clank do. On item 1: I am working to move VR to use the ToolbarModel. This doesn't control *when* visuals are updated, but it should ensure that *what* we render is consistent with Desktop/Clank. This looks like one piece of low-hanging fruit we can pull from existing Omnibox. On item 2: I suspect there is no issue, but I'm not certain yet. We're basically using the observer to trigger redraws on security and navigation events, and if anything, we might be triggering too often. Based on my initial code digging, I don't think it's easy to "unify" the triggers across Clank and Desktop. But, alternatively, I can look at trying to plumb the Clank update trigger through to VR's native code, so that we redraw exactly when Clank would redraw (which might be more or less often than we currently do). It'd be unfortunate to tie ourselves to Clank, but it may be worthwhile for peace of mind in the short term.
,
Jun 23 2017
I'd like to understand where that transient green lock is coming from. The security level should never Secure unless there is an error-free certificate [1], and there never would be an error-free certificate when navigating to https://expired.badssl.com, so I'm confused how a green lock is ever showing up. I'm concerned that the security level and URL are updating out of sync or something (e.g. the URL updates to https://expired.badssl.com but "inherits" the green lock from the previous navigation). [1] https://cs.chromium.org/chromium/src/components/security_state/core/security_state.cc?q=security_state.cc+package:%5Echromium$&l=133
,
Jun 23 2017
Is it possible our WebContentsObserver use is just incorrect? We are overriding its DidChangeVisibleSecurityState(), but maybe that's an incomplete picture of what the URL bar should be drawing. I have that CL in-progress to drive the URL bar from ToolbarModel instead. I'll re-test this case with those local changes, and see what happens.
,
Jun 24 2017
,
Jun 29 2017
,
Jun 29 2017
ToolbarModel to the rescue. VR browser now exhibits the expected behavior. See CL https://codereview.chromium.org/2960903002/
,
Feb 7 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ddorwin@chromium.org
, Jun 21 2017