Question is if this extension detects having changed owners itself?
Maybe something else, not an extension, would be better suited for that kind of check, although of course more complex I guess.
This is how you make an extension that you can resell for big bucks. People looking to buy extensions will need to buy popular extension checkers first so they can do so undetected. /s
Won't the damage be done by the time you detect it? Extensions auto-update by default and there are only hacky ways to prevent this. This has always bothered me since just because I trust an extension now, doesn't mean I'll trust the next update that gets automatically applied.
At least I think it's pretty rare for a sold extension to be turn malicious in a way that it could do permanent damage, such as stealing your passwords. It's usually more along the lines of excessively invasive tracking or injecting their own ads; while I absolutely wouldn't want that normally, I probably wouldn't lose sleep over it if I learned that it had happened for 24 hours before I uninstalled the extension. That being said I would definitely like a better solution to this problem.
Unfortunately, it's been established for a long time now that users cannot be trusted to perform updates by themselves, no matter how naggy you get about it, even for the most critical of security fixes.
Automatic updates, again unfortunately, are critical to safety.
Users often don't want to perform updates because the updated version is worse in some way. That it has a security impact is unfortunate, but that's how it is.
I had an extension update itself and partially stop working. There's no way to go back to a previous version unless you happen to back up the old files.
And these automatic updates are often abused to remove or change features, or generally "enshitify" things. Which breaks trust and we are back to square one.
Find a way to do security patches without restarting the application or interrupting user's work, and keep featuers/enshittification updates separate from security patches - and then people will not mind auto-updates. Hell, you could just apply them and not even ask anymore.
This attitude is a large part of what I find so repulsive about tech today. You are a guest on my machine. No matter how much you think you know better than me (even if you're right!), you don't get to make decisions like that. You can ask nicely, and if you can convince me that something needs to be done, I will decide to do it.
Practically speaking, we have the choices that one monopoly or another offers us, and only so long as those choices are convenient for them.
I do avoid corporate overreach where it's practical (I have a dumb TV/vehicle/appliances/etc), but there will come a day when it's impossible to participate in society without giving in.
I'm happy enough with my life. But yours seems like a very ... I don't know, defeatist? point of view.
You make it sound like I can either have the stunted over commercialized shovelware thats on offer or I can choose to go live in a hut in the woods. Where's the middleground where we put a little market pressure on our corporate overlords so they make better widgets?
That being said, I really like VS Code's approach of having auto-updates enabled by default, but making a switch to turn off the feature available for nerds like us who care.
It has also been established that vendors cannot be trusted to refrain from bundling unwanted feature changes (and sometimes straight-up malware) with their security updates, so it's no wonder that users might be reluctant to install such updates.
Yes, this is the reason I do not enable automatic updates (in general, not just browser addons), and that software updates are so frustrating.
If there was a way to specify I only want security updates and bug fixes and I do not want new features, UI redesigns, and so on, I would always update and maybe even turn on automatic updates. Software companies have no excuse--we have sophisticated version control software that allows you to manage multiple branches easily. Every software should have a maintenance branch and a "new shit" branch, and should allow both kinds of updates.
Just FYI, for iOS updates, you can in fact opt into these release channels separately.
Go to Settings > General > Software Update > Automatic Updates. You will see two separate toggles, one for "iOS Updates" and another for "Security Responses & System Files."
> Unfortunately, it's been established for a long time now that users cannot be trusted to perform updates by themselves, no matter how naggy you get about it, even for the most critical of security fixes.
So let them not update. It's not your device, it's theirs. Mind your own business.
Problem is every single update claims to be security fixes, like for Android. Now I realise almost any bugfix can be construed as a security fix, but I've never seen an Android update that doesn't claim to include security updates, and I've never seen one that goes into any kind of detail(in the pop up prompt that is) on what any of the updates entail.
Probably some of those were critical, and some of them were completely unlikely to affect real world security. As a user, how do I know when to take it seriously and when not to? All I'm told by the UI is that every single update they push "improves security and performance".
This if the ToS problem. Tell me, of the many services you use and products you own, how many ToS have you read? 3%? 10%? Probably less than 2%. Changelogs and release notes have the same problem. They take time to create, edit and review and no one who matters reads them. Why would they spend their time on it?
I get your point, but changelogs can often be generated semi-automatically from VCS.
And I realise I'm not the typical user, but I actually do read(skim) TOS just to see if there's any centipad like stuff. Most of it is just boilerplate and you get pretty quick at finding the substantive parts with some practice. Of course TOS/EULA are hard to read for most people by design. They don't actually want you to read it. If they did, they'd offer a summarised version without all the legalese boilerplate.
I get the same feeling about changelogs. They probably have one internally if they know what they're doing. It may even be online somewhere if I go looking. I can only surmise that for whatever reason, they don't want me to read it, which doesn't inspire trust.
The trouble is, security fixes (generally) don't get backported to older branches. If older branches are even a thing.
Say you're on Foo 1.4.7, and the jump to Foo 1.5 includes a feature re-org you don't want, and no security fixes. So you hold your version on 1.4.7.
But then a security issue is found, and Foo 1.5.1 is released with a fix. Is the version you have vulnerable? Maybe, depending on where the bug is. Is there a 1.4.8 update to fix it? Maybe not. How would you even get it? Heck, if you've switched off automatic updates, have you even heard about the 1.5.1 release? Are you checking on the release announcements for Foo to find out if there have been any security updates, ever?
OK, maybe you check those things. But do you think J. Random User who saw a post on Reddit that said 1.5 sux0rz and they should stay on 1.4.x is going to? And do you like having botnets? Because that's how you get botnets.
The trouble is, security fixes (generally) don't get backported to older branches.
Even if the security fixes were backported, it would produce a new version of the older branch, and requires an update in order to actually use it. If the security fix is in an older branch or a newer branch doesn't matter: it still qualifies as an update.
Are outdated Chrome extensions really attack vectors? They're very sandboxed. I'd be way more concerned about the update itself being malicious, especially for simple extensions that shouldn't really need updates.
Pedantically, outdated Chrome extensions make for a poor attack vector in the first place because the majority of users get automatic updates, including being disabled/removed by Google themselves if the dev is gone and a problem is found.
Anyone who has had to administer anything user-facing will tell you that some users will ignore any warning. Updates need to be automatic and mandatory. You can give them a grace period, but you have to force the issue after a while, or users will delay the update prompt every 15 minutes for months.
If the software you are using is so bad, or the distributor so untrustworthy, that you would classify it as malware, then I think it is time to switch to an alternative.
For example, it is now quite feasible to use only open source software in everyday life, which usually operates according to better ethical principles and has greater difficulty in enforcing problematic changes.
The concern is that for a lot of software these days, it starts in the "good" bucket (and often open source even), and then once it gets popular, it is bought out and enshittified.
Yes, unfortunately this happens regularly, but with open source software it is at least possible to fork it. We often see forks when there are major disagreements. Not all of them survive, but if the original is bad enough, the chances are pretty good. There are also projects that are developed or supported by a trustworthy foundation/organisation, where you don't have to worry about such bad development.
Anyone who has owned a cloud connected device or software will tell you that companies cannot be trusted with remote access, they will abuse it every single time. And they'll have the useless cargo-cult security industry telling users that it's "best practice" and for our own good while their companies are spamming us or spying on us or removing features or outright hacking us or taking away access to our own data while they sell it to third parties and try to lock us into their ecosystem.
It was not my intention to defend large corporations and their sleazy practices. I just wanted to say that the average user cannot be trusted with an easy option to ignore updates, especially when it comes to security.
Users will do things like ignore updates and then trash you on the internet or spam your support because the software no longer works properly with service xyz. We regularly hear about major hacking incidents where internet-facing software hasn't been patched for years. Things like this will give your company a bad reputation.
I think the best compromise is to have automatic updates by default and a slightly hidden option in the menu to turn them off. If the user goes out of his way to turn it off, then it is his own damn fault, but if you make it too easy (like presenting it with every update prompt) you are courting disaster.
Nope, annoying forced update stuff goes in my trash. Already said bye bye to Windows for this reason. If your thing is gonna update itself, it can't disrupt me or make itself worse.
There should always be an option to turn off automatic updates (unless we are talking about a corporate network), but the option should be opt-in and require some initiative on the part of the user. If the option is presented together with a prompt to update, users will simply turn it off without knowing what they are doing.
If it is in an options menu, power users can choose to turn it off, but normal users will probably never find the option.
I agree for most software in general. Mac updates are auto by default iirc, and that's good. Just not Chrome extensions. The risk of attacks by the owner seems much higher than the risk of attacks by websites on outdated extensions.
And the problem with Windows is you can't really turn minor updates off, they require reboots, it nags you a ton about major ones, and the updates basically just make it worse.
I don't think manual updates would solve this security problem. The new owner would just have to delay the activation of the malicious parts of the software. No one is going to check the binary of an extension or try to replicate it if it is open source.
It's strange that Windows updates are still such a big problem, and I'm not talking about the ones caused by Microsoft's greed. Even Linux systems, which for a long time were pretty user-unfriendly, have largely managed to make updates seamless. I have automatic updates turned on on my computer, and the only indication is that once in a blue moon I can't turn the system off for a minute while it's running an update.
It wouldn't solve it, but at least an update couldn't get instantly pushed and run by all users. These extensions are JS rather than compiled binaries, so they're not too hard to inspect (and if the code is intentionally obfuscated rather than just minified, you know something is up).
If you want to limit the initial impact of a malicious extension, a mandatory hold or slow rollout would be more appropriate. There is no need to bother normal users if they would never inspect the code anyway. If some users want to inspect it first, they can go into the options and turn off automatic updates. Fixes for serious vulnerabilities that require immediate rollout are much rarer and often small, and could be reviewed by the extension store team.
I mean linux updates are everything but seamless, it highly depends on your exact config and distro, certain hardware configs break every single kernel version, hell even Nvidia would break they drivers super often not even that long ago. Smaller vendors with closed source drivers were even worse. Software just breaks sometimes no matter the amount of testing that you do. It's better just just accept that and deal with it when it comes up.
And in my experience (mostly server linux, client Windows/macOS) the worst updates are still macOS, they take for ever to install. Linux and Windows seem to at least install quickly, like a full upgrade takes less than 20 minutes on both, while a minor release for macOS will make my MacBook try to lift off like a jet engine for 45 minutes.
so when one software company does it to you it's good you say but when a different outfit does it goes in the trash. nice consistency you got there, bud.
Apple doesn't force the updates, Microsoft does. You can turn off automatic Mac updates, and even the automatic ones won't force reboot your machine while you have stuff open. And you aren't greeted with a "please switch to Safari" modal when it boots back up.
What's true about both is the updates require a reboot and take way longer than they should.
I mean macOS will spring the "Your computer will reboot within 60s" with the count down on you, if you don't watch out. And the "Reopen" feature only barely works.
Not every computer is a part of managed corporate inventory. And some suppliers will happily ignore any issues their updates are causing. E.g. forced Windows feature updates can just disable a computer by throwing out essential but unsigned drivers.
This is more of a technical problem. If your update either breaks something or leaves gaping security holes, then there is no good solution. I think I would rather inconvenience a customer by turning off functionality than leave a bad vulnerability unpatched, but delay an update if it is not security related.
I am shocked, people actually think that automatic updates are very good? Because for me, it is trivial that automatic updates are very bad. One of the greatest security risk of extensions are due to automatic updates, they can't be verified, since they change.
edit : BTW I've submitted a related submission about Guerilla Script, a userscript injecting engine, where userscripts are not even updateable: https://news.ycombinator.com/item?id=39620863 This is the ideal way of safe extensions IMO
I don't think anyone (at least not me) is claiming that auto-updates are very good. However, I will argue 'till the cows come home that they are better than the alternative in many cases.
Installing software in the first place is placing a lot of trust into whoever made that software from the get-go. There are a myriad of ways a bad vendor can abuse a software installation without having to involve auto-updates. Singling that as a specific abuse vector that's orders of magnitude worse than giving filesystem access to an opaque binary just doesn't make much sense to me.
If I don't trust a vendor enough to allow auto-updates, then I don't trust them enough to install the software in the first place (dev dependencies notwithstanding for obvious reasons). Combine this with the well known fact that optional updates just don't get installed, and the cost/benefit calculus of the feature becomes not that hard to motivate.
Fwiw, I also think that a switch to disable the feature should always be present for those of us who care.
I don't advise turning this on because I think automatic updates in most cases are preferred to manual updates for most users. However, in Firefox you can in fact disable automatic updates on a per-addon basis. So you can have the addons that you trust automatically update, but for the addons that you're less sure about or that basically already work, you can just turn off updates for them.
Just go to about:addons, click on the addon you want to change, and then swap "Allow automatic updates" to off. You can also change the default behavior to not automatically update except for individual addons that you override (although again, I don't recommend it for most users).
I don't believe you'll get notified about updates (correct me if I'm wrong), which isn't ideal, so you'll have to periodically go and check for updates yourself.
I believe Firefox at least alerts you when an extension update has changed the permissions it requests (and you need to accept the new permissions). Of course, there are many cases where malicious code doesn't require new permissions.
I'd also prefer more visibility into updates. Enabling auto-updates might be okay, if there's a way to opt out of it, and if the updates were significantly more visible. I want to see a big modal when one of my extensions has updated, and ideally I'd be able to see the diff of its source code. But even without that, just knowing it updated would be enough for me to unpack the CRX and check for myself (like I did when I installed it originally).
Disclaimer: I run exactly two extensions in my main browser: uBlock Origin, and Little Rat (monitors network requests of other extensions). I have a separate Canary browser for web development where I install other extensions I might need.
The ideal solution would be similar to when an extension asks for new permissions: disable it with a pop-up that informs you of the change and allows you to re-enable it.
Recently my favorite open source mouse gestures extension SmartUp Gestures was taken over by some shady entity (with github no longer being updated of course).
I opened Chrome ticket that they should ask to re-enable extension when ownership changes. They just closed the ticket replying with this link:
To combat this wouldn't malicious extension buyers simply keep the developer name the same? Or is developer name strictly policed by the Chrome Extension store?
They could just purchase Extension Author LLC with the extension being one of its assets, and there would be no need to notify Google of the change in control.
Also there's not much practical defense to an unscrupulous extension author "exiting" with an under-the-table password transfer or "oops we got hacked" to a shady buyer.
<tinfoil hat> One could imagine a nefarious state actor offering the author of e.g. uBlock $XX million to get access to a lot of browsers. Not sure about the economics, but more niche extensions could probably be targeted for a lot cheaper.
True, but at least it would require the exiting party to not have any illusions about what they are doing. I'd be surprised to hear that most extension takeover bids are open about their plans.
My guess is that most extension takeovers happen because the developer was making no money from the extension, not a lot of money at their dayjob, maintaining the extension was sucking up all their free time and maybe they also got an unexpected bill or were hurting for cash.
Not that those are good reasons to sell out your users, but they’re the kinds of circumstances that you can easily imagine happening.
Nothing of that changes their desire to avoid selling to the worst abuser. What circumstances can do is making them sell despite that despite.
That's why it's so important to have a clean handover way that does not involve handing over credentials: it allows circumstantial sellers to pick a least bad buyer, if it exists. The more visible the existence of a clean path (as in "advertised in the UI vs getting someone at Google on the phone") is the more difficult it becomes to pretend that the shady path is clean. There might even be some "conscience arbitrage", perhaps unintended: buyers who buy through regular handover mechanism, with a believable story of confidence in being able to make clean money (which they may or may not believe themselves), but who then sell dirty. Less money for the original dev, true, but at least there's one handover on record, eroding trust.
How many change detectors to mitigate against 51% attacks?
Realistically, even with this extension functioning as advertised, there are still plenty of related risks. E.g., a software company could disguise its motives early on and convert its product into malware at a later date, or the developer could be paid by a 3rd party to add certain features.
Pro tip: don't use chrome extensions. They are a trivial and huge security risk. Similar how random exe was some years ago, only much worse. Use tampermonkey scripts instead.
Tampermonkey scripts are
- open source and easily modifiable
- permissions are firmly controlled
- you can disable auto update
But I want to use extensions! Extensions do so many useful things that go beyond what scripts with fewer permissions can do. I want a utility that handles screenshotting sections of pages. I want a thingy that tracks the price history of products on Amazon so I know if something is real on sale or fake on sale. I want a thing that makes ssh sessions clickable for my weird internal ssh thingy. I want the stupid and experimental web mashup extensions that add weird stuff like "a chat room for every website you visit so you can chat with other people using that website." Well, okay, I don't want that last one, but I want it to exist.
The price for convenience is security. If you are willing to hand your digital life to others, you will gain the convenience that you seek. You are seeking to become a digital king by gaining digital servants that handle every aspect of your life. The day one of them betrays you, it will be painful for you at the very least
Fuck that. Pardon my language but that's a falsehood I am so sick of hearing repeated, and the only reason anyone believes it's an inevitable tradeoff is that this belief has been imposed on us by proprietary software ecosystems that have obtained the monopoly status needed to unilaterally reject competing models
The price for convenience and security being compatible is for these extensions to be auditable and for updates to be opt-in. Sure, someone could still install malicious updates under this model, but the value proposition of doing so scales with the number of people who care about the thing, and auditability allows experts who care about the thing to warn people if it does something suspicious, which also scales with the number of people who care about the thing
Not meaningfully. A tampermonkey script has complete access to the information in a webpage it runs in. This is necessary for its operation and not something I have a problem with, but I'd never say its an improvement in terms of security.
a closed source extensions plus a bunch of random scripts ("unpackaged extensions" essentially, by even less well known authors with no review anywhere) is not the win over extensions that you think.
Is this an issue that's worse for Chrome than for other browsers?
The only browser extension I use is HonorLock, an exam proctoring software that I'm required to use. Its extension is for Chrome only, so I use Chrome from time to time out of the requirement to use HonorLock. If I visit the install link in Safari, it tells me to install Chrome: https://app.honorlock.com/install/extension
I'm wondering if there's something unique about Chrome's extensions that both supports HonorLock's use case and makes this submission's linked resource more helpful.
Sounds like Chrome isn't their daily driver. Firefox blocks a lot of ads by default in Strict mode. That's what I use, so I haven't used AdBlock for a long time.
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.
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.
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.
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.
> 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.
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.
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.
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.
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, 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.
> 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.
Then I got a new machine and had to reinstall it. For the first time I had a look at those permissions. Insanity. It's only logical that it should be able to see what I see to block the ads, but I never stopped to think about that.
Safari has a special interface for content blockers to work without any permissions. They provide blocklists and the browser does the blocking itself. [1] Don't know if that's an option in Firefox.
(It's also the thing everyone is angry at Chrome for as their 'plan to kill ad blockers' by replacing the current blocking APIs with declarativeNetRequest.)
This is kind of an important point with Manifest V3: having more permission options is a good thing. It's good that declarativeNetRequest exists. Active Tab permissions are cool, I love being able to scope extensions to specific domains. Non-persistent background pages are a nice performance/security feature. The only problem with Manifest V3 is that Google is shutting down everything else and removing other APIs.
Safari's extension model kind of goes in its own direction, but it's based on similar principles to Manifest V3 and my contention with it is the same -- it's not a problem that you can build a permission-less adblocker in Safari, that's good. It's a problem that you have to, because getting rid of those permissions makes adblockers slightly less effective, which may or may not be worth it for every user. I can say with relative certainty that there is no adblocker on Safari that is as powerful as uBlock Origin on Firefox.
People bundle criticism of Chrome under the Manifest V3 label but aside from some more techy-type complaints around how Service Workers are being handled, in my experience at least a lot of Manifest V3 is really good. What's not good is that Chrome used Manifest V3 as an opportunity to get rid of a lot of other important APIs. So you don't see the same criticism levied at Mozilla because with Firefox you get most of the same benefits of Manifest V3 (and some additional benefits, Firefox's event-system is imo a better way to handle temporary background pages than Chrome's service-worker system) without the downsides of Chrome removing blocking web requests for the extensions that need them.
I'm using Manifest V3 for private extensions that I maintain for myself on Firefox. Manifest V3 is great and I enjoy trying to cut down my permissions as much as I can even though I'm basically just running the code myself. But none of my private extensions would work in Chrome or Safari or would be portable to either browser; they lack the APIs that I need and don't have any realistic equivalents.
The VPN can be configured to only send DNS requests (port 53). If necessary, you can also tunnel port 443 for requests to well-known DoH servers (though with a VPN going to the same local network as your DNS server, DoH seems unnecessary)
That's one of the reasons behind the permission changes coming in Manifest V3: to reduce what extensions have access to in the first place. Some extensions may be open-source and trustworthy but there are many that aren't and people seem to have trouble vetting them.
Note that a Piihole will not be as effective at blocking ads and trackers as uBlock Origin will be. But it's good to have the option for people who want it, different people have different risk profiles and concerns.
This is really useful, although, as another commenter said, this should be a built-in feature.
A question I got regarding this extension, as I didn't take a deep dive into the source code yet: Does it automatically notify you (not necessary in real-time but at least in startup) of ownership change or you need to manually trigger a check command?
"I think it would behoove Firefox and Chrome to change their policies around automatic extension upgrades in these scenarios: if an extension discloses a change in ownership, then upgrades should require user approval. If an extension fails to disclose a change in ownership, then users should be able to report it as malicious."
As a side note, probably the title should be prefixed by "Show HN"
Creator here. A check automatically runs every hour, and if there are any changes detected, a badge appears over the extension icon. I decided anything more than that was too invasive.
Are extensions allowed to disable other extensions? That seems like it would be a poor design. If the feature was part of the browser, then sure, but not as an extension.
Adding such a speed bump where the user must explicitly approve the upgrade because of a change of ownership of the company that provides it, would leak a fair percentage of the users. This would decrease the value of the product/company when sold. User friendly, but creator (who has bills to pay) unfriendly.
It seems fair for the browser to charge a fee (in the form of losing a percentage of users) in exchange for money earned by stealing data from users.
Creators do not get offered large sums of money by entities motivated by the desire to better serve the creator's users.
So yes, I agree that it would decrease the value of selling out. I see that as a good thing. It fights against what is currently killing the extensions ecosystem for everyone.
It'd be neat if there was a way to install an extension from git, including getting notified of updates and an easy way to install said updates. The current UX around installing extensions "out-of-band" is poor (in both firefox and chrome), I wonder what it'd take to improve things.
> The current UX around installing extensions "out-of-band" is poor (in both firefox and chrome), I wonder what it'd take to improve things.
The problem is that that experience isn't poor because of neglect, it's poor because you're intentionally not supposed to do that kind of thing unless you're developing and testing an add-on yourself.
(I don't know how Chrome arrived at that state, with Firefox the justification was that if the user can do that sort of thing [install random unsigned add-ons] easily, then so can ad-ware [browser toolbars and other spyware stuff].)
Tracking the ownership of your Chrome extensions sounds exhausting, especially if you're someone who just wants to surf the damn web and are not some kind of super nerd.
For Firefox extensions, Mozilla has a "recommended extensions program" [0] which involves "rigorous technical review by staff security experts" before extensions are included, but it's not clear from their support article if every update is reviewed before it's published.
If they do review every update, that would this problem at least for the more popular extensions, although I wonder how much delay it introduces when an extension needs an urgent security update.
It's almost as if you wish there was some kind of onerous "marketplace" where participation had rules and there was some kind of enforcement taking place, and organizations that break the rules could, no matter how popular or well known, be banned if they repeatedly violate the rules of the marketplace, or work to subvert the marketplace's function.
> Having a choice of marketplaces… imagine if Mozilla gave you that!
It sort of does, it's just not something devs take advantage of or that exists in an official way.
If you don't want to be listed in the addon store, you can do a signed addon that goes through a much less rigorous check and then distribute it however you want. Similarly within the addon store Mozilla has a concept of "vetted" and "unvetted" addons. You end up with roughly 3 layers of validation.
There's technically nothing stopping anyone from setting up a separate addon store using only the 1st-layer of validation (or even adding a wrapper around the 3rd layer of validation since it's all still ultimately XPI files). Automatic updates would even work, you can specify URLs to check updates from. I haven't fiddled around with it much though.
And sure, it would be nice to be able to skip even the 1st-layer signing when necessary, but what exists is still better than what a lot of other app-stores allow and in practice I suspect most addons aren't going to have trouble getting their stuff signed, so it's (likely?) not a huge deal if you wanted to make a 3rd-party store to require Mozilla-signed extensions. Maybe there's something I'm missing though.
Curation and integration by a trusted party is a valuable service, and I very much appreciate Mozilla, Debian and others doing this work and enforcing their inclusion policy, e.g. the Debian Free Software Guidelines and whatever Mozilla's technical review involves. Debian's onerous rules in particular are great for the user – I can rely on packages to be appropriately licensed, to receive security patches without breaking my system with incompatible changes, to be compatible with the rest of the packages in the distribution, etc.
Some important differences from "marketplaces" provided by various for-profit companies are 1) the user can choose whatever curator they wish, or opt to install whatever they want at their own risk; 2) the service doesn't usually involve payments, selling, shopping, etc. which would usually be associated with a marketplace.
Firefox has a marketplace with participation rules and enforcement where organizations that break the rules can be banned for violating them. That already exists.
They want something stricter. What they're asking for is the ability to have multiple marketplaces and validation measures, some of which have stricter rules than others. That these requests pop up in scenarios where marketplaces already exist suggest that singular universal marketplaces that attempt to be one-size-fits-all gatekeepers aren't scalable or sufficient to meet everyone's needs, and that a multi-marketplace setup would allow some of those marketplaces to offer stricter quality standards for the people who need them.
I get that you're jabbing at the Apple situation, but nobody has a problem with what you're suggesting. The problem arises when that is the only avenue to get onto a platform. Apple actively blocks sideloading and there's no way for a user to trust something that Apple has branded as "untrusted." Curation can coexist with untrusted code just fine, and in fact that's what Mozilla already does with their system mentioned in this thread!
I'm currently working on an extension as well ([0]) and share the same concerns many have mentioned about extensions here. I'd like to highlight another dimension concerning the Browser APIs ([1]).
Handling the permissions necessary for certain API functionalities and the corresponding warning messages can be somewhat confusing. For instance, our extension uses "chrome.devtools.panels" to open a new window within DevTools. This API doesn't require any permissions by itself. Yet, for messaging across the popup, content, and DevTools windows, we're required to use activeTab and sendMessage APIs. The DevTools window operates in its unique context, almost like a tab within another tab. For example, updating the URL in the active tab doesn't directly update the DevTools window but triggers an event.
Messaging across these different contexts requires the "https://*/*" host permission, without which Chrome and Firefox won't send the messages between these isolated windows.
We made this permission optional, the DevTools Panel is activated only upon receiving explicit user consent. However, the permission prompt's messaging is something like "This extension requires access to all your data," which sounds very alarming. We don't access any data nor that we want to, but requiring that permission is mandatory since the message APIs won't work without them.
This is just one example of the many undocumented complexities within Chrome's documentation. Similar pitfalls exist with message exchanges between the background service and content scripts. Sometimes you don't know why your API call doesn't work even though you think you have the required permission and asking for more permissions show very alarming messages to users.
I think that a more granular permission approach, made specific to API functionalities rather than broad permissions that cover a list of APIs, would significantly help user experience. For example, requesting permission for the "sendMessage API" with a clear explanation would be far more informative for users than the general "All host https:///" permissions.
There's also the issue of building for different browser. The same browser API calls can have different permissions requirement on Chrome and Firefox which makes the development process more difficult and more confusing for users since the same extension requires different permissions on different browsers.
I think this is illustrative of how the economy gets more scammy the faster and more secretly ownership of a product, company, or brand can change hands
To me, this cuts at a fundamental logic we take for granted in the paradigm of Intellectual Property: That a brand is a fungible commodity that can be sold, like any other good or service. We treat this as a transfer of ownership of some property, but I think it makes more sense to treat this as a form of fraud. A name or brand is a signal people and businesses use to indicate who made something, and its chief value is the trust that's been built by the people running whatever operation carries that brand. The fact that it is not only legal but common practice to buy a brand explicitly for this trust in the operation is, from my perspective, obviously a big part of why everything is so scammy
Wait till you see the brand landscape in groceries and consumer goods. A few companies owning hundreds[1] of brands of everyday items. What company is actually behind Brand X? You pretty much need a database/app to remember as you're shopping. This is likely done deliberately to obfuscate and confuse. I always thought it would be a sensible law to make a company that displays a brand on a product also display their company name as-or-more prominently next to that brand, so people know who is actually making those products.
Yes, I think consumer brands for things like food are exactly the way this trend started, and the aggregation of them has been gradual but led to lower quality and more scamminess throughout
> I always thought it would be a sensible law to make a company that displays a brand on a product also display their company name as-or-more prominently next to that brand, so people know who is actually making those products.
They should have to display the entire chain of companies in the corporate structure and, if it's too big to legibly fit on the package, you can't sell it.
Yes, it absolutely can. However, these decisions are more the rule than the exception in an acquisition or change of management, whereas people who set out to make things that get the good reviews in the first place will often value the effort they've put into the thing they've made, the reputation they've earned with it, their relationship with their customers, or even just take pride in making something well
Of course, perhaps it would be even rarer in a world whose incentives resisted "optimization" of this kind rather than actively encouraging it
I've also used Extensions Update Notifier [1] in the past, which has the option to disable extensions on every update. It hasn't been updated since 2016, but recent reviews say it still works. It doesn't detect ownership changes though.
It looks like the current code does. But this provides little assurance as the new owner could update the code to behave differently. Since the checks run after the update is installed, you can't rely on it.
300 comments
[ 0.21 ms ] story [ 395 ms ] threadAutomatic updates, again unfortunately, are critical to safety.
Critical to the safety of some site/other users? Then the problem is a bit deeper, as my computer/software shouldn't be able to affect someone else.
But automatic updates aren't for you or me, or any of the other geeks here.
They're for everyone else.
Fortunately, you have choices. You can choose to avoid software and operating systems that feature automatic updates.
You can even write it yourself, if you wish: You're absolutely empowered to be absolutely in control of your things.
There's nothing stopping you.
I do avoid corporate overreach where it's practical (I have a dumb TV/vehicle/appliances/etc), but there will come a day when it's impossible to participate in society without giving in.
There's plenty of ways to get through life that don't involve computers or software or television.
You can choose differently than you have.
You make it sound like I can either have the stunted over commercialized shovelware thats on offer or I can choose to go live in a hut in the woods. Where's the middleground where we put a little market pressure on our corporate overlords so they make better widgets?
You want software that doesn't update itself on your computer? Nobody is going to stop you. Simply make it so.
(And if you're happy with your life, then what are you here bellyaching about?)
That being said, I really like VS Code's approach of having auto-updates enabled by default, but making a switch to turn off the feature available for nerds like us who care.
That's the model to follow in my book.
If there was a way to specify I only want security updates and bug fixes and I do not want new features, UI redesigns, and so on, I would always update and maybe even turn on automatic updates. Software companies have no excuse--we have sophisticated version control software that allows you to manage multiple branches easily. Every software should have a maintenance branch and a "new shit" branch, and should allow both kinds of updates.
Just FYI, for iOS updates, you can in fact opt into these release channels separately.
Go to Settings > General > Software Update > Automatic Updates. You will see two separate toggles, one for "iOS Updates" and another for "Security Responses & System Files."
So let them not update. It's not your device, it's theirs. Mind your own business.
Probably some of those were critical, and some of them were completely unlikely to affect real world security. As a user, how do I know when to take it seriously and when not to? All I'm told by the UI is that every single update they push "improves security and performance".
And I realise I'm not the typical user, but I actually do read(skim) TOS just to see if there's any centipad like stuff. Most of it is just boilerplate and you get pretty quick at finding the substantive parts with some practice. Of course TOS/EULA are hard to read for most people by design. They don't actually want you to read it. If they did, they'd offer a summarised version without all the legalese boilerplate.
I get the same feeling about changelogs. They probably have one internally if they know what they're doing. It may even be online somewhere if I go looking. I can only surmise that for whatever reason, they don't want me to read it, which doesn't inspire trust.
Say you're on Foo 1.4.7, and the jump to Foo 1.5 includes a feature re-org you don't want, and no security fixes. So you hold your version on 1.4.7.
But then a security issue is found, and Foo 1.5.1 is released with a fix. Is the version you have vulnerable? Maybe, depending on where the bug is. Is there a 1.4.8 update to fix it? Maybe not. How would you even get it? Heck, if you've switched off automatic updates, have you even heard about the 1.5.1 release? Are you checking on the release announcements for Foo to find out if there have been any security updates, ever?
OK, maybe you check those things. But do you think J. Random User who saw a post on Reddit that said 1.5 sux0rz and they should stay on 1.4.x is going to? And do you like having botnets? Because that's how you get botnets.
Even if the security fixes were backported, it would produce a new version of the older branch, and requires an update in order to actually use it. If the security fix is in an older branch or a newer branch doesn't matter: it still qualifies as an update.
For example, it is now quite feasible to use only open source software in everyday life, which usually operates according to better ethical principles and has greater difficulty in enforcing problematic changes.
Users will do things like ignore updates and then trash you on the internet or spam your support because the software no longer works properly with service xyz. We regularly hear about major hacking incidents where internet-facing software hasn't been patched for years. Things like this will give your company a bad reputation.
I think the best compromise is to have automatic updates by default and a slightly hidden option in the menu to turn them off. If the user goes out of his way to turn it off, then it is his own damn fault, but if you make it too easy (like presenting it with every update prompt) you are courting disaster.
If it is in an options menu, power users can choose to turn it off, but normal users will probably never find the option.
And the problem with Windows is you can't really turn minor updates off, they require reboots, it nags you a ton about major ones, and the updates basically just make it worse.
It's strange that Windows updates are still such a big problem, and I'm not talking about the ones caused by Microsoft's greed. Even Linux systems, which for a long time were pretty user-unfriendly, have largely managed to make updates seamless. I have automatic updates turned on on my computer, and the only indication is that once in a blue moon I can't turn the system off for a minute while it's running an update.
And in my experience (mostly server linux, client Windows/macOS) the worst updates are still macOS, they take for ever to install. Linux and Windows seem to at least install quickly, like a full upgrade takes less than 20 minutes on both, while a minor release for macOS will make my MacBook try to lift off like a jet engine for 45 minutes.
What's true about both is the updates require a reboot and take way longer than they should.
I am shocked, people actually think that automatic updates are very good? Because for me, it is trivial that automatic updates are very bad. One of the greatest security risk of extensions are due to automatic updates, they can't be verified, since they change.
edit : BTW I've submitted a related submission about Guerilla Script, a userscript injecting engine, where userscripts are not even updateable: https://news.ycombinator.com/item?id=39620863 This is the ideal way of safe extensions IMO
Installing software in the first place is placing a lot of trust into whoever made that software from the get-go. There are a myriad of ways a bad vendor can abuse a software installation without having to involve auto-updates. Singling that as a specific abuse vector that's orders of magnitude worse than giving filesystem access to an opaque binary just doesn't make much sense to me.
If I don't trust a vendor enough to allow auto-updates, then I don't trust them enough to install the software in the first place (dev dependencies notwithstanding for obvious reasons). Combine this with the well known fact that optional updates just don't get installed, and the cost/benefit calculus of the feature becomes not that hard to motivate.
Fwiw, I also think that a switch to disable the feature should always be present for those of us who care.
Just go to about:addons, click on the addon you want to change, and then swap "Allow automatic updates" to off. You can also change the default behavior to not automatically update except for individual addons that you override (although again, I don't recommend it for most users).
I don't believe you'll get notified about updates (correct me if I'm wrong), which isn't ideal, so you'll have to periodically go and check for updates yourself.
I'd also prefer more visibility into updates. Enabling auto-updates might be okay, if there's a way to opt out of it, and if the updates were significantly more visible. I want to see a big modal when one of my extensions has updated, and ideally I'd be able to see the diff of its source code. But even without that, just knowing it updated would be enough for me to unpack the CRX and check for myself (like I did when I installed it originally).
Disclaimer: I run exactly two extensions in my main browser: uBlock Origin, and Little Rat (monitors network requests of other extensions). I have a separate Canary browser for web development where I install other extensions I might need.
I opened Chrome ticket that they should ask to re-enable extension when ownership changes. They just closed the ticket replying with this link:
https://chromium.googlesource.com/chromium/src/+/main/extens...
:(
<tinfoil hat> One could imagine a nefarious state actor offering the author of e.g. uBlock $XX million to get access to a lot of browsers. Not sure about the economics, but more niche extensions could probably be targeted for a lot cheaper.
Not that those are good reasons to sell out your users, but they’re the kinds of circumstances that you can easily imagine happening.
That's why it's so important to have a clean handover way that does not involve handing over credentials: it allows circumstantial sellers to pick a least bad buyer, if it exists. The more visible the existence of a clean path (as in "advertised in the UI vs getting someone at Google on the phone") is the more difficult it becomes to pretend that the shady path is clean. There might even be some "conscience arbitrage", perhaps unintended: buyers who buy through regular handover mechanism, with a believable story of confidence in being able to make clean money (which they may or may not believe themselves), but who then sell dirty. Less money for the original dev, true, but at least there's one handover on record, eroding trust.
Realistically, even with this extension functioning as advertised, there are still plenty of related risks. E.g., a software company could disguise its motives early on and convert its product into malware at a later date, or the developer could be paid by a 3rd party to add certain features.
Tampermonkey scripts are
Now it's no longer a good idea because that same browser is also:
- your bank,
- likely your point of contact with the government / tax folk
- the place you do your shopping
- the portal for most of your communications with the rest of the world
The price for convenience and security being compatible is for these extensions to be auditable and for updates to be opt-in. Sure, someone could still install malicious updates under this model, but the value proposition of doing so scales with the number of people who care about the thing, and auditability allows experts who care about the thing to warn people if it does something suspicious, which also scales with the number of people who care about the thing
TM still requires trusting their extension and script authors.
Not meaningfully. A tampermonkey script has complete access to the information in a webpage it runs in. This is necessary for its operation and not something I have a problem with, but I'd never say its an improvement in terms of security.
I don't know about chrome, but Firefox also allows automatic updates to be disabled on a per-extension basis.
I'm a fan of userscripts but lets not pretend they're magically better.
For example Firefox can't even control on which websites the extensions run. This is stupid and bad. Tampermonkey just does this thing right too.
Edge at least has an allowlist, if I'm not mistaken.
E.g. here's the "bypass paywalls" extension requesting permission to inject content scripts into particular domains sites: https://github.com/iamadamdev/bypass-paywalls-chrome/blob/c6...
The only browser extension I use is HonorLock, an exam proctoring software that I'm required to use. Its extension is for Chrome only, so I use Chrome from time to time out of the requirement to use HonorLock. If I visit the install link in Safari, it tells me to install Chrome: https://app.honorlock.com/install/extension
I'm wondering if there's something unique about Chrome's extensions that both supports HonorLock's use case and makes this submission's linked resource more helpful.
I also have a Pi-hole on my home network.
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
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.
But it's equally easy to envision nefarious reasons of course.
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.
And if you tie it to individuals, then an extension is transferred every time a new employee replaces an old.
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.
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.
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.
At the moment I don't believe any browser has features that notify end users of ownership changes.
[1]: https://support.google.com/chrome_webstore/contact/one_stop_... [2]: https://extensionworkshop.com/documentation/publish/add-on-o....
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.
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.
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) 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.
Since the CEO of Wikipedia is Egyptian born, would you define Wikipedia as Egyptian owned? Note that Egypt is a US backed dictatorship.
(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.)
> 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]
https://en.wikipedia.org/wiki/Zhou_Yahui
> 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 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.
Pretty much everyone is going to agree, with the only individual difference on how much you have to pay.
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?
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-extensio... (note the "You don't need to repeat this procedure ever again")
[1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...
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 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.
Edit: I'm probably thinking of Android and they'd probably sign with their own key.
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.
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.
[0] https://itero.plasmo.com/tools/generate-keypairs
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.
Then I got a new machine and had to reinstall it. For the first time I had a look at those permissions. Insanity. It's only logical that it should be able to see what I see to block the ads, but I never stopped to think about that.
Now I have a pihole and zero extensions.
https://developer.apple.com/documentation/safariservices/cre...
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Ublock Origin Lite uses it for example.
(It's also the thing everyone is angry at Chrome for as their 'plan to kill ad blockers' by replacing the current blocking APIs with declarativeNetRequest.)
Safari's extension model kind of goes in its own direction, but it's based on similar principles to Manifest V3 and my contention with it is the same -- it's not a problem that you can build a permission-less adblocker in Safari, that's good. It's a problem that you have to, because getting rid of those permissions makes adblockers slightly less effective, which may or may not be worth it for every user. I can say with relative certainty that there is no adblocker on Safari that is as powerful as uBlock Origin on Firefox.
People bundle criticism of Chrome under the Manifest V3 label but aside from some more techy-type complaints around how Service Workers are being handled, in my experience at least a lot of Manifest V3 is really good. What's not good is that Chrome used Manifest V3 as an opportunity to get rid of a lot of other important APIs. So you don't see the same criticism levied at Mozilla because with Firefox you get most of the same benefits of Manifest V3 (and some additional benefits, Firefox's event-system is imo a better way to handle temporary background pages than Chrome's service-worker system) without the downsides of Chrome removing blocking web requests for the extensions that need them.
I'm using Manifest V3 for private extensions that I maintain for myself on Firefox. Manifest V3 is great and I enjoy trying to cut down my permissions as much as I can even though I'm basically just running the code myself. But none of my private extensions would work in Chrome or Safari or would be portable to either browser; they lack the APIs that I need and don't have any realistic equivalents.
- make it the DNS for your wifi if your router can do that
- set Pihole to be the DNS for individual devices in their wifi settings if it can't
- create a personal VPN that uses Pihole as the DNS
A question I got regarding this extension, as I didn't take a deep dive into the source code yet: Does it automatically notify you (not necessary in real-time but at least in startup) of ownership change or you need to manually trigger a check command?
A few months ago, a story on this topic was trending: https://news.ycombinator.com/item?id=36233068
From the top comment of the above story:
"I think it would behoove Firefox and Chrome to change their policies around automatic extension upgrades in these scenarios: if an extension discloses a change in ownership, then upgrades should require user approval. If an extension fails to disclose a change in ownership, then users should be able to report it as malicious."
As a side note, probably the title should be prefixed by "Show HN"
The majority of owner changes are going to be malicious, so the action taken should account for that.
Creators do not get offered large sums of money by entities motivated by the desire to better serve the creator's users.
So yes, I agree that it would decrease the value of selling out. I see that as a good thing. It fights against what is currently killing the extensions ecosystem for everyone.
I don't use chrome though. I wonder how Firefox handles it.
The problem is that that experience isn't poor because of neglect, it's poor because you're intentionally not supposed to do that kind of thing unless you're developing and testing an add-on yourself.
(I don't know how Chrome arrived at that state, with Firefox the justification was that if the user can do that sort of thing [install random unsigned add-ons] easily, then so can ad-ware [browser toolbars and other spyware stuff].)
If they do review every update, that would this problem at least for the more popular extensions, although I wonder how much delay it introduces when an extension needs an urgent security update.
[0] https://support.mozilla.org/en-US/kb/recommended-extensions-...
- More malicious apps found in Mac App Store that are stealing user data - https://appleinsider.com/articles/18/09/07/more-malicious-ap...
- How 18 Malware Apps Snuck Into Apple's App Store - https://www.wired.com/story/apple-app-store-malware-click-fr... ...
A corollary… just because one piece of software has fewer reported CVEs, doesn’t mean it is more secure.
It sort of does, it's just not something devs take advantage of or that exists in an official way.
If you don't want to be listed in the addon store, you can do a signed addon that goes through a much less rigorous check and then distribute it however you want. Similarly within the addon store Mozilla has a concept of "vetted" and "unvetted" addons. You end up with roughly 3 layers of validation.
There's technically nothing stopping anyone from setting up a separate addon store using only the 1st-layer of validation (or even adding a wrapper around the 3rd layer of validation since it's all still ultimately XPI files). Automatic updates would even work, you can specify URLs to check updates from. I haven't fiddled around with it much though.
And sure, it would be nice to be able to skip even the 1st-layer signing when necessary, but what exists is still better than what a lot of other app-stores allow and in practice I suspect most addons aren't going to have trouble getting their stuff signed, so it's (likely?) not a huge deal if you wanted to make a 3rd-party store to require Mozilla-signed extensions. Maybe there's something I'm missing though.
https://extensionworkshop.com/documentation/publish/add-on-p...
> All add-ons are subject to these policies, regardless of how they are distributed.
and
> Add-ons with the sole purpose of promoting, installing, loading or launching an outside website, application or add-on are not permitted.
I believe the only way to bypass this would be to disable add-on signing in your browser, which is probably a bad idea.
Curation and integration by a trusted party is a valuable service, and I very much appreciate Mozilla, Debian and others doing this work and enforcing their inclusion policy, e.g. the Debian Free Software Guidelines and whatever Mozilla's technical review involves. Debian's onerous rules in particular are great for the user – I can rely on packages to be appropriately licensed, to receive security patches without breaking my system with incompatible changes, to be compatible with the rest of the packages in the distribution, etc.
Some important differences from "marketplaces" provided by various for-profit companies are 1) the user can choose whatever curator they wish, or opt to install whatever they want at their own risk; 2) the service doesn't usually involve payments, selling, shopping, etc. which would usually be associated with a marketplace.
They want something stricter. What they're asking for is the ability to have multiple marketplaces and validation measures, some of which have stricter rules than others. That these requests pop up in scenarios where marketplaces already exist suggest that singular universal marketplaces that attempt to be one-size-fits-all gatekeepers aren't scalable or sufficient to meet everyone's needs, and that a multi-marketplace setup would allow some of those marketplaces to offer stricter quality standards for the people who need them.
Currently my personal policy is to only allow those curated extensions to run on all sites/tabs.
Handling the permissions necessary for certain API functionalities and the corresponding warning messages can be somewhat confusing. For instance, our extension uses "chrome.devtools.panels" to open a new window within DevTools. This API doesn't require any permissions by itself. Yet, for messaging across the popup, content, and DevTools windows, we're required to use activeTab and sendMessage APIs. The DevTools window operates in its unique context, almost like a tab within another tab. For example, updating the URL in the active tab doesn't directly update the DevTools window but triggers an event.
Messaging across these different contexts requires the "https://*/*" host permission, without which Chrome and Firefox won't send the messages between these isolated windows.
We made this permission optional, the DevTools Panel is activated only upon receiving explicit user consent. However, the permission prompt's messaging is something like "This extension requires access to all your data," which sounds very alarming. We don't access any data nor that we want to, but requiring that permission is mandatory since the message APIs won't work without them.
This is just one example of the many undocumented complexities within Chrome's documentation. Similar pitfalls exist with message exchanges between the background service and content scripts. Sometimes you don't know why your API call doesn't work even though you think you have the required permission and asking for more permissions show very alarming messages to users.
I think that a more granular permission approach, made specific to API functionalities rather than broad permissions that cover a list of APIs, would significantly help user experience. For example, requesting permission for the "sendMessage API" with a clear explanation would be far more informative for users than the general "All host https:///" permissions.
There's also the issue of building for different browser. The same browser API calls can have different permissions requirement on Chrome and Firefox which makes the development process more difficult and more confusing for users since the same extension requires different permissions on different browsers.
[0] https://divmagic.com [1] https://developer.chrome.com/docs/extensions/reference/api
To me, this cuts at a fundamental logic we take for granted in the paradigm of Intellectual Property: That a brand is a fungible commodity that can be sold, like any other good or service. We treat this as a transfer of ownership of some property, but I think it makes more sense to treat this as a form of fraud. A name or brand is a signal people and businesses use to indicate who made something, and its chief value is the trust that's been built by the people running whatever operation carries that brand. The fact that it is not only legal but common practice to buy a brand explicitly for this trust in the operation is, from my perspective, obviously a big part of why everything is so scammy
1: https://capitaloneshopping.com/blog/11-companies-that-own-ev...
They should have to display the entire chain of companies in the corporate structure and, if it's too big to legibly fit on the package, you can't sell it.
1. Launch good product
2. Get good reviews
3. "Optimize" the design to use cheaper, worse components
4. Sell it under the same name
5. Coast on those good reviews and enjoy the higher profit margin
Of course, perhaps it would be even rarer in a world whose incentives resisted "optimization" of this kind rather than actively encouraging it
[1]: https://chromewebstore.google.com/detail/extensions-update-n...
A extension watcher is great but what happens when THIS extension itself changes owners?
Who watches the watcher?