IoT
IoT
DevOps // Programming Languages
Commentary
3/27/2016
11:06 AM
50%
50%

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.

(Image: skeeze via Pixabay)

(Image: skeeze via Pixabay)

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

Curtis Franklin Jr. is executive editor for technical content at InformationWeek. In this role he oversees product and technology coverage for the publication. In addition he acts as executive producer for InformationWeek Radio and Interop Radio where he works with ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
4/21/2016 | 8:00:17 PM
Re: Outlawing languages
> "From a legal standpoint, I know that it matters whether it's done for commercial purposes."

Actually, this rarely matters.  Sometimes in certain intellectual-property matters or other specific contexts it comes up, but in general whether or not you're profiting from your speech is a legal nonce.

(((NOT LEGAL ADVICE.)))
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
4/20/2016 | 6:25:07 PM
Re: Wrong code
@Dr. T: Indeed, patch management -- or, rather, the lack of it -- may well be the #1 security issue facing enterprise IT departments today.

( see, e.g., enterprisenetworkingplanet.com/netsysm/patchy-patching-it-pet-peeves-part-4.html )
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
4/17/2016 | 8:36:32 PM
Re: Outlawing languages
@Curt: I'm sure that to a certain degree, programming languages do qualify as speech for freedom purposes.  Some activists, after all, have (attempted to) proliferate "feminist" programming languages simply for the sake of doing so, as a protest against perceivedly masculinist languages.

And when a language doesn't include a GOTO function, that definitely seems to be commentary.  ;)
jries921
50%
50%
jries921,
User Rank: Ninja
4/1/2016 | 12:21:24 PM
Banning languages
First of all, while I haven't read the petition, I'm guessing that nobody is talking about making programming in certain languages a criminal offense (arguably unconstitutional and probably unenforceable); but rather that the petition is about prohibiting the use of certain programming languages by the federal government itself and in software the federal government uses.  Since governments can and should make purchasing decisions in the same way any one else would, this should not offend anyone's libertarian sensibilities (if my wife and I don't want to use Windows in her yarn shop, that's our business, not anyone else's, to include MS').

Second, it should be noted that two of the most dangerous of all programming languages above the assembler level are also the most common: C (long notorious as a bug factory), and its superset, C++ (both are much more dangerous than Java ever thought of being) and that years ago, the US Defense Department spent large amounts of taxpayer money developing a specification for a best practices programming language that never really caught on in the private sector: Ada.  So if the feds really wanted to promote safer computing, one of the things they could do is to make the language they've already paid to create easier to use, and to actively promote its use, at least in federal projects.

Third, it's an utter waste of time and effort to petition the President of the United States to do things he obviously does not have the legal authority to do.  While this petition probably does not fall into this category, I've seen numerous others that do (like the various secession petitions) so the point should be kept in mind when filing new ones.
BrooklynNellie2
50%
50%
BrooklynNellie2,
User Rank: Moderator
4/1/2016 | 9:30:04 AM
Re: I say Yes
JQuery is JavaScript code that helps you accomplish JavaScript tasks with less writing. It does not stand alone. It cannot exists without JavaScript.

I am not familiar with Node.js, but Wikipedia says, "many of its basic modules are written in JavaScript, and developers can write new modules in JavaScript."
Broadway0474
50%
50%
Broadway0474,
User Rank: Ninja
3/31/2016 | 9:20:52 PM
Re: Outlawing languages
I'd say the WWW is a very tought market, but like any market, it is not entirely "free." It can be gamed and definitely bought. That's Google's whole business model right?!
TerryB
50%
50%
TerryB,
User Rank: Ninja
3/31/2016 | 12:53:26 PM
Re: Too Late
@ashu001. Yeah, don't see game changing much in near future. Client side is difficult and most likely unsolvable because bad guy has computer right in front of him.

My initial discussion with Curtis that he referred to was about using scripting languages at backend on servers. That's the big exposure, where the data lives. My point to him was just by used compiled programs and stored procedures on servers it makes it infinitely more difficult to screw security up. When your client side code doesn't allow feeding in raw "Select * from database" commands and getting them to run thru SQL injection and buffer overflow techniques, you have covered the primary attack vectors.

Calling stored/compiled programs only allows manipulating parameters. Decent session control (CGI spoofing prevention) and good server side edits can mitigate that vector.

But server side, a big problem is this DevOps stuff on commodity servers that uses HTTP methods like PUT and DELETE to implement server side code. The IBM i5 server has an integrated (meaning runs under user profiles like native jobs) HTTP Apache server which does not even implement those methods. You can only GET and POST from clients. So that way you know no one is putting rogue code on your server.

Being an IBM server guy, I avoid things like PHP, Node.js, even Java, because they don't run natively. The i5 o/s can run a UNIX shell and JVM on top of it's o/s to allow those tools. But now you have all the security holes of JVM and UNIX to deal with.

But the world is not going to quit using these cheap commodity servers. But that's where this battle must be fought, on server side.
Ashu001
50%
50%
Ashu001,
User Rank: Ninja
3/31/2016 | 10:20:55 AM
Re: Wrong code
Curt,

I believe we need a Compulsary Security Framework in place for JS today.

Too much investment has been sunk into JS to discard it totally and re-start again from scratch.

 
Ashu001
50%
50%
Ashu001,
User Rank: Ninja
3/31/2016 | 10:17:23 AM
Re: Too Late
TerryB,

Nice way of describing the current conrundrum.

How close(or otherwise) are we towards such a Language today?

Not very.

And that means the rest of us Folks(in Development & Security) need to pull our socks up and Be on the game 24/7/365.

 
Ashu001
50%
50%
Ashu001,
User Rank: Ninja
3/31/2016 | 10:08:49 AM
Re: Outlawing languages
Broadway,

Fair enough statement made by you here.

If there is a problem with this Language (or any other) its best left to the Market to decide whether or not to outlaw a particular language.

After all there is no superior Marketplace out there than the WWW today.

Is there?

The No-holds barred competition can drive folks crazy sometimes but any one who survives this market is most definitely dealing with Survival of the fittest.

No doubts about that one!

 
Page 1 / 3   >   >>
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of August 14, 2016. We'll be talking with the InformationWeek.com editors and correspondents who brought you the top stories of the week to get the "story behind the story."
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.