+1 from reddit:
https://www.reddit.com/r/brave_browser/comments/a542t2/just_downloaded_brave_trying_to_install_3rd_party/

Yup, that's me on Reddit :)

Just to add to this, Brave Browser keeps rejecting the installation of Roboform which is listed on the Chrome Web Store. It flagged it as not being on the Brave web store as well.

@thisisespria — that sounds like a separate issue, which I'm not able to reproduce. Can you file a new issue with screenshots of what you're experiencing, and more detail?

@thisisespria — that sounds like a separate issue, which I'm not able to reproduce. Can you file a new issue with screenshots of what you're experiencing, and more detail?

It was a temporary problem, it looks like. After the extension updated, for some reason it began conflicting with Brave browser and kept getting marked as not tested by Brave and not being in the Brave web store. I was able to get around it by using developer mode and sideloading the extension but I've uninstalled and reinstalled from the web store and it works fine now.

I guess this behavior is intentional according to this support document (Learn More).

The support document is very unclear about how a Developer should reupload their extension. I also find this decision to be problematic for developers who may want to test their own extensions out, and even for regular users using extensions that can't be added to the Chrome Web Store.

Hope they will allow us to enable non web store extension, as long as they display a message to discourage the average user from doing it

Is there any work around to this problem?

+1
https://community.brave.com/t/any-news-about-whitelist-for-extensions/76815

Ran into this issue after updating to the latest version of brave. As far as I can tell the only way to fix this for effected users would be to patch install_verifier.cc or extension_service.cc to remove the nonstore checks. There used to be a flag you could pass to sideload however according to google forums that no longer exists

I recently started getting used to Brave and I really like it but it seems like non-chrome webstore extensions cannot be enabled, is this true? I downloaded the dev channel version as I do with chrome in order to be able to whitelist homemade extensions in the Windows registry. This would be a deal-breaker unfortunately so please tell me there is a way??

I hope this gets fixed.

Another +1 for this. Had to download Chrome again because a tool I'm using is distributed as a .crx :'(

@damendo exactly same situation here. I have to use a tool distributed as .crx

+1

Can anybody from team comment on whether this is intentional or a bug and whether there are plans to fix this or not?
There are arguments for both, so I'm just curious about what to expect

I used to circumvent this issue by white listing/forceinstall listing my extensions via policies in the registry (HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallForcelist / HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallWhitelist).

Now even that doesn't work...
Any news?

Relinking my earlier comment on this issue:

#5761 (comment)

This punishes using any FOSS extensions that aren't on the chrome store since the only other option is to get the source and load it as a dev extension but that causes an annoying popup that the devs seem to think is wanted (#5063). This includes anything google disagree with, such as blocking paywalls (See the example OP supplied)

I used to circumvent this issue by white listing/forceinstall listing my extensions via policies in the registry (HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallForcelist / HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallWhitelist).

Now even that doesn't work...
Any news?

Tried with HKLM\SOFTWARE\Policies\BraveSoftware\Brave as reported here: #5063 (comment) .
I can confirm that my custom extension it's working.

It's really horrendous how they say that brave "begins with giving you back power."
Please guys, listen to the community and stop making things harder for everyone

There are certain ad blocking extensions that Google doesn't allow on their store that have to be loaded this way and (for some reason) Brave refuses to give the user the choice to do so. I switched to another browser until this is fixed, but I won't hold my breath.

I was looking for a way to make a self-signed crx extension work in Brave. It looks like @aetonsi is right. I am able to get my extension working with GPO white-listing.

I'm posting this here in case others are trying to run a custom 3rd party .crx extension that's not from the chrome webstore and getting the above error when sideloading. You need to add the following registry key(datatype are all SZ string type):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallWhitelist]
"1"="_<your .crx extension id here>_"
"2"="_<next .crx extension id here>_"
; etc...
; for example:
;"3"="npifoilcgoddgoagljbkagfmmafmphki"

Setup I tested this on, Win7 64-bit with Brave 1.3.113 Chromium: 80.0.3987.87 32-bit. This is actually Brave-portable.

I was looking for a way to make a self-signed crx extension work in Brave. It looks like @aetonsi is right. I am able to get my extension working with GPO white-listing.

I'm posting this here in case others are trying to run a custom 3rd party .crx extension that's not from the chrome webstore and getting the above error when sideloading. You need to add the following registry key(datatype are all SZ string type):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallWhitelist]
"1"="_<your .crx extension id here>_"
"2"="_<next .crx extension id here>_"
; etc...
; for example:
;"3"="npifoilcgoddgoagljbkagfmmafmphki"

Setup I tested this on, Win7 64-bit with Brave 1.3.113 Chromium: 80.0.3987.87 32-bit. This is actually Brave-portable.

