New issue
Advanced search Search tips

Issue 847544 link

Starred by 1 user
Status: Started
Owner:
pmonette@chromium.org
Cc:
pmonette@chromium.org
emilyschechter@chromium.org
jsc...@chromium.org
chrisha@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

more UI visibility into the third party blocking state

Project Member Reported by wfh@chromium.org, May 29 2018 
It would be good to have more visibility into the internal state of the third party blocking subsystem, exposed to users and also potentially enterprise admins.

At a minimum, I think we should present (potentially via a webUI page):

 - Current state of the blocking subsystem i.e. is it engaged or not, is it disabled by enterprise policy?
 - List of the modules that are injected that are not signed by microsoft and might therefore be blocked, clearly indicated.
 - List of whether these modules "are able to be tied to existing installed software." since that appears to be a trigger for further behavior.
 - Whether they are actively being blocked, or whether they are not.
 - Modules that attempted to load but were blocked.
 - Modules that were allowed to load.

Also, I think we need more information presented in product about the plans in future milestones, something in developer tools or chrome://conflicts that says "these modules will be blocked in upcoming release <date> or <milestone>"

Comment 1 by chrisha@chromium.org, May 30 2018

Cc: jsc...@chromium.org emilyschechter@chromium.org
Adding a few other folks for their thoughts.

Comment 2 by pmonette@chromium.org, Jun 12 2018

Cc: chrisha@chromium.org
Owner: pmonette@chromium.org
Status: Started (was: Assigned)
Project Member

Comment 3 by bugdroid1@chromium.org, Jun 20 2018 

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

commit d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0
Author: Patrick Monette <pmonette@chromium.org>
Date: Wed Jun 20 20:56:28 2018

Allow to force the initialization of the ThirdPartyConflictsManager

Also keep track of the status of the ModuleListFilter initialization,
which will be used later to display the state of the third-party
blocking subsystem to the user.

Bug: 847544
Change-Id: I354253ec05012f50fa4418ef1c69113844c3c2ac
Reviewed-on: https://chromium-review.googlesource.com/1097626
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569006}
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/component_updater/third_party_module_list_component_installer_win.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/component_updater/third_party_module_list_component_installer_win.h
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/incompatible_applications_updater_win.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/incompatible_applications_updater_win.h
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/incompatible_applications_updater_win_unittest.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_blacklist_cache_updater_win.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_blacklist_cache_updater_win.h
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_blacklist_cache_updater_win_unittest.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_database_observer_win.h
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_database_win.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/module_database_win.h
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/third_party_blocking_browsertest.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/third_party_conflicts_manager_win.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/third_party_conflicts_manager_win.h
[add] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/browser/conflicts/third_party_conflicts_manager_win_unittest.cc
[modify] https://crrev.com/d847a0ab17aac5a93814d0c6fc64bacc9fb16bd0/chrome/test/BUILD.gn
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 19 

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

commit a0f9859b045f62e5347cc7d6f6532591c8476dc8
Author: Chris Hamilton <chrisha@chromium.org>
Date: Thu Jul 19 14:14:27 2018

[3P] Add code ID to chrome://conflicts UX.

This makes it so that all the information needed to diagnose
whitelist issues is available in one place.

BUG=847544

Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: Idef99fa83d84ff1d7258c65f9ca4f481267758f8
Reviewed-on: https://chromium-review.googlesource.com/1142515
Commit-Queue: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576478}
[modify] https://crrev.com/a0f9859b045f62e5347cc7d6f6532591c8476dc8/chrome/browser/resources/conflicts/about_conflicts.html
[modify] https://crrev.com/a0f9859b045f62e5347cc7d6f6532591c8476dc8/chrome/browser/resources/conflicts/about_conflicts.js
[modify] https://crrev.com/a0f9859b045f62e5347cc7d6f6532591c8476dc8/chrome/browser/ui/webui/conflicts_handler.cc
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 13 

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

commit 87f85fe14060cbf0d4b6dd014c1676889aba0c5e
Author: Chris Hamilton <chrisha@chromium.org>
Date: Mon Aug 13 17:48:08 2018

[3P] Refine third party module blocking status.

The current ModuleBlockingDecision was conflating "current run" state with
the blocking decision that will be applied during the next run. This now
encodes the "next run" blocking decision in ModuleBlockingDecision, and
separates the "current run" state into a collection of booleans. The combined
state is stored in a ModuleBlockingState struct.

This allows additional edge cases to be cleanly described:
- A module that was blocked in the current run, but will not be blocked in the next.
- Allow differentiating between explicitly blocked and implicitly blocked modules.

BUG=847544

Change-Id: I5fc9dd14dde312667a137c8a0919b74fd8841d99
Reviewed-on: https://chromium-review.googlesource.com/1169965
Commit-Queue: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582632}
[modify] https://crrev.com/87f85fe14060cbf0d4b6dd014c1676889aba0c5e/chrome/browser/conflicts/module_blacklist_cache_updater_win.cc
[modify] https://crrev.com/87f85fe14060cbf0d4b6dd014c1676889aba0c5e/chrome/browser/conflicts/module_blacklist_cache_updater_win.h
[modify] https://crrev.com/87f85fe14060cbf0d4b6dd014c1676889aba0c5e/chrome/browser/conflicts/module_blacklist_cache_updater_win_unittest.cc
[modify] https://crrev.com/87f85fe14060cbf0d4b6dd014c1676889aba0c5e/chrome/browser/ui/webui/conflicts/conflicts_handler.cc
►

Sign in to add a comment