Question about Chrome Extension change to protect Windows users

[Scott Cressler]

In this blog post, there is reference to still being able to install an extension on Windows that is not in the Chrome Web Store while in Developer mode or if you "install via Enterprise policy".  We have an extension that is only used internally, but not by all users on all systems, so I don't think the Enterprise policy applies.  But since it is only intended to be used internal to our company (it is of no value and won't work for other users), I'm not sure it makes sense to put it in the Chrome Web Store.

The blog post also mentions something about "You could keep the extensions hidden from the Web Store listings if you like." but there is no more elaboration on that.  Can you point me to the place in the publishing process where it describes how to do that?  That might solve our need.  I found discussion of "Publishing to test accounts", but this implies there is a limited (and explicitly listed) set of test accounts to which you can publish.  We basically want to make the extension available to any internal users who are interested.

Can you explain how I can achieve this once you make this change?

Thanks.

[Antony Sargent]

There are now a few options in the webstore for limiting who can access an item you've published. You can limit it to just people with the link, just people in your Google Apps Domain (if you're using one), or a test of trusted testers as defined by membership in a Google Group you manage. From the developer dashboard, check out the "Visibility options" at the bottom of the page when you are editing the properties for one of your entries in the store. 

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/184f34a3-fbee-4467-9f7c-d4c7d3d5577c%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Neil Stoker]

Thanks Antony, that's useful.

But just to be absolutely clear, in the latter two options (for people in domain or trusted testers) some untrusted person with the link wouldn't be able to get at the code for the extension from the store or is it merely that they couldn't install it?

I appreciate the reasons given for this change but it's actually quite a pain, as at my company we're in a similar position as Scott but would rather not expose an internal only extension to the outside world. I suppose there is obfuscation, but are there any other approaches that could be recommended for those concerned with privacy? (Ie some way to keep more of the workings internal only?)

[Tim Robinson]

I agree. I can partly understand the reasons for this change, but it seems Google are just another company living in the consumer-only world and ignoring corporates. The client side of my enterprise application is an MSI file that installs all the pieces needed to get it going, including add-ons for the popular browsers which is required for some of the functionality. A lot of my users prefer to use chrome but don't have access to the app store, but their employers don't have the kind of enterprise policy infrastructure that would allow them to roll out the plugin automatically.

Recently we have been recommending chrome because it's more performance and standards-compliant than IE, and doesn't have the plugin version compatibility issues of Firefox. From next year, it looks like they'll have to go back to IE again.

