New issue
Advanced search Search tips

Issue 847051 link

Starred by 1 user

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Pre installed extension gets disabled since not coming from the webstore

Reported by chrome-a...@ironsrc.com, May 27 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1. Install chromium with predefined extension as described here and make sure the update url is not from the webstore - https://support.google.com/chrome/a/answer/188453?hl=en 
2. Open Chromium after installation

What is the expected behavior?
Predefined extension should be working properly

What went wrong?
The extension gets disabled in Chromium since it is not coming from the webstore.

WebStore page: 

Did this work before? Yes 64.0.3248.0

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

We've been using Chromium (not Google Chrome!) with a private extension (not from the Google Chrome Web Store) for some time. A while ago we noticed a change in behavior where Chromium refuses to load extensions not from the store.

After some experiments with the help of https://omahaproxy.appspot.com/ and https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html we've managed to pinpoint the change to happen between version 64.0.3248.0 (510996) and 64.0.3249.0 (511313).

Diffing the relevant commits (4bc8560..2e3b540) we found the suspect in 4226f65 (https://chromium.googlesource.com/chromium/src/+/4226f65a65c94c6cd304b5009d7eba3cd81c1535%5E%21/)
 
Labels: Needs-Bisect Needs-Triage-M66
Cc: proberge@chromium.org
Labels: Triaged-ET Needs-Feedback
Thanks for filing the issue!

As per the URL provided in steps to reproduce the problem in comment# 0(URL: https://support.google.com/chrome/a/answer/188453?hl=en), seems issue need to have CRX file to test and confirm the issue.

@Reporter: If possible could you please provide clear steps on how to install chromium with predefined extension which helps us in further triaging it from ET end.

Note: CC'ing the author proberge@chromium.org as provided in comment# 0 for further inputs on this issue.

Thanks!
Thank you for going through the trouble of pinpointing the issue and finding a suspect CL.

Looking through the code, it seems like Chromium shouldn't be disabling off-store extensions. I can see two reasons it might happen in your Chromium build. 

1. The InstallVerifier (which disables off-store extensions in Chrome) is enabled by default on Windows and MacOS if Chromium was built with the 'GOOGLE_CHROME_BUILD' flag. Is it possible that your version of Chromium was built with the "is_official_build" or "is_chrome_branded" flags? If you're not sure, please navigate to chrome://version and copy the top line to this bug.

2. The change you linked allows the Chrome variations server to specify whether to enable the InstallVerifier. Is it possible that the "--variations-server-url" command-line flag is used in your version of Chromium? If you're not sure, please navigate to chrome://version and copy the "Command Line" section into this bug.

Thanks for the clarifications. We are not building Chromium as we are only using it for internal employees and we would like to use off-store extension in those installs. We are installing Chromium from the official site with a different master preferences file (--installer-data=XXX) - is there a way to disable the InstallVerifier via cmd line parameter?
Project Member

Comment 5 by sheriffbot@chromium.org, May 29 2018

Cc: viswa.karala@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Chromium	64.0.3270.0 (Developer Build) (32-bit) 
Revision	cff667d9388ca757d9211cc3e769e4bb4c72b4e8-refs/heads/master@{#516979}
OS	Windows
JavaScript	V8 6.4.307
Flash	(Disabled)
User Agent	Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3270.0 Safari/537.36
Command Line	"C:\Users\saul\AppData\Local\Chromium\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Attached also an example of an internal extension
cbe97a5b.crx
2.2 MB Download
Thanks for the clarifications. A coworker pointed out that Chromium uses the src/testing/variations/fieldtrial_testing_config.json values not just for the unit tests but also for the Chromium builds.

I had made the change in https://chromium.googlesource.com/chromium/src/+/4226f65a65c94c6cd304b5009d7eba3cd81c1535%5E%21/ to allow for the InstallVerifier feature to be tested on the Chromium trybots. This has the negative side-effect of breaking your workflow by preventing the installation of off-store extensions in Chromium builds.

There's unfortunately no way to disable the InstallVerifier via cmd line parameters - such a flag would be abused by Unwanted Software to install bad extensions on regular user's machines.

An alternative for your use case (internal employees), assuming that your Windows machines are on an enterprise domain, could be to use enterprise policies to install your off-store extensions. See http://www.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist. 

If this works, you should also consider using Chrome instead of Chromium - which would allow you to get automatic updates of new features and important security patches.

Labels: -Needs-Bisect Needs-Feedback
As per comment# 3 & 9, the root cause of the issue is already identified, hence removing Needs-Bisect label, feel free to add it back if it is needed.

@Reporter: Could you please try to test this issue as suggested in comment# 9 and report us back the behaviour, hence adding Needs-Feedback Label.

Thanks!
Perhaps it should not be possible to disable InstallerVerifier (by command line args or otherwise) in Google Chrome for the reason stated, but it should be possible to do so on Chromium.

I don't fully understand what these trybots are, but consider this:
1) If someone need to test something he should make a private change.
2) If everyone uses it then it should be a build configuration.
3) If it has to happen on an startdard build, then it should be an external configuration (command-line arg, config file, whatever).

There's no justification for such a breaking change for what is not a policy decision but rather a developer's quick hack without considering the implications for the software and its current users.
Project Member

Comment 12 by sheriffbot@chromium.org, Jul 5

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The trybots are used for automated testing. Whenever a change is submitted to Chromium, all tests are ran to verify that the change doesn't break things.

Since you're using Chromium, you have the ability to make any code changes you want before you build a binary to distribute to your internal employees. 

Is the workaround in comment #9 not sufficient for your use case?
I'm sorry. I thought I already addressed the Group Policy proposal but it seems I somehow dropped that line. Unfortunately Google Chrome and Chromium both use the same policies/Registry keys as far as I understand. This is not what we want. We want to affect the changes for a single instance of Chromium. Not Google Chrome and not even a different instance of Chromium if one exists.

Re "make any code changes before you build" - We don't want to get into the adventure of compiling Chromium. For now we use the latest builds from chromium.org and add our extension on top of that.

Moreover, this time we managed to found the change more or less. But what if someone else decided to use the InstallerVerifier in some other place for some other reason? We certainly wouldn't be able to track every commit to Chromium, or start hunting the problematic line every time we want to update to a newer version. We strongly feel that such a significant change should not come unannounced, in some random commit, without considering the ramifications for current users, and specifically we don't understand why the change is needed in *Chromium*. If these trybots are testing *Google Chrome* ("official build") they should verify that off-store extensions can't be installed and if they're testing *Chromium* they shouldn't. We fail to understand why the change for Chromium was made.
Cc: rdevlin....@chromium.org
The number of users that use builds from chromium.org is pretty low so we rarely announce changes or consider the ramifications of changes that only impact Chromium users. I understand that it's really annoying for power users like you whose workflow is broken by these changes - but it's really hard to effectively communicate changes which will impact a few dozen users. 

If you have some extra bandwidth and deeply care about this issue, we do appreciate patches. I don't have time at the moment to fix the issue, but if you send a changelist to myself and rdevlin.cronin we'll be happy to review it.

Sign in to add a comment