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

Issue 642576 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

Simplify the SecurityStateModel interface

Project Member Reported by est...@chromium.org, Aug 31 2016

Issue description

The main entry point for SecurityStateModel is the GetSecurityInfo() method. This method is called quite frequently, including every time the omnibox redraws. To avoid unnecessary work, SecurityStateModel::GetSecurityInfo() memoizes based on a VisibleSecurityState provided by the SecurityStateModel's client. (The VisibleSecurityState contains any data that might affect security UI, such as the certificate, the connection status, mixed content status, etc.)

I think we should remove the memoization and VisibleSecurityState. It memoization doesn't really save us much work: when GetSecurityInfo() recomputes the security info, it's mostly just copying data from the VisibleSecurityState to the SecurityInfo. It does a little bit of computation -- mostly in GetSHA1DeprecationStatus() -- but I'm skeptical that the memoization actually gives any measurable performance improvement.

It's conceivable that in future we might want SecurityInfo to contain something that is expensive to compute and that is needed by devtools or WebsiteSettings but not by the omnibox, in which case it really would be detrimental to re-compute it every time we redraw the omnibox. I imagine that, in such a future, we could add the new computation as a method on GetSecurityInfo(), or as a separate SSM method, so that it's computed only when UI needs it.

(The reason I want to remove the memoization is basically simplicity: the SecurityStateModel interface is pretty ugly, and adding new data to SSM is a tedious matter of copying it from one object to another about 4 different times.)
 

Comment 1 by mea...@chromium.org, Aug 31 2016

I looked at this code briefly because of crrev/2254853002 and was confused about how the memoization worked. +1 for simplification.

Comment 2 by f...@chromium.org, Sep 1 2016

Cc: k...@chromium.org
Labels: ConnectionInfo
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 22 2016

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

commit 518660431c09f50c55c73b0bee872c2a5fc5b1ae
Author: estark <estark@chromium.org>
Date: Thu Sep 22 20:35:35 2016

Remove SecurityStateModel memoization

As discussed in the bug, it's hard to imagine that memoizing on
VisibleSecurityState buys us anything other than more complicated code.

BUG= 642576 

Review-Url: https://codereview.chromium.org/2363623002
Cr-Commit-Position: refs/heads/master@{#420444}

[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/android/offline_pages/offline_page_mhtml_archiver.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/safe_browsing/safe_browsing_blocking_page_test.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ssl/chrome_security_state_model_client.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ssl/chrome_security_state_model_client.h
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ssl/chrome_security_state_model_client_browser_tests.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ssl/security_state_model_android.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ssl/ssl_browser_tests.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/android/bluetooth_chooser_android.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/android/connection_info_popup_android.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/android/usb_chooser_dialog_android.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/android/website_settings_popup_android.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/browser.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/cocoa/location_bar/location_icon_decoration.mm
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/extensions/hosted_app_browser_controller.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/toolbar/chrome_toolbar_model_delegate.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/views/frame/web_app_left_header_view_ash.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/chrome/browser/ui/views/location_bar/location_icon_view.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/components/security_state/security_state_model.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/components/security_state/security_state_model.h
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/components/security_state/security_state_model_unittest.cc
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/ios/chrome/browser/ssl/ios_chrome_security_state_model_client.h
[modify] https://crrev.com/518660431c09f50c55c73b0bee872c2a5fc5b1ae/ios/chrome/browser/ssl/ios_chrome_security_state_model_client.mm

Components: -Security>UX Internals>PageSecurityState
Components: Internals>Permissions>CrowdConsent
Components: -Internals>Permissions>CrowdConsent
Labels: -ConnectionInfo
Status: Fixed (was: Assigned)
I think I've done what can be done here. I originally suggested removing VisibleSecurityState as well, but I don't think we can actually do that; it still serves for the embedder to provide security state data into the component from which the SecurityInfo is computed.

I'd still like to figure out a way to reduce the copying of VisibleSecurityState data into SecurityInfo since it's just weird that adding a field involves copying it from one struct to another, but that's a little bit of a different issue.

Sign in to add a comment