Unable to find such extension in the Chrome Web Store. Do other extensions experience similar problems? Does it work properly in a new Chrome profile?

I have only one extension.
I send you link on my extension. 
https://chrome.google.com/webstore/developer/edit/fgdfkgijmihakgkpgfihkhoflogmiphp?hl=en
see attached files

now there is a problem only chrome 53 x32 version. 53 x64 works greate.

3. if I remove "key": "MIIBIjANBgkqh...." ket from manifest then the extension loadable.

Try to load antCH.crx from attachment.
Thanks

Deleted: c1.png 41.2 KB

	c1.png 41.2 KB View Download

Deleted: c2.png 21.7 KB

	c2.png 21.7 KB View Download

Deleted: c3.png 112 KB

	c3.png 112 KB View Download

If  tag "key" replaced by key from another extension then my extension is loaded.
I think Google Chrome have blocked the extension!
What is the reason of blocking the extension?

 Issue 643932  has been merged into this issue.

Chrome on Windows and OSX has code that enforces that all normally installed extensions (eg not loaded in developer mode) were installed from the chrome webstore, and that their contents on disk have not been tampered with by comparing against a list of file hashes signed with a webstore private key. In chrome 53 we tightened things up to be a little more strict - it had been possible to bypass the checks by claiming a version number higher than the webstore had seen before. 

In your case, the extension in the .crx file you attached claims to be version 0.2.0.5 of the extension with id fgdfkgijmihakgkpgfihkhoflogmiphp, but the webstore has never seen that version and doesn't have any signed file hashes for it, so the extension won't run. 

For more background on why we added these protections, see:

http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html

1. the version 0.2.0.5 was uploaded a webstore 5 days ago https://chrome.google.com/webstore/developer/edit/fgdfkgijmihakgkpgfihkhoflogmiphp?hl=en
but chrome 53(x32) still doed not load extension.
does chrome compare a extension by version number of by control sum?
2. I even cannot load unpacked extension in developer mode.

What steps must I do for fixtion of promlem?

maybe I have to install own extension only from a webstore?
how to debug it if I cannot load it in developer mode??

This bug affects HTTPS Everywhere and Privacy Badger from the Chrome website.

See: https://github.com/EFForg/https-everywhere/issues/5874

https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp?hl=en

Version on my computer: 2016.9.1
Version on Web Store:  2016.9.1

sorry, do not understand.
is the wrong posts?

Hi, I have the same problem on Ubuntu x64 with HTTPS Everywhere. Even the version in the Chrome Web Store is disabled immediately when I install it.

How do you decide a problem?
Do you usually update an extension in a webstore? 
I am not. Now updated, status pending...

This issue also affects Browsing Protection and Search extensions of F-Secure security products. I reported this initially to Google forums:

https://productforums.google.com/forum/#!topic/chrome/vIn3YPHpgL8;context-place=forum/chrome

After updating the extensions to latest ones in Web Store, the situation should be now ok for our users that haven't yet upgraded Chrome to 53, but the remaining question is how to fix the situation for users that are experiencing this "corrupted extension" scenario? Currently it seems that even when the extension is updated automatically to the one in Web Store, it does remain in "disabled & corrupted" state in browser, i.e. the option to enable extension is greyed out. Visiting extension's Web Store page does show a flyer "This item has been disabled in Chrome." with link "Enable this item". Clicking it will enable the extension in browser. However, we have a huge amount of really nontechnical customers, so instructing them all to click some link in some web page is not really an option.

Does this happen because the extension is in some way blacklisted? If so, is there any way to programmatically, or from Web Store db to remove this blacklisting for all users? Or is this "permanent disabled state" a bug in Chrome?

Probably it is the reason

https://productforums.google.com/forum/#!topic/chrome/vIn3YPHpgL8;context-place=forum/chrome
Antony Sargent:
Hi Jouni - sorry for the inconvenience. We did change the code in chrome 53 to be more strict about checking for exact file contents matching against the webstore, because we found evidence of unwanted software abusing the loophole you describe, so we made chrome insist on being able to read signed file hashes that are signed with a private key during the webstore publishing process. 

