Good morning,
I hope that all of you had a great weekend!
On to the update:
NPM Sabotage
From Bleeping Computer:
Users of popular open-source libraries ‘colors’ and ‘faker’ were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking. Some surmised if the NPM libraries had been compromised, but it turns out there’s much more to the story.
The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on ‘colors’ and ‘faker.’ The colors library receives over 20 million weekly downloads on npm alone and has almost 19,000 projects relying on it. Whereas, faker receives over 2.8 million weekly downloads on npm, and has over 2,500 dependents…
The reason behind this mischief on the developer’s part appears to be retaliation—against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community. In November 2020, Marak [Squires] had warned that he will no longer be supporting the big corporations with his “free work” and that commercial entities should consider either forking the projects or compensating the dev with a yearly “six figure” salary.
A few important points of background. First, npm is a package manager for Node.js. Node.js is a runtime environment that lets you run Javascript, which was originally designed for use in the browser, on the server. Node.js comes preinstalled with the npm package manager, which lets you easily access and install bits of code from npm’s online registry; npm was acquired by Microsoft-owned GitHub two years ago. It is possible to run a Node.js app that pulls code straight from npm.
Squires’ code, like a huge portion of open source code available on npm, had the MIT license (there are far more restrictive open source licenses, most famously the GPL family of licenses; GPL code is far less likely to be used in company projects, however). The MIT license is short and sweet, and states in whole:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Both the first and last paragraphs are pertinent in this case. The first one makes clear that the corporations that Squires is unhappy with are absolutely acting within their rights when they use projects he has shared without compensation. Sure, you can argue that companies that use open source software and never give back to the community, whether monetarily or via code, are violating the spirit of open source, but they are not doing anything illegal.
The third paragraph, meanwhile, applies to Squires’ actions and the impact it had on companies using his code. It is his code, and he is free to do whatever he wants to said code, including sabotaging it, and if that screws up other companies’ applications he does not bear any responsibility for that. Sure, you can argue that an open source author purposely introducing a bug into his widely used package is violating the spirit of open source, but he is not doing anything illegal.
Convenience Matters
My favorite npm story concerned the is-even package:
Notice that is-even has 1 dependency; let’s see what it is:
That’s right, is-even requires the download and installation of is-odd, just so that it can return the opposite answer (is-odd, naturally, has its own dependency: is-number).
Using is-even is, to be clear, the absolute height of laziness for any developer; is-odd is already pretty lazy, but if you have is-odd you already have is-even! And yet, as you can see, is-even has been downloaded 141,282 times this week alone. The fact of the matter is that many developers, because they are humans, default to the most convenient option — and if you’re a Node.js developer then using a freely available npm package is pretty darn convenient! Moreover, while this specific story is about npm and Node.js, package managers are a standard part of many open source programming environments, precisely because they are so convenient.
This convenience can, of course, be abused by malicious actors — attacking packages is called a “supply chain attack” — which is why companies generally maintain a private mirror of these packages for their applications; everything on these private mirrors is, at least in theory, fully vetted. In truth, though, it’s easy to let it slip, and hybrid feeds can be exploited; best practices include referencing one single private feed (instead of multiple), controlling scope via naming prefixes, and implementing client-side verification, including version pinning. Not everyone follows best practices though — it can be inconvenient!
Moxie Marlinspike on Web3
There are a lot of interesting points to make about this story, including ruminating about how so much of computing and the Internet was designed with remarkably optimistic assumptions about the trustworthiness of strangers; while we sometimes see the downsides of this approach, it is worth thinking about the extent to which that optimism was a prerequisite for the Internet to have ever come to be.
I think, though, given the context of last week’s Update about OpenSea and Aggregation, it is worth highlighting just how powerful a motivator convenience — which is absolutely a part of the user experience — is to a product or project’s adoption.
Moxie Marlinspike, co-founder of Signal, wrote a fantastic blog post over the weekend that fleshed out the point I was trying to make in that Update; here is the core of his argument:
web3 is a somewhat ambiguous term, which makes it difficult to rigorously evaluate what the ambitions for web3 should be, but the general thesis seems to be that web1 was decentralized, web2 centralized everything into platforms, and that web3 will decentralize everything again. web3 should give us the richness of web2, but decentralized.
It’s probably good to have some clarity on why centralized platforms emerged to begin with, and in my mind the explanation is pretty simple:
- People don’t want to run their own servers, and never will. The premise for web1 was that everyone on the internet would be both a publisher and consumer of content as well as a publisher and consumer of infrastructure.
We’d all have our own web server with our own web site, our own mail server for our own email, our own finger server for our own status messages, our own chargen server for our own character generation. However – and I don’t think this can be emphasized enough – that is not what people want. People do not want to run their own servers.
Even nerds do not want to run their own servers at this point. Even organizations building software full time do not want to run their own servers at this point. If there’s one thing I hope we’ve learned about the world, it’s that people do not want to run their own servers. The companies that emerged offering to do that for you instead were successful, and the companies that iterated on new functionality based on what is possible with those networks were even more successful.
- A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. People are still trying to standardize sharing a video reliably over IRC; meanwhile, Slack lets you create custom reaction emoji based on your face.
This isn’t a funding issue. If something is truly decentralized, it becomes very difficult to change, and often remains stuck in time. That is a problem for technology, because the rest of the ecosystem is moving very quickly, and if you don’t keep up you will fail. There are entire parallel industries focused on defining and improving methodologies like Agile to try to figure out how to organize enormous groups of people so that they can move as quickly as possible because it is so critical.
When the technology itself is more conducive to stasis than movement, that’s a problem. A sure recipe for success has been to take a 90’s protocol that was stuck in time, centralize it, and iterate quickly.
But web3 intends to be different, so let’s take a look. In order to get a quick feeling for the space and a better understanding for what the future may hold, I decided to build a couple of dApps and create an NFT.
What Marlinspike discovered is exactly the same sort of thing I wrote about last week: it turns out that the reality of web3 is far more centralized than it is advertised to be (I highly suggest reading the whole post to get the specifics). To those who argue that this is early days, Marlinspike responded:
However, even if this is just the beginning (and it very well might be!), I’m not sure we should consider that any consolation. I think the opposite might be true; it seems like we should take notice that from the very beginning, these technologies immediately tended towards centralization through platforms in order for them to be realized, that this has ~zero negatively felt effect on the velocity of the ecosystem, and that most participants don’t even know or care it’s happening. This might suggest that decentralization itself is not actually of immediate practical or pressing importance to the majority of people downstream, that the only amount of decentralization people want is the minimum amount required for something to exist, and that if not very consciously accounted for, these forces will push us further from rather than closer to the ideal outcome as the days become less early.
Keep in mind the lesson we just discussed: convenience matters. Moreover, given the fact that so many crypto projects depend on ever more people entering the ecosystem, such that earlier users can see the value of their holdings increase, the incentives of both existing users and new users are aligned in favor of more convenience and easier onboarding, which is to say that the incentives are towards more centralization, not less.
GitHub, by the way, reverted faker.js and suspended Squires’ account (although his account appears to have been restored); this led to complaints on Twitter about GitHub’s centralization and calls for a decentralized alternative. Here’s the thing, though: Git is an open source project (invented by Linus Torvalds), which means you can set up a Git server on your own server if you would like. It’s inconvenient, though.
This Update will be available as a podcast later today. To receive it in your podcast player, visit Stratechery.
The Stratechery Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly.
Thanks for being a subscriber, and have a great day!