The extension ID is derived from a private key that the developer uploads with the first upload to the app store, and the ID will change if any subsequent uploads include a different key.pem in their zip file (but if there is no key.pem then the extension ID will remain the same).
Therefore, if the extension ID changes, it's possible the owner changed. However, it's also of course possible (and even likely) that the original owner might transfer the private key to the new owner. And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
I find the extension ecosystem fascinating and I'm also working on some tools for this space ([0]: warning, WIP hobby code). For example, I want to create a GitHub repo that targets a specific extension, tracks its updates, and pushes each one as a change to the repo. And then I can run static analyzers on the code after each update, and also some runtime taint analysis I've been experimenting with (e.g. tracing user inputs into dangerous sinks like eval or postMessage).
One of my Opera (Presto web engine, European owned) extension was featured on the front page and became very popular. Somebody wanted to purchase it from me for a good amount. During the negotiation, I said I would take down the extension and provide all source code to them so they could distribute it themselves. They said they expected me to hand over my Opera extension account credential too to them. Long story short, I backed out.
So yeah, I support your assertion that while something like this is somewhat useful, a better thing would be some kind of malware scanner for extensions.
Unfortunately, it probably even makes sense that they'd want that for non-nefarious reasons.
If you shut down your extension and they had to put up their own copy, they'd have to re-acquire your installed base. That could be a sharp decline in value to them, particularly if the extension mostly got popular off a one-time front-page feature rather than via gradual discovery with active word of mouth.
The chance that people jump through all the hoops to impulse-install again twice is low. They'd have to really like your extension, even if your version notified them of shutdown of yours and availability of the new one. Growing an installed base is generally more a factor of not chasing your users away than explicitly doing things to retain them. That change would chase them away.
In an ideal world, you'd be able to officially transfer the single extension to a new owner while keeping all the installed users--preferably with a notice dialog enforced by the browser popping up to tell the user the ownership changed and offering them a chance to uninstall. That would also chase some users away, but it's sort of the ethical minimum (hence this HN post).
But I doubt many browsers, if any, work like that.
True, I understood that the userbase was more important to them as my extension code was already released under GPL open source license. I was concerned about the following:
1. It was a grey area if the Terms of Service allowed such transfers of Opera account.
2. I had many other extensions that were being distributed through the same Opera account.
3. My suggestion to them was that I would release a new version of the extension from my account that explicitly informs the user of the change of ownership, and also inform them to install the extension from the new owners Opera account. They weren't interested in that.
> Couldn't the extension do that itself? Why does it need to be a browser feature?
The reason for wanting such notifications in the first place is because new owners often do dodgy things, and a company that specialises in buying up popular extensions and cramming them full of spyware typically doesn't want you to know about the change of ownership.
So extension authors can't be relied upon to provide this feature. The ones you particularly want to know about go out of their way to hide their involvement.
But then wouldn't those new owners just avoid the notification entirely by buying the original developer's account so there's no way to tell that ownership changed? I'm pretty sure that's how it usually works already, so any notification system would necessarily have to be voluntary.
To my knowledge no browser supports transferring an extension's user base from one extension to another. If you want your users to switch, the only think you can do is show them a link of where to get the new extension they should install.
The GGP suggested "officially transfer the single extension to a new owner" which you can obviously already do (by giving the new owner your account, if nothing else), and "tell the user the ownership changed and offering them a chance to uninstall" can already be done by any extension that has any sort of UI. You don't need to "[transfer] an extension's user base from one extension to another".
The extension could do that itself, but it's possible that the new owner of the extension has hijacked the extension or otherwise has nefarious intent. Forcing the browser to announce this change alerts the user of this possibility.
Almost all public companies have shareholders from all over the world, including China.
While Opera might not be a Chinese company in the strictest definition, over 50% of Opera's shares are owned by their Chinese parent company, and by all accounts around 80% of the shares still seem to be in control of the Chinese conglomerate that owned Opera before it went public.
You might want to stress that Opera is Chinese-controlled then; which is different from Chinese-owned.
(Eg Google is controlled by its founders, who still have the majority of share voting rights and are in power as executives. But it's not majority owned by them anymore.)
Did Zhou Yahui buy a bunch of shares in Opera? Otherwise, I don't know why he would be CEO of that company (as a billionare). Ok, from his wiki page:
> The next month, a consortium of investors including Beijing Kunlun acquired Opera Software with Beijing Kunlun acquiring 48%, effectively granting ownership to the company (and Zhou Yahui) by majority.[12] Zhou has served as chairman and CEO of Opera since 2016.[4]
> In 2016, Opera was acquired by an investment group led by a Chinese consortium.[7] On July 27, 2018, Opera Limited went public on the Nasdaq stock exchange, raising $115 million in its initial public offering.[8] Opera is a subsidiary of Kunlun Tech Co., Ltd., and controlled by Zhou Yahui.[9]
So they bought it, and then they sold some of it (that's what an IPO is).
What's important here is the last sentence with 'controlled by', which is in practice more important than ownership.
While I too would back out from anything requiring giving away credentials, is there no other way to transfer ownership? A charitable interpretation could be that they wanted to also buy the "popularity" of the extension simply for discoverability.
But it's equally easy to envision nefarious reasons of course.
Should you be able to transfer trust and userbases that way? It feels like usually acquisitions trying to do this create a worse experience for users in some way or another.
This is a good point, and transferring of trust is a very interesting concept. But while I agree that these things shouldn’t necessarily be silently transferable, I also think there should be an easy way to onboard users to the new owner/extension (if they wish to) without having them need to think about it and manually go figure it out. It shouldn’t be silent, but it also shouldn’t be a pain. Acquisitions do often make things much worse eventually for users, but negating this by complicating the process of retaining them (especially if they want to be retained) isn’t great, either.
The extension ID is derived from a private key that the developer uploads with the first upload to the app store, and the ID will change if any subsequent uploads include a different key.pem in their zip file (but if there is no key.pem then the extension ID will remain the same).
the original owner might transfer the private key to the new owner. And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
This isn't how PKI works. Is this really an accurate description of the way private keys are used for Chrome extensions? That you're supposed to provide the private key in a PEM file when you upload the extension?
The developer should be signing the extension/manifest with the private key and sharing the public key/including the public key in the upload. Updates should continue to be signed with the private key, and as long as the key doesn't change, the original public key from the original upload can be used to verify that the same private key was used to sign -- if the public key is included or not on subsequent uploads is immaterial. Yes, the developer could sell/share the private key with someone else, thereby allowing someone else to provide a legit, signed update, but that's the risk (to the user of the extension/message recipient) of the signer not keeping their private key private. Sharing the private key with Google, or anyone, undermines provenance of the extension. Sharing the private key with someone else wouldn't be detectable, because use of the private key to sign is the method by which the identity of the source is established.
The problem is that this isn't just a code signing system. In a code signing system, the public key would be tied to a developer, and they could rotate their private key to sign their app. But in this case, the extension ID itself is tied to a (private) key, so it's not even possible for the developer to rotate their key without changing their extension ID, which breaks existing installations and breaks interoperability
for code that expects the extension pages at chrome-extension://{extensionID}
In a code signing system, the public key would be tied to a developer, and they could rotate their private key to sign their app.
That's also not how PKI works. The private key and the public key are tied together, by the very math that defines public/private key cryptography. There is no situation where a private key can be changed and the associated public key does not change. Are you confusing public keys with certificates?
It makes sense that the extension id is/could be tied to a keypair: that forces a change in identity of the source of the extension if the key changes. However, that's not very extensible or pragmatic, so I suspect that the extension is identified by a field in a certificate, the certificate is signed by Google, the certificate is assigned/tied to a developer, and that would allow the certificate fields to stay constant while allowing the keys to be rotated.
> Are you confusing public keys with certificates?
No. If you include a key.pem file (private key) in your .zip on first upload, then the extension ID is derived from the public key which is derived from the private key. This is an RSA keypair, there is no certificate involved, and the process to generate the extensionID is well known (hex encoding of first 32 characters of the public key). [0] The chrome team signs the .crx file, so they need the private key to do it.
However, AFAICT, this is _optional_ (and also poorly documented, so probably also discouraged). You can choose not to submit your zip with a key.pem file, in which case I presume Google will use a more modern PKI approach on their backend. But they still don't give you the private key.
As an extension developer, the reason you want to upload the key.pem yourself is so you can know the extension ID before you publish it, which might be important if your extension contains code that references that ID (e.g. checking Origin of a postMessage is chrome-extension://{yourId}).
Disclaimer: I haven't published an extension, so this is based only on reverse engineering and reading the threads in the extension developers Google Group.
But if the extension ID changes, you'd need to explicitly install the new version. It wouldn't just auto-update.
Then again, you say:
> And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
How is this even possible that Google allows this? Is this really true?
I mean, Google is such a PITA with their Webstore for the smallest possible things, but that is something they don't care about?
I have three extensions which I have only released for testers, where I am the sole tester of the extensions, so that I can easily install them on my different machines without having to rsync/robocopy them and enable developer mode.
This weekend Chrome decided to disable all these extensions on just one machine, because "This extension is not listed in the Chrome Web Store and possibly has been added without your knowledge". I can't override and force-enable it, when I go to the web store it says it's "inactive" and gives me the option to "activate now", but "activate now" only removes the banner and re-shows it after a reload. That Chrome profile is signed in with the whitelisted account.
This happens with just one browser, my main one on my main machine, signed in with the tester account.
The badge on the CWS page claims that the developer (me) has a positive balance without any strikes. I mean, I wouldn't be able to see the page if I weren't logged in with the my whitelisted email.
They "care so much" but then they allow updates without the key?
> How is this even possible that Google allows this? Is this really true?
Yes, you only need to upload the key (meaning, include a `key.pem` in your packed zip file) on first upload. [0]
However, I'm not sure if Google will allow you to upload with a _different_ key. Since that would cause the extension ID to change, I'm not sure what would happen, both to the webstore page (does the previous one 301 to the new one?) and to existing installations (do they stop auto-updating?).
Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key.
> This weekend Chrome decided to disable all these extensions on just one machine
There is a trick for this, if you are loading an unpacked extension. Simply edit `manifest.json` in the unpacked extension directory, to add a `"key": "<base64 encoded public key>"`, where that public key matches the public key associated with the extension from the store. You can do this with any extension from the store, since you can extract the public key from a .crx file [1]. When you load an extension this way, the ID will be the same as the "real" extension.
Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key.
They don't want someone to "lose their extension" if the private key is lost? That makes no sense and completely undermines using PKI in the first place. This isn't how "code signing" is supposed to work _at all_.
> The extension ID is derived from a private key that the developer uploads with the first upload to the app store
While what you described is possible, this process isn't required or the typical way an extension ID is generated. Typically developers just upload a ZIP file on their first submission, then CWS will generate and store a private key to sign the extension for public distribution.
> and the ID will change if any subsequent uploads include a different key.pem in their zip file
CWS should never change an existing extension's ID. The ID is what I uniquely identifies an extension. If the ID changed, Chrome clients wouldn't be able to request an updated version of that extension. CWS & Chrome do not support migrating users from one extension to another.
To the best of my knowledge CWS will reject an extension if the zip after the first submission contains a key.pem file.
> Therefore, if the extension ID changes, it's possible the owner changed.
If the extension ID changes, it's not the same extension.
> then the new owner could push changes without even needing access to that key.
This is mostly true, but there is one case where developers CANNOT update an extension without the PEM: if the dev signed the extension they submitted to CWS. To be honest I'm not even sure this is possible to do any more; as I recall this feature was a huge foot-gun and often ended up causing developers to lose their install base because they lost their private keys that they used to sign their own uploads.
Therefore, if the extension ID changes, it's possible the owner changed. However, it's also of course possible (and even likely) that the original owner might transfer the private key to the new owner. And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
I find the extension ecosystem fascinating and I'm also working on some tools for this space ([0]: warning, WIP hobby code). For example, I want to create a GitHub repo that targets a specific extension, tracks its updates, and pushes each one as a change to the repo. And then I can run static analyzers on the code after each update, and also some runtime taint analysis I've been experimenting with (e.g. tracing user inputs into dangerous sinks like eval or postMessage).
[0] https://github.com/milesrichardson/crxmon