4 ms·

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 uploa

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). [0] https://github.com/milesrichardson/crxmon https://github.com/milesrichardson/crxmon

thisislife2 3y ago
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.
- croon 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - ozim 3y ago
    My bet is that code on its own with due respect is most likely easy to replicate. Couple months of dev work and most likely done. User base and trust doesn’t work that way. I cannot hire 10 devs to replicate years of building trust and brand reputation. My idea is that non-nefariously buyer discounted code part and valued trust and user base.
    - nemomarx 3y ago
      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.
      - dkh 3y ago
        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.
        bombcar 3y ago
        Even if you try to keep it known, it’s easy enough to have an LLC own the extension and keys, and then sell that LLC. And if you tie it to individuals, then an extension is transferred every time a new employee replaces an old.
- geoelectric 3y ago
  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.
  - Ajedi32 3y ago
    > a notice dialog enforced by the browser popping up to tell the user the ownership changed and offering them a chance to uninstall Couldn't the extension do that itself? Why does it need to be a browser feature? Edit: Quoted portion of comment I was responding to.
    - dotproto 3y ago
      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.
      - Ajedi32 3y ago
        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".
- LtWorf 3y ago
  Isn't Opera chinese owned these days? I interviewed at their office and at the time their business was to use the high user count the browser had on mobiles in africa to push microcredit.
  - eru 3y ago
    > Isn't Opera chinese owned these days? Opera is a public company. Almost all public companies have shareholders from all over the world, including China. https://en.wikipedia.org/wiki/Opera_(company) https://en.wikipedia.org/wiki/Opera_(company) has some details. EDIT: that Wikipedia article says Opera is indeed a public company, but it's only indirectly publicly traded via a chain of parent companies.
    - wil421 3y ago
      The CEO and Co-CEO appear to have Chinese names, same with the parent company listed in your wiki link.
      - pastacacioepepe 3y ago
        So what? The CFO is Norwegian. Since the CEO of Wikipedia is Egyptian born, would you define Wikipedia as Egyptian owned? Note that Egypt is a US backed dictatorship.
      - eru 3y ago
        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.)
      - pastacacioepepe 3y ago
        [flagged]
        seanmcdirmid 3y ago
mellutussa 3y ago
If someone is buying your extension with wicked, dark and nefarious intentions, he's gonna want the private key too. Pretty much everyone is going to agree, with the only individual difference on how much you have to pay.
- LtWorf 3y ago
  Why does nobody ever propose these deals to me? :(
qwertox 3y ago
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?
- chatmasta 3y ago
  > 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. [0] https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Su50pbNzRms/m/VbQhXEnkAwAJ https://groups.google.com/a/chromium.org/g/chromium-extensio... (note the "You don't need to repeat this procedure ever again") [1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b7641bad491834df00669764be568e/scripts/lib/extension-crypto.ts https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...
thwarted 3y ago
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.
- deleted 3y ago
  [deleted]
- coryrc 3y ago
  IIRC Google does the build, so they need the private key to sign the resulting binaries? Edit: I'm probably thinking of Android and they'd probably sign with their own key.
- chatmasta 3y ago
  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}
dotproto 3y ago
> 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.

thisislife2 3y ago

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.

croon 3y ago
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.
- deleted 3y ago
  [deleted]
- ozim 3y ago
  My bet is that code on its own with due respect is most likely easy to replicate. Couple months of dev work and most likely done. User base and trust doesn’t work that way. I cannot hire 10 devs to replicate years of building trust and brand reputation. My idea is that non-nefariously buyer discounted code part and valued trust and user base.
  - nemomarx 3y ago
    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.
    - dkh 3y ago
      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.
      - bombcar 3y ago
        Even if you try to keep it known, it’s easy enough to have an LLC own the extension and keys, and then sell that LLC. And if you tie it to individuals, then an extension is transferred every time a new employee replaces an old.
geoelectric 3y ago
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.
- Ajedi32 3y ago
  > a notice dialog enforced by the browser popping up to tell the user the ownership changed and offering them a chance to uninstall Couldn't the extension do that itself? Why does it need to be a browser feature? Edit: Quoted portion of comment I was responding to.
  - dotproto 3y ago
    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.
    - Ajedi32 3y ago
      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".
LtWorf 3y ago
Isn't Opera chinese owned these days? I interviewed at their office and at the time their business was to use the high user count the browser had on mobiles in africa to push microcredit.
- eru 3y ago
  > Isn't Opera chinese owned these days? Opera is a public company. Almost all public companies have shareholders from all over the world, including China. https://en.wikipedia.org/wiki/Opera_(company) https://en.wikipedia.org/wiki/Opera_(company) has some details. EDIT: that Wikipedia article says Opera is indeed a public company, but it's only indirectly publicly traded via a chain of parent companies.
  - wil421 3y ago
    The CEO and Co-CEO appear to have Chinese names, same with the parent company listed in your wiki link.
    - pastacacioepepe 3y ago
      So what? The CFO is Norwegian. Since the CEO of Wikipedia is Egyptian born, would you define Wikipedia as Egyptian owned? Note that Egypt is a US backed dictatorship.
    - eru 3y ago
      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.)
    - pastacacioepepe 3y ago
      [flagged]
      - seanmcdirmid 3y ago

mellutussa 3y ago

If someone is buying your extension with wicked, dark and nefarious intentions, he's gonna want the private key too. Pretty much everyone is going to agree, with the only individual difference on how much you have to pay.

LtWorf 3y ago
Why does nobody ever propose these deals to me? :(

qwertox 3y ago

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?

chatmasta 3y ago
> 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. [0] https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Su50pbNzRms/m/VbQhXEnkAwAJ https://groups.google.com/a/chromium.org/g/chromium-extensio... (note the "You don't need to repeat this procedure ever again") [1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b7641bad491834df00669764be568e/scripts/lib/extension-crypto.ts https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...

thwarted 3y ago

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.

deleted 3y ago
[deleted]
coryrc 3y ago
IIRC Google does the build, so they need the private key to sign the resulting binaries? Edit: I'm probably thinking of Android and they'd probably sign with their own key.
chatmasta 3y ago
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}

dotproto 3y ago

> 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.