Trusting Other People’s Code
The danger of using 3rd party JavaScript code from npm (or another package manager) is that the library you use, or one of its dependencies, could come with nefarious bits. There is even the chance that the code you see on GitHub does not match the library.min.js pre-compiled code npm will use. Is all hope lost? Do we have to code everything by hand? Do we abandon JavaScript because of this? What about other languages and other environments?
I am writing this in response to David Gilbertson’s article titled I’m harvesting credit card numbers and passwords from your site. Here’s how. It is a sensational piece that every website developer should read. Be certain to also read part 2 that is just as important to read as it provides actions you can take to protect your critical data as well as a healthy dose of “do not abandon ship”.
I was sparked to comment when I read a reply to this original article. The reply included:
I think this is the biggest issue here. Open Source should mean that anybody can audit the code, what’s the point if things like this become common practice and nobody can actually do it?
The General, Global Concern
First, this is not just a JavaScript concern. Most languages have 3rd party libraries, and many have library managers to ease their acquisition. This is an every language concern. Most, if not all, serious software packages on every platform, everywhere, use 3rd party libraries. This is seriously an every software package ever distributed concern.
It is true: Open Source projects can be inspected by anybody and that can provide a higher level of scrutiny, and therefore improved security over closed source software. However, history has proven this reality to rarely, if ever, be the case. Many key open source projects have lived with major security holes (sometimes for decades!): OpenSSL, OpenSSH, Bash, and more! Security defects in code that were open to public scrutiny and therefore provided more trust than closed source software.
Fundamentally we are talking about an issue of trust. We need some way of establishing the trustworthiness of the libraries we use. The question is how? Clearly, based on the original article, you cannot align trust with the number of downloads. Thumbs up/thumbs down meters? No, that is not going to provide anything more than an understanding of popularity — though on a per module basis the number of ratings will be far lower than the downloads. Perhaps what we need is a 3rd Party Library Trust Blockchain! Okay, I threw out there for fun — even though there might be something to it. The truth is, I do not have the answer, and I do not know if anyone really does.
This issue of trust in software is one Microsoft and Apple (and others!) have been trying to solve on their operating systems for years — mostly by moving to tighter controls on what software will run by default. To-date they have mostly solved this with code signing with stronger requirements for kernel driver code than application code. While these improvements have made a big difference, malicious code still finds its way onto computing devices every day. This trust is also only as good as the vetting put in place for entities allowed to sign code. Even if those entities are not malicious, carefree use of 3rd party code could still invite trouble in the backdoor from the trustworthiness of developers.
I agree with the sentiment of the original author in his second post: you do not need to stop using 3rd party libraries and abandon all hope. You do need to work smarter and with increased skepticism. As a development community as a whole, across languages and platforms, we need to work together to solve the trust issue — whatever that solution may be.
JavaScript Focused Response
I have a couple of things to say in response to the JavaScript specific issues. npm... We should not be permitting pre-bundled, minified versions of the library to be used automatically. Upon installing a package npm should build and bundle it. It is a fundamental failure that it does not do that. Module installation might be slower, but the assurance that what you are using is what you see in the repository is worth the extra time. It may be possible to write a tool to scan for pre-bundled versions which fail to match the expected source.
Further, please, stop using every little library because it seems cool. As I worked on my JavaScript Starter Architecture For the General Website, I very specifically made the conscious decision that the code I would use on my site would not use a bunch of 3rd party libraries. At worst case, I plan to use a few polyfills. This was primarily done from a desire to keep the JavaScript small, but the additional benefit of being easier to vet cannot be overlooked.
Conclusion
We all need to think more about this. That is all I can really conclude at this point. Think more about it, and keep talking about it.
