White House Petition Aims To Stop The JavaScript Scourge
Is it time to put an end to JavaScript once and for all? Someone thinks so, and they've got the White House petition to prove it.
Top Programming Languages That Will Future-Proof Your Portfolio
Top Programming Languages That Will Future-Proof Your Portfolio (Click image for larger view and slideshow.)
Some programming languages are so bad, so dangerous, that the full weight of the US federal government must be brought to bear on ending their use. That's the premise of a petition now seeking signatures at the "We the People" section of the White House website.
The petition, entered on the site March 16, 2016, asks the government to, "Outlaw programming languages that threaten the safety of the American people and work counter to our way of life." The petitioner is even kind enough to provide examples of these evil and dangerous languages.
Which programming languages deserve the fate normally reserved for terrorists and drug pushers? JavaScript, Ruby, and Java are called out by name. According to the petition, "...these tools represent a grave risk to the reliability and safety of our nations critical infrastructure." As of this writing, 35 citizens have signed the petition in support of the ban. Only 99,965 more need to sign in order to force a government response. Never one to wait around for action, I'd like to respond now.
The person who brought the petition to the White House website seems to feel that security (or rather a lack of security) is the main problem with the languages mentioned. My first problem is that he throws three languages into his bag of examples, and in the words of the Sage of Sesame Street, "One of these things is not like the others; one of these things just doesn't belong." So I'm going to carve Java off for the moment and see whether he has a point concerning JavaScript and Ruby.
Earlier in March I wrote an article on programming languages to future-proof your portfolio. Not surprisingly, there was a discussion about my general understanding of the world following its publication, and one member of the InformationWeek community -- TerryB -- called out scripting languages as a problem, writing, "The fact things like Python and PHP, and to lesser degree, Perl are showing up go a long way to explain why many web apps are as secure as a 1940 outhouse."
TerryB then went on to write, though, "...javascript really needs to be expanded into things like Node.js, JQuery, Linear, and Extjs and the rest of fullblown javascript libraries. By almost any measure, those are becoming just like a high level programming language for the client side." The key part of his analysis is those last two words: client side. That's where the petitioner and many others strike. They look at the weakness in client-side security and project it all the way through to the server.
The structural problem the petition (and our community member) call out is that scripting languages are almost always interpreted. That is, they're converted from the language you can look at into the language of the computer when the program is executed rather than when the program is prepared for distribution. That makes the program quite flexible, but it also means that the server-side applications that accept input from scripts must be somewhat flexible, as well. That run-time flexibility (along with some of the input methods allowed) are why people doubt the security of Ruby. It's interpreted, it's client-oriented, and it's flexible. And in that flexibility lies the seeds of vulnerability.
I'll be the first to admit that it's possible to use JavaScript (or any other client-side scripting language) to create a Web application that is a security nightmare. All it takes is a client app that does no type of data checking and a backend that isn't locked down to give a reasonably talented 12-year-old the keys to your entire data store. I maintain, though, that the problem is only partially with the language. Much of the blame must lie with the programmer.
Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!
So what we have is a petition to outlaw languages that, if used badly, might lead to security problems in critical infrastructure. Before I get to the end, let me talk about Java for a moment.
Repeat after me: Java is not JavaScript. The two are related in the first four characters of their names and pretty much nothing else. While I'm not the world's biggest Java fan (it's a generational thing), I recognize that it's the most commonly used programming language in enterprises today. It's a compiled language that is no less secure than any other compiled language. It has its faults but none of them are as significant as the problems programmers can introduce.
So should you run out and add your name to the petition? Your right to do so is written into the Constitution. I'm not a fan of this one, though, for several reasons. The first is that I just don't believe we should go around outlawing everything that might be dangerous. Call me a latent Libertarian if you must, but I'd rather see us develop good programming habits than have languages outlawed.
The next reason for my opposition is one of limits. If we succeed in outlawing JavaScript where do we turn next? I've always thought that UDP was a dangerous protocol, what with ephemeral ports and lack of required response. Anarchy!
It's possible this is a very silly petition that is getting just about the level of response it deserves. While it would be fun to see the executive branch weigh in on the political nuances of Ruby, I don't really want to see the government (ours or any other) deciding the legality of programming languages. So let's have a good discussion about tools and their best use and leave the legislation to more important matters like why "Angry Beavers" hasn't been recognized as the cultural treasure it is. I think I'll start a petition...
About the Author
You May Also Like
2024 InformationWeek US IT Salary Report
May 29, 20242022 State of ITOps and SecOps
Jun 21, 2022