Hey, I'm using Brave Stable build on Win10 and the specific registry path is absent in my case. any idea on this?

The reason why sideloaded, non-store extensions are blocked seems to be this flag set at compile time: --extensions-install-verification=enforce
The stable and beta versions of Google Chrome seem to have a similar default setup.

Like with Google Chrome you can actually work around this restriction by creating a policy file like it is described in this tutorial from Google.

For Debian/Ubuntu users the steps are as follows:

sudo mkdir /opt/brave.com/brave/extensions
sudo editor /opt/brave.com/brave/extensions/aaaaaaaaaabbbbbbbbbbcccccccccc.json

aaaaaaaaaabbbbbbbbbbcccccccccc is the ID of your extension (you can for example retrieve it from chrome://extensions if you have sideloaded the extension already and it got disabled)
This json file only needs two entries (/home/username/extension.crx is the location of your CRX file):

{
	"external_crx": "/home/username/extension.crx",
	"external_version": "1.0"
}

After creating and saving the json file, the only thing you have to do is to start Brave, visit chrome://extensions, enable "Developer Mode" and drop the extension into the browser window. Make sure that the extension is located in the path you specified in the json file. If done correctly, the extension should now stay activated.

Recently google erased ClearUrls from Chrome Web Store and I can't install the crx. This was an important extension for me and other users. Why Brave doesn't allow us to install other extensions?

Hi folks - I can definitely understand being upset. The problem here is this behavior is inherited from Chromium. The behavior you're seeing isn't a result of anything we at Brave are doing on purpose. There are sets of patches where we deviate from Chromium which you can view those here:
https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)

The solution for this issue would be to:

1. Define what a proper solution for this would be
2. Patch the behavior in Chromium (and add to the wiki above)
3. Clean up patches per our Patching Chromium guideline

cc: @diracdeltas @karenkliu as there is a security implication of making a change here. I'm not sure what the preferred behavior would look like? The problem isn't installing unpacked extensions, the problem is signed extensions (outside of the Chrome Web Store)

The work-around I would recommend for now would be to use the group policy. For example on Windows, the key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallAllowlist]
(Older versions of Chromium used ExtensionInstallWhitelist - this is now deprecated)

The registry keys won't exist by default - you'll have to either create those in RegEdit or double click a .reg file. For example, make a new text file, rename as extensions.reg (or similar) and putting something similar:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallAllowlist]
"1"="_<your .crx extension id here>_"
"2"="_<next .crx extension id here>_"

More info about the group policy here: https://chromeenterprise.google/policies/#ExtensionInstallAllowlist

Group policy should work on other platforms too - although I have never used it outside of Windows. Kudos to @esjarc and @shivashranz above for sharing the details 😄

Hi Brian, thanks for the update on this issue. I'm curious why extensions work on Arch Linux Chromium. The chromium package doesn't deviate much from upstream either. Yet it is able to run extensions that are installed by package manager such as browserpass.

@bsclifton Your explanation sadly does not add up.

First of all Chromium does not block any third party extension for me. This is only a problem on brave.

The behavior you're seeing isn't a result of anything we at Brave are doing on purpose.

This directly contradicts Brave's official support article, where this is explained to have been done on purpose: https://support.brave.com/hc/en-us/articles/360017914832-Why-am-I-seeing-the-message-extensions-disabled-by-Brave

Moreover my issue #10018 does not seem to trigger any interest from brave devs.

Pretty sad that brave seems to go the censoring route, just like big tech.

@bsclifton IIUC there's two separate issues here:

1. the original report which says that non-CWS crx files can't be loaded even when developer mode is enabled. this seems like a bug; if developer mode is enabled, you should be able to load extensions that aren't in CWS.
2. whether to allow non-CWS extensions when developer mode is NOT enabled. it's not clear to me whether Chrome and Chromium differ in this regard.

