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

Issue 690166 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Feature


Sign in to add a comment

[Win] Blocking third party modules

Project Member Reported by chrisha@chromium.org, Feb 8 2017

Issue description

Feature description:

The Chrome Third Party project (http://go/chromethirdpartyblocking) is about blocking third party modules from loading into Chrome’s processes on the Windows platform

Eng owner: chrisha@google.com

Product owner: rpop@google.com

Design doc: https://docs.google.com/document/d/1wA-XM1xUMf1ahMuxfPHgTRHQxvqV0U5-tgCevYHVf3c/edit#

Are you planning on experimenting before launch? yes

Any new strings? yes

Any implications for Google webservices (i.e. sync, translate)? no

Binary size?
Will require distributing a new black/whitelist of size O(100KB) - O(1MB).
This will be slowly evolving and only incur infrequent differential updates.

Do the existing perf tests exercise all aspects of your new feature(s)?
Yes.
 
Issue 617176 has been merged into this issue.
Blockedon: 704233
Blocking: 710420
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 13 2017

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

commit c0ce31467ec5d9f79c3e1e069f785d211a03d655
Author: chrisha <chrisha@chromium.org>
Date: Thu Jul 13 15:57:33 2017

Create third-party conflicts module whitelist/blacklist protobuf definitions.

This defines the format in which whitelist/blacklist information will be distributed.

BUG=690166

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

[modify] https://crrev.com/c0ce31467ec5d9f79c3e1e069f785d211a03d655/chrome/browser/BUILD.gn
[add] https://crrev.com/c0ce31467ec5d9f79c3e1e069f785d211a03d655/chrome/browser/conflicts/proto/module_list.proto

Blockedon: 757454
Blockedon: 789174
Windows ends up loading some modules such as Network Providers and Shell Extensions automatically when Chrome opens a File Dialog.
Some of these are wrongly listed as incompatible apps, and blocking them would reduce the functionality of the File Dialog. More details in issue 877852.

If Chrome doesn't want these module being loaded in its main process, maybe a proxy process for the File Dialog should be implemented?
Blockedon: 884075
Yes, we're planning on moving file save / file load dialogs to a utility process for this very reason. In the meantime, those shell extensions will continue to be blocked.

Shell extensions that register appropriately are also excluded from the incompatible software warning, as the vast majority of them are innocent.

I've created  issue 884075  to track this.
Actually, network providers or shell extensions that only provide an icon overlay don't seem to be excluded from the warning. From what I gather from the code, only IME and regular shell extensions (e.g. context menus) are excluded.

Sign in to add a comment