Well done Google, it's not easy to shoot yourself in the foot worse than Microsoft these days but you've somehow managed it :-(

--- Tim

[Antony Sargent]

But just to be absolutely clear, in the latter two options (for people in domain or trusted testers) some untrusted person with the link wouldn't be able to get at the code for the extension from the store or is it merely that they couldn't install it?

I believe what happens is that someone with the URL but not in the domain / trusted testers list would get an error page if they browsed to the URL. However, because we do autoupdate requests without sending any cookies, in some cases if someone knows the id of the extension they may be able to get a copy of it by crafting a fake autoupdate check. (However if they have access to a computer where it is installed to find out the id, they could get a copy the contents from the user profile directory anyway). 

 

I appreciate the reasons given for this change but it's actually quite a pain, as at my company we're in a similar position as Scott but would rather not expose an internal only extension to the outside world. I suppose there is obfuscation, but are there any other approaches that could be recommended for those concerned with privacy? (Ie some way to keep more of the workings internal only?)

Sorry this is a pain for you! We very reluctantly came to the decision to add these restrictions after analyzing data showing rapidly increasing numbers of windows users being plagued by unwanted force-installed extensions. (The problem is that the bad actors doing the force installs are rewriting users' preferences files behind their back after killing chrome to make it look like they opted in to the install when they didn't)

To summarize, the restrictions will only apply to Windows chrome stable/beta users, and the set of available options will be:

-Users installing from the webstore via the regular chrome.google.com/webstore page, or inline install from pages a developer controls. The items here can be unlisted (effectively hidden from public view) and additionally shown but just to domain users or trusted tester groups.

-Enterprise policy, specifically the ExtensionInstallForceList or ExtensionInstallWhitelist values. 

-Unpacked for development

We really wanted to limit the scope of the change to just where the problem is, so we don't plan to enforce these restrictions to the dev or canary channels, the open-source chromium builds, or to chrome on OSes other than windows. Again, I really wish we didn't have to make the tough choice between leaving large numbers of our user base at risk or making life more difficult for some legitimate developers like yourself. We'll continue to try and find technical solutions that would be hard for the bad actors to exploit but give flexibility for cases like yours, but so far we haven't come up with anything that achieves that.

Could you elaborate on why using enterprise policy would not work for you?

[PhistucK]

Will drag and drop into chrome:extensions continue to work?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CALwaUNKJF1NCdVL1QaLX8jCNNeNL2Vdkqce%2BBgRji7HBtH%2BCHw%40mail.gmail.com.

[Antony Sargent]

Hi Tim-

We agree that it sucks that we have to do this, and will cause difficulty for some legitimate use cases like yours. The problem is that the bad actors have shown themselves willing to modify state on the users machine to make it look to the chrome binary like the user opted in to installing something they actually didn't want. Several of us have spent a lot of time thinking the issues through but so far we haven't figured out good ways to protect users that don't involve verification with some trusted source external to the user's machine (eg the webstore or enterprise policy config). 

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c0a73e07-9ddc-4197-a0e6-bc468fd2d073%40chromium.org.

[Antony Sargent]

Drag and drop of .crx files will only work for items that can be verified to be from the allowed sources of webstore or enterprise policy (otherwise bad actors could simply write your preferences file to make it look like you did a drag install). 

[PhistucK]

Will there be a flag for disabling these restrictions?

Will --easy-off-store-extension-install continue to be available and also disable these restrictions?

☆PhistucK

[Antony Sargent]

Unfortunately it's also easy for bad actors to update chrome shortcuts to set command line flags. 

[Tim Robinson]

Thanks for the response Antony. It's great to have a huge "faceless" supplier come back and at least justify these kind of actions, something which never happens with MSicrosoft (e.g. dropping the skype API). You could probably tell I was a bit p***ed when I found out about this yesterday morning but I'm pragmatic now and at least I'm not worried about the confidentiality and Intellectual property of my code which is clearly worrying some people

[Tom Moore]

Hi Antony,

From your response I understand that the new changes will disallow changing the preferences file.

My problem:

I own an add-on that changes the user's homepage (after receiving full consent from the user for that change), and I do that by changing the preferences file.

My add-on is very legitimate, and the homepage is a major part of it (allowing the user to socially interact with his via the homepage, and see a feed of their friends' shares), and therefore, the add-on will lose a lot of users if it wont be able to 'touch' the preferences file.

What will I be able to do in order to keep my add-on running?

Are you going to block changing the preferences file completely or just the part that allows malware and adware force themselves into chrome?

Thanks in advance!

Tom

[PhistucK]

See https://plus.google.com/+FrancoisBeaufort/posts/9QsLx1rF2hq.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5a5f62d0-e6b5-430f-800b-61b7b031e882%40chromium.org.

[Simon B.]

The timeline is very questionable.

If you an extension with NPAPI-plugin, you are kind of screwed.

According to "Saying Goodbye to Our Old Friend NPAPI" :

"The Chrome Web Store will also be phasing out NPAPI support. Starting today [Monday, September 23, 2013], no new Apps or Extensions containing NPAPI-based plug-ins will be allowed in the Web Store."

So I can't put it in Chrome Web Store and my customer can't install it...

For my self, I've planned to switch with an other technology before September 2014 to respect NPAPI-phase-out timeline, but not as soon January 2014! I don't have time and man power to do it.

[Tim Robinson]

hmm I just saw this.

my plug-in absolutely has to use windows APIs to access shared memory - don't ask why :-(

But If I can't use NPAPI are there any other options open to me?

[Antony Sargent]

Hi Tim-

Did you see the pointers at the bottom of the blog post on NPAPI for the technical alternatives, including NaCl, Chrome Apps, and the Native Messaging API? If you don't think any of those will work for your use case, please start a new discussion thread and give some more details about your use case and why you don't think any of those would work, and we can help you explore possible approaches, possibly including designing new extensions/apps APIs. 

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/3e2f8918-969e-4646-888e-3ead283d8bf8%40chromium.org.

[Neil Stoker]

Hi Antony,

Thanks for the response. The concern with the Enterprise settings is mainly one of practicality - the extension tool being developed is useful to my team, but I am unlikely to win over our central IT people to make a change specifically for us; we don't usually operate with that level of fine grained control over those sort of settings (there are areas where levels are fine grained, but the overall profiles are typically fairly uniform).

You could make the case that we're not making sufficient effort, or if it were important enough, we'd change, however the world is full of things that fall in this category, and it's just a shame we have lost something that didn't actually seem that broken to me.

I'm sure you've got great people running over the options, so I feel a hesitant to suggest it, but is there no way to sign the collection of extension settings and then simply compare the stored signature at start up against the files? (ie so you know the bad actors haven't fiddled with them). And if it's on a machine that's so compromised, is the upcoming change not just rearranging the chairs on the Titanic? Not much reassurance for those in sea-worthy vessels!

Kind regards,
Neil

[samroth]

First of all, a shout-out to Google: GOOD JOB GUYS! Thanks for helping with protecting your users!

I've been a victim of an ad-injecting add-on that was added to all of my browsers without my consent.

Frustrated of that - as a web developer, and as someone who considers himself a power-user, I started digging into this subject - while testing all kinds of downloads from various download sites on different environments/OS's (real ones, as well as virtual), and found out to my surprise that this plague is ALL OVER the internet, and is widely spread, as well as some more very interesting findings that I still investigate.

I look forward to see how Google's blessed changes will affect the world of bundled add-ons - although I understand that unfortunately, some innocent and legit add-ons will suffer from this change.

I'm now writing a detailed research that I intend to publish very soon with all of my findings about the industry of ad-injecting add-ons (If anyone's interested - I'll update this thread with it soon with an early draft of the research).

Is there anyone here that can share some more technical details about the future changes? will the preferences file be encrypted, for instance?

Thanks!

[Adrian Aichner]

On Tue, Nov 12, 2013 at 2:16 PM, samroth <samro...@gmail.com> wrote:

First of all, a shout-out to Google: GOOD JOB GUYS! Thanks for helping with protecting your users!

 

I'm now writing a detailed research that I intend to publish very soon with all of my findings about the industry of ad-injecting add-ons (If anyone's interested - I'll update this thread with it soon with an early draft of the research).

Is there anyone here that can share some more technical details about the future changes? will the preferences file be encrypted, for instance?

Which preferences exactly?

 

Thanks!

 

-- 

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/99c5c50b-ce5a-4d45-b114-43409dffebdb%40chromium.org.

[Tim Robinson]

I must admit I didn't pay too much attention because when we've looked at this before (with Chrome and Firefox) you needed NPAPI to make Windows API calls.

Sure enough NaCl and Chrome Apps don't get me anywhere but it looks like the Native Messaging API will allow me to do what I want. I can write a small executable which does the Windows API part for me and talk to that through the shared messaging. It seems pretty secure too (because an attacker would have had to have already installed an executable on the machine in order to be able to attack it through a native messaging plugin) so I'd hope that google won't be removing this API in the near future at least.

[samroth]

@Adrian,

Chrome's preferences file.

In my research, I found out that changing it allows silently adding extensions to chrome, without the user's approval

On Tuesday, November 12, 2013 3:29:09 PM UTC+2, Adrian Aichner wrote:

On Tue, Nov 12, 2013 at 2:16 PM, samroth <samro...@gmail.com> wrote:

First of all, a shout-out to Google: GOOD JOB GUYS! Thanks for helping with protecting your users!

 

I'm now writing a detailed research that I intend to publish very soon with all of my findings about the industry of ad-injecting add-ons (If anyone's interested - I'll update this thread with it soon with an early draft of the research).

Is there anyone here that can share some more technical details about the future changes? will the preferences file be encrypted, for instance?

Which preferences exactly?

 

Thanks!

 

-- 

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

[Adrian Aichner]

On Tue, Nov 12, 2013 at 3:20 PM, samroth <samro...@gmail.com> wrote:

@Adrian,

Chrome's preferences file.

In my research, I found out that changing it allows silently adding extensions to chrome, without the user's approval

Ah, that is the "Preferences" file found in the "Profile Path:" as found in

chrome://version/

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/06dacf65-5f21-4800-b47f-23f57cabe742%40chromium.org.

[Tim Robinson]

Thanks Serge,

My chrome plug-in is part of a larger client-side install for my application which we deliver as an MSI. It's all windows-specific and needs to be installed by an administrator so no worries on that account. This definitely seems like the best solution for me.

BTW your message didn't seem to go onto the mailing list. I'm not sure if this reply will???

--- Tim 

On 12 November 2013 15:15, Serge Strukoff <serge.s...@googlemail.com> wrote:

Sure enough NaCl and Chrome Apps don't get me anywhere but it looks like the Native Messaging API will allow me to do what I want. I can write a small executable which does the Windows API part for me and talk to that through the shared messaging.

NaCl doesn't have access to the system. You can't call native system functions directly, for example use Win32 API. So NaCl is like native javascript, and all your code runs in Google's sandbox.

Native Messaging Host - Limited users can't install native messaging host, because your installer need to write to the HKLM registry hive to register your host with Chrome, to do that an user need run your installer with admin privileges. If you have a big user base, you will lost many users.

Also, you can't install an extension and native messaging host at once, you need to write your own custom native installer and updater for every platform Mac, Win, Linux. Moreover, this is not cross-browser solution.

P.S As a result, browsers based on Chromium are stuck at v.25 and not updating their products. 

As a result, many users are moving to the alternative small browsers and IE, just see at counterstats.

[Antony Sargent]

Thanks for the response. The concern with the Enterprise settings is mainly one of practicality - the extension tool being developed is useful to my team, but I am unlikely to win over our central IT people to make a change specifically for us; we don't usually operate with that level of fine grained control over those sort of settings (there are areas where levels are fine grained, but the overall profiles are typically fairly uniform).

You could make the case that we're not making sufficient effort, or if it were important enough, we'd change, however the world is full of things that fall in this category, and it's just a shame we have lost something that didn't actually seem that broken to me.

Are you referring to the difficulty of getting them to set up chrome policy at all? Or adding specific ids to the ExtensionInstallWhitelist?

 

I'm sure you've got great people running over the options, so I feel a hesitant to suggest it, but is there no way to sign the collection of extension settings and then simply compare the stored signature at start up against the files? (ie so you know the bad actors haven't fiddled with them). And if it's on a machine that's so compromised, is the upcoming change not just rearranging the chairs on the Titanic? Not much reassurance for those in sea-worthy vessels!

 Yes, we have definitely agonized about the trade-offs given that we can never completely defend against determined attacks running at the same (or even higher) OS privilege level. But we're working on a variety of techniques that we think will help, and given how widespread we've seen the problem become, we felt we had to act. 

[Antony Sargent]

Sure enough NaCl and Chrome Apps don't get me anywhere but it looks like the Native Messaging API will allow me to do what I want. I can write a small executable which does the Windows API part for me and talk to that through the shared messaging. It seems pretty secure too (because an attacker would have had to have already installed an executable on the machine in order to be able to attack it through a native messaging plugin) so I'd hope that google won't be removing this API in the near future at least.

We definitely plan to continue supporting native messaging going forward.

 

[Mihai Coman]

Hi Anthony,

Based on the announcement and discussions I've seen so far, I understand that installing extensions through Windows Registry, as outlined here, will no longer work since the .crx file had to be installed, as part of a larger application install, on disk. I'm in the same boat as others here as we have to support fairly large numbers (thousands) of clients that rely on our native app and it's associated Chrome extension. Asking the clients to a) install our kit and b) go and manually manage the installation of the extension (used to be part of the kit) is quite a big issue.

A couple of questions:

1. would it be possible to retain the registry mechanism but require that instead of a local/share path, the registry key value should contain the extension id (from Chrome Web Store) or the whole link to the extension URL in the store? I suppose this approach would solve all the security concerns you guys have while still allowing an application to install extension as part of the application install process without us having to educate users on how to go though a few additional steps required to manually install the extension.

2. do you plan to update the extension developer documentation any time soon with relevant info on what mechanism still apply when installing extensions?

On Saturday, November 9, 2013 1:02:19 AM UTC+2, PhistucK wrote:

Will drag and drop into chrome:extensions continue to work?

☆PhistucK

On Sat, Nov 9, 2013 at 12:53 AM, Antony Sargent <asar...@chromium.org> wrote:

But just to be absolutely clear, in the latter two options (for people in domain or trusted testers) some untrusted person with the link wouldn't be able to get at the code for the extension from the store or is it merely that they couldn't install it?

I believe what happens is that someone with the URL but not in the domain / trusted testers list would get an error page if they browsed to the URL. However, because we do autoupdate requests without sending any cookies, in some cases if someone knows the id of the extension they may be able to get a copy of it by crafting a fake autoupdate check. (However if they have access to a computer where it is installed to find out the id, they could get a copy the contents from the user profile directory anyway). 

 

I appreciate the reasons given for this change but it's actually quite a pain, as at my company we're in a similar position as Scott but would rather not expose an internal only extension to the outside world. I suppose there is obfuscation, but are there any other approaches that could be recommended for those concerned with privacy? (Ie some way to keep more of the workings internal only?)

Sorry this is a pain for you! We very reluctantly came to the decision to add these restrictions after analyzing data showing rapidly increasing numbers of windows users being plagued by unwanted force-installed extensions. (The problem is that the bad actors doing the force installs are rewriting users' preferences files behind their back after killing chrome to make it look like they opted in to the install when they didn't)

To summarize, the restrictions will only apply to Windows chrome stable/beta users, and the set of available options will be:

-Users installing from the webstore via the regular chrome.google.com/webstore page, or inline install from pages a developer controls. The items here can be unlisted (effectively hidden from public view) and additionally shown but just to domain users or trusted tester groups.

-Enterprise policy, specifically the ExtensionInstallForceList or ExtensionInstallWhitelist values. 

-Unpacked for development

We really wanted to limit the scope of the change to just where the problem is, so we don't plan to enforce these restrictions to the dev or canary channels, the open-source chromium builds, or to chrome on OSes other than windows. Again, I really wish we didn't have to make the tough choice between leaving large numbers of our user base at risk or making life more difficult for some legitimate developers like yourself. We'll continue to try and find technical solutions that would be hard for the bad actors to exploit but give flexibility for cases like yours, but so far we haven't come up with anything that achieves that.

Could you elaborate on why using enterprise policy would not work for you?

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

[Konstantin Boykov]

Hi Anthony,

Will non-webstrore extensions installations alive after 1Jan 2014, or it will be removed/set off?
Whether I will be able to update this extension after 1Jan 2014? 

Can I migrate to webstore, keeping all users, installed the extension?

[PhistucK]

You need to upload your extension to the Chrome Web Store (with your key.pem in the root of the ZIP file, in order to maintain the same ID), update your (own hosted) manifest with an updated update_url value -

update_url: "https://clients2.google.com/service/update2/crx"

I suggest you start the process now.

Non web store installation will be disabled or removed (not sure, but probably removed) once the said update kicks in. I am not sure you will be able to update your extension (not even just for updating the manifest with the new update_url) then, so just do that as soon as possible.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/7bf6462b-1cf5-42c8-8b87-9503b81fae28%40chromium.org.

[Ng Yik Phang]

Developers will still be able to load their unpacked extension for development, right?

Then what if the attackers also trick Chrome to load an unpacked extension? After all, they most likely have Windows admin access and can easily adjust Chrome's raw settings file.

Also, can't the attacker also silently install Chrome dev to bypass this blocking restriction?

I know that this is a tough decision to completely block all non-store extensions, but I just feel that this only slows down the persistent attackers and ending up inconveniencing/frustrating legitimate developers.

For some miraculous reason, modern versions of Internet Explorer has become much more resistant to toolbars/add-ons/search engine changes, I have no idea what Microsoft done to become more resistant. Perhaps the Chrome team could do some research and apply it to Chrome in some way?

- Ng

[PhistucK]

Yes, they could, but a prominent warning would be shown (Antony stated that).

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/ddb44686-b85f-422b-9b3a-f73b8844418b%40chromium.org.

[Antony Sargent]

It's already possible to install with an autoupdate url pointing at the webstore using the "external_update_url" in a preferences file (just give it a value of "https://clients2.google.com/service/update2/crx") which we plan to continue to support, and we have a bug that we'll soon fix to make this work for the registry also. 

We'll be updating the documentation soon. 

[Antony Sargent]

See https://groups.google.com/forum/#!topic/chromium-extensions/3vvygtEajMQ on how to migrate an extension to the webstore in a seamless way for your users, including keeping the same id.

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/7bf6462b-1cf5-42c8-8b87-9503b81fae28%40chromium.org.