are users still seeing some kind of warning whenever developer mode is enabled? i have had an extension i made (that's not in CWS) installed for months without issue.

@bsclifton Are you sure that Brave is not disabling this on purpose? If I am right with my assumption that the command line switch --extensions-install-verification=enforce disables all extensions from sources other than the Chrome Web Store, then this is one of the settings you explicitly enable in one of your patches:

  // Setting these to default values in Chromium to maintain parity
  // See: ChromeContentVerifierDelegate::GetDefaultMode for ContentVerification
  // See: GetStatus in install_verifier.cc for InstallVerification
  command_line.AppendSwitchASCII(
      switches::kExtensionContentVerification,
      switches::kExtensionContentVerificationEnforceStrict);
  command_line.AppendSwitchASCII(switches::kExtensionsInstallVerification,
                                 "enforce");

Other Chromium-based browsers like Chromium (from the Debian repository), Vivaldi and Kiwi Browser don't disable sideloaded extensions and I have only ever experienced this issue with Brave.
The default startup parameter list of Vivaldi is quite a bit shorter than the one Brave uses and the extensions-install-verification switch is not part of Vivaldi's parameter list: --new-window --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=SecurePaymentConfirmation --save-page-as-mhtml

EDIT: The extensions-install-verification parameter apparently got added in Brave 0.68. So I decided to test Brave 0.67.125 against Brave 0.68.131 (both were stable releases) and I can now confirm that extension sideloading broke with Brave 0.68 when this commit got merged into the stable branch.

@esjarc you're correct - I definitely got that wrong ☹️ Brave is doing this on purpose; thanks for flagging the PR/commit. The enforce argument was added by @jumde in the commit you shared

@Nuc1eoN I updated my comment above since I was definitely wrong about that and then updated our deviations wiki page to specifically include this (search for Specific features are disabled on startup via the CLI ):
https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#what-chromium-features-are-removed-for-privacysecurity-reasons

edit: wiki update was backed out after finding we are matching Chrome behavior

With my confusion cleared up (apologies), the root cause for this issue seems very clear

I believe this enforce check is required in order for the extension block list we publish to be enforced. I could definitely be wrong about that too 😛 but the commit adding it references BravePDFDownloadTest.VerifyChromiumPDFExntension test failing which was checking an entry in the block list (ex: the code which loads the list and has allow/block functionality). We were using PDF.js at the time and have since removed that test (as we use PDFium now)

the original report which says that non-CWS crx files can't be loaded even when developer mode is enabled. this seems like a bug; if developer mode is enabled, you should be able to load extensions that aren't in CWS.

@diracdeltas would the ideal fix be to ignore the enforcement if developer mode is enabled (in brave://extensions)?

are users still seeing some kind of warning whenever developer mode is enabled? i have had an extension i made (that's not in CWS) installed for months without issue.

The warning is not enabled by default anymore. It was only showing before when we were using the TEST config. After we put the proper config in place the issue went away and #5063 was logged in case we did want to show a warning

@bsclifton yes, if my understanding is correct, the current behavior was an unintentional side effect of brave/brave-core#2471 and should be reverted to the behavior prior to 0.68.x

OK will prep a fix and create a security review to accompany, in case there was a reason for it 😄 Thanks!

edit: looks like it was already modified to be enforce instead of strict... 🤔 This should be working...

Will review with @jumde and report back
https://github.com/brave/brave-core/blob/cf8219a0571c83c5eaaac9b382189d79c2c02670/app/brave_main_delegate.cc#L166-L173

Exciting to see this make progress after 2 years.

@rushilsrivastava happy to help move things along 😄

I'm not able to get this working in Chrome. Maybe folks can help me double check I did this right?

1. Have latest Chrome stable installed (version 89.0.4389.90)

2. downloaded chromium-cleaner (thanks for the example @esjarc)

3. destroyed the profile directory for Chrome (%USERPROFILE%\AppData\Local\Google\Chrome) so that we'd have a fresh profile.

4. visit chrome://extensions/

5. drag the chromium-cleaner.crx extension from desktop onto the chrome://extensions page

   At that point, I see this in the bottom left of the window:
   

6. If I hit Continue, the following will show up in the top of the window and it doesn't load
   

7. I flipped on Developer mode (top right), re-ran the steps 5 and 6, and I get the same thing
   

It does look like we are matching what Chrome is doing, which is consistent with the comments here:
https://github.com/brave/brave-core/blob/cf8219a0571c83c5eaaac9b382189d79c2c02670/app/brave_main_delegate.cc#L166-L173

Here's a link to the Chromium code for where kExtensionContentVerification is evaluating as strict:
https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/extensions/chrome_content_verifier_delegate.cc;l=73-130;drc=75b4a953c8bd85166ef652d2b8ed724e709c86f7

#if BUILDFLAG(GOOGLE_CHROME_BRANDING)
  experiment_value = VerifyInfo::Mode::ENFORCE_STRICT;
#else
  experiment_value = VerifyInfo::Mode::NONE;
#endif

Here's a link to the Chromium code for where kExtensionsInstallVerification is evaluating as enforce:
https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/extensions/install_verifier.cc;l=70-87;drc=5626c75beba7258d28f23fd7964258334616f97f

if (!InstallSigner::GetForcedNotFromWebstore().empty())
    return VerifyStatus::ENFORCE;

GetForcedNotFromWebstore is where CLI (and probably group policy) can override the list of extensions allowed. More info about that work-around here.

Because you can see a difference above (Chrome using ENFORCE_STRICT, Chromium using NONE), I downloaded latest stable Chromium (not Chrome) and tried it too (version 89.0.4389.90). I get the exact same behavior there too:

It seems I'm back to square one. I was originally sharing that we are doing the same as Chromium (which is what I honestly believed) and after verifying right now, it does appear this is the case. I am on Windows 10 x64 (20H2) for what it's worth. Is there something I'm missing?

If you have gotten this working on official builds of Chrome/Chrome Canary/Chromium did you have to do anything special?

@bsclifton I can't reproduce your results. One possible explanation I could come up with: When you drag the extension into the browser window you have to wait until a grey overlay appears (if it doesn't try to move your mouse around a bit). Once the overlay is displayed you can drop the extension into the browser and the installation dialog appears. If you don't wait for the overlay, the browser treats the extension as a file and downloads it instead and that could be what happened to you?

I have now tested the following browsers on Ubuntu 20.04 (could this have something to do with differences between builds for different operating systems?): Brave 1.22.70, Chromium 91.0.4460, Google Chrome 89.0.4389 and Vivaldi 3.7.2218 and both extensions (chromium-cleaner, Chromium Web Store) are working fine under Chromium, Chrome and Vivaldi. The only browser blocking these is Brave. All browsers were tested with an active internet connection and with a clean profile. I did the following: Install the browser, open each browser, go to chrome://extensions, enable Developer Mode, drag and drop the crx file from the file manager into the extensions page and confirm the installation with "Add to Browser".

The results under Windows are actually quite a bit different: Google Chrome and Microsoft Edge disable the sideloaded extensions, but Chromium and Vivaldi leave them activated.

@esjarc thanks for the detailed information - it must be platform specific. I tried on Ubuntu 18 and confirmed Brave doesn't load (doesn't matter if in dev mode or not). Chrome however DOES work in dev mode. I can look at solving this problem- looks like we unintentionally are not matching Chrome for some reason on Linux

Quick update - I created a separate issue for how we're not matching Chrome/Chromium on Linux:
#15024

Thanks @esjarc for helping ID the bug there 😄 That issue aside, we should be matching Chrome/Chromium and not doing anything intentional.

I have a pull request open solving the Linux issue (see brave/brave-core#8392) which is going through security review. I also raised this overall issue (being able to install signed CRX which are not in store) with the team too - they're going to evaluate the ask in this issue too.

We usually try to match Chromium - but this will become a larger issue when manifest v3 comes into play (which we aren't going to do, as far as I know). Stay tuned for comments from security folks

@bsclifton Good to see progress on this issue, thank you for taking the time to review this issue and its comments here and creating a fix for this regression!

Personally I would like to see a switch (e. g. a flag in chrome://flags) to disable the enforcement mode for extensions. Firefox for example already has a similar preference in its about:config menu called xpinstall.signatures.required (not all Firefox builds honor this setting, but the ESR and Developer Edition and many stable non-ESR builds for Linux do). Normal users would still be protected from potentially malicious extensions, but advanced users (those that actually know that chrome://flags exists) wouldn't need to create policies with administrative privileges first.

Curious if folks would be able to get this working with the steps shared in https://developer.chrome.com/docs/extensions/mv3/external_extensions/ (the path would be different for Brave; BraveSoftware\Brave instead of Google\Chrome for example)

edit: just now saw above in post by @esjarc that it does indeed work! Sorry I had missed that
#2457 (comment)

OK folks - thanks for your patience on this 😄

I reviewed this issue with security/privacy folks here at Brave we agreed on the following plan:

1. The deviation from Chrome/Chromium was fixed with Match Chromium behavior for extension loading brave-core#8392. This was not something we intentionally did - thanks to all that helped narrow this down 😄 We should be the same as Chrome/Chromium now. The next Nightly build (1.25.x, will be available by tomorrow 8 April) will have this fix and it will propagate through the channels. It should hit Release channel on 25 May (2021).
2. Support-wise, @Brave-Matt updated our help article (you can view here) to include a link to Chromium's documentation for Alternative extension distribution options. This is the officially supported approach for signed CRX files not in the store
3. I created a new issue for a "Brave Extension Store", available here: Brave Extension Store #15187. This is something we had considered in the past and would be a way to offer extensions which are not in the official Chrome Web Store. Comments extremely welcome! 😄

Given the above plan, we agreed to close this issue (offering an in-app way to bypass the security check; ex: feature flag) as wontfix. Per one of our engineers:

The downside of a feature flag is that a malicious extension could change that too since they're both located in the profile directory. The group policy/allowlist method at least requires admin access, which a malicious extension hopefully doesn't have otherwise you're in deep trouble.

I know this isn't the solution everybody wants - I championed the best I could. However, I am glad we:

• did find where we had a mistake on our side and were able to fix that (Linux w/ dev mode on should work)
• were able to update our help article to link to the official Chrome/Chromium recommended approach
• created an issue to explore a Brave store which deviates from Chrome Web Store