I my extension never keep in a Web Store because it build-in my software.
Today I updated it version in a Web Store and it  has a pending  status now.
I can't load it in developer mode. I am thinking how it debug now...

You should always be able to load an unpacked extension in developer mode - this means going to the chrome://extensions page, clicking the "Load unpacked extension.." button, and choosing a folder with your extension source in it. Are you saying that following these steps, you still cannot load the extension?

For HTTPS Everywhere & Privacy Badger, the relevant bug has been filed and assigned to the Chrome security team:

https://bugs.chromium.org/p/chromium/issues/detail?id=643814

This unfortunately is not visible by everyone, I mention it here as a convenience for the chromium maintainers.

to asargent@chromium.org

I am developer really I know as do it. See attached image.
I have a few test computers and chromes. The extension is a lodable in developer mode on chrome where I write to you. Another chrome (x32) does not accept my extension but before the extension of a release version was instelled on it.
If I remove "key": "MIIBI...." from manifest then the extension is loadable.

Deleted: 2.png 70.1 KB

	2.png 70.1 KB View Download

One more question I do not understand NOW how must I install my extension antCH.crx if an extension  is builb-in the sofware and binded with it? 
The extension does not work offline .

Re comment #18 - by any chance do you happen to have the extension installed both from the .crx file (which is disabled) *and* via the load unpacked method? That might explain the behavior you're seeing, since specifying the "key" field forces an extension loaded in development mode to have a specific id (corresponding to the public key given in the "key" field of the manifest). See https://developer.chrome.com/extensions/manifest/key for a little more information. That being said, it's definitely a bug that we even allow this - if there already is an extension installed with a given id, we should not allow loading for development extension source that also wants to have that same id. 


Re comment #19 - the only supported options for installing extensions are:

a) Users manually choose to install via the item's page on the webstore

b) Inline install - see https://developer.chrome.com/extensions/webstore#method-install

b) Native software can trigger auto-install of an item hosted in the webstore, but the user has to opt-in before the extension will actually run. Documentation for how to do this is at: 

https://developer.chrome.com/extensions/external_extensions#registry (windows)
https://developer.chrome.com/extensions/external_extensions#preferences (osx/linux)

to asargent@chromium.org, 
Re comment #18 this contradiction of your proposal
https://bugs.chromium.org/p/chromium/issues/detail?id=643814
Comment 9 (b) 
Besides, I cleared the database of chrome, remove all extensions

to asargent@chromium.org

Now works in this scheme https://developer.chrome.com/extensions/external_extensions#registry 
but my package does not contain verified_contents.json file (as you wrote https://bugs.chromium.org/p/chromium/issues/detail?id=643814). what will be the reaction of chrome on it?

Sorry, I should have been clear that by "supported options for installing extensions" I was referring to how an extension can be distributed to end users. 

For development, you should use the load unpacked option on chrome://extensions, and while we generally recommend *not* having a "key" field in your manifest to force it to load with a particular id unless you have a particular need for testing with that id (eg something like cross-extension messaging that depends on particular ids), in general it should work. But it sounds like you've tried this on a clean chrome profile and found that it still doesn't work? Can you include a .zip file of the directory that you were trying to load unpacked?

to asargent@chromium.org

Yes, without "key" it's worked!

--- Can you include a .zip file of the directory that you were trying to load unpacked?
Sorry, I do not understand. What's the point of this?

> What's the point of this?

I may have misunderstood you, but I thought in comment 21 you indicated that you tried loading the unpacked extension (which still had the "key" field in the manifest) and it didn't work. I couldn't think of a reason it should fail other than (a) you somehow already had an extension installed with an id corresponding to that public key which was already disabled due to corruption, or (b) a bug in chrome. Since it sounds like you were using a clean profile, (a) seemed unlikely so that points towards (b) so I wanted to see if I could reproduce the problem and fix any possible bug. 

asargent@chromium.org thank you very much for your help!

In now moment I have email from chrome a web store - my extension was deletedbecause of the conflict an extension with chrome policy (My extension helps download video). It's a current problem.

Can you tell me where to email on this issue?
the back email does not work.

You can contact webstore support via this link: https://support.google.com/chrome_webstore/contact/developer_support/