Slashdot Mirror
Open Source and Javascript
mr_burns asks: "I was wondering what people's opinions were about GPLing or otherwise OSS licensing javascript code. I have some pretty cool code I want to share with everybody, but I don't want to be screwed. I look forward to establishing a method of collaboration such that we can all take ECMA-262/javascript to the next level. Why should Slashdot and other DB driven sites rely on a servers processing power when the client machine is mostly idle? I think colaboration between client side and server side scripters in an OSS context could make things much more efficient. What pointers do the OSS community have that could guide the way, and what are your opinions on the matter? Thanks in advance for any feedback y'all can give." What do you all think? Is Javascript robust enough for this sort of thing?
Actually, the risk is in enabling Javascript or ActiveX on any web browser. Some people may swallow the pleasing arguments of the manufacturers' marketing agents in favour of these two proprietary technologies. However, real companies with assets to protect need to have a strict security policy to control the content of communications to and from networks including both intranets and the Internet. The type of content most likely to bring serious hazards is executable content such as Javascript. Many companies therefore have a security policy that forbids the use of Javascript et al in web browsers. Javascript et al have a history of serious security problems -- one of the best information sources on this topic is BugTraq's Ja vascript security problems.
Furthermore, many companies avoid using Javascript and ActiveX on their web sites because they do not want to lock out potential customers from companies that do not allow Javascript or ActiveX.
Remember, executable content is a security problem looking for a victim.
in a serious international forum like Slashdot it's unprofessional
Who knew?
Surely the comment was tongue-in-cheek -- "in a serious international forum like Slashdot it's unprofessional" !!!!
Perhaps it's only me, but I find javascript fairly annoying. First of all, way too many sites uses it for gratuitous effects, like popping up fixed-size windows everywhere, irritating animated effects and the like. Second, I find that netscape crashes much more often if I have javascript activated. So for the forseeable future, I will not allow javascript and just stay away from websites that require it.
Trust the Computer. The Computer is your friend.
If you want to GPL your JavaScript, just include the GPL in your JavaScript. Well, there may be a few K of implementation difficulty...
Many businesses have a security policy which forbids the use of Javascript and ActiveX in web browsers due to the exceptional risks of malevolent attack raised by feeding your computer with someone else's Javascript or ActiveX (with or without signatures).
A web site which requires Javascript or ActiveX to view is locking out potential customers. Design a website using any standard HTML and you will be open for business from most PCs on the planet with a browser. Are you listening Odeon Cinemas UK?
Javascript is a strong scripting language. It has support for dynamic objects, associative arrays, regular expressions, OOP, and other nice programming features. It also has dynamic function definitions. As a scripting language, Javascript can hold its own pretty well. I have recently written some stand-alone stuff in Javascript, and javascript is a very good scripting language to do it in. This means that is also functions well as a server-side scripting language.
As far as Javascript in Browsers go, agree with the other posts that say javascript should be avoided in internet web pages. Using javascript in internet web pages limits the potential audience. Javascript can be used well in company intranets, though. (Where everything is fairly standardized so everyone is using the same browser with the same security settings). Javascript can make intranet sites become very useful to a company.
Be careful to seperate javascript as a language from any implementation of it. Just because IE's implementation of it produces staticly-sized text boxes does not mean that it is a bad language. That is just one way of using the language. The language itself has evolved to be a very powerful scripting language (not far behind perl in my opinion). The most common use of it just happens to be client-side web scripting. Try using javascript as a normal scripting language and the good design of the language will come through. Do not limit javascript to a client-side scripting language when it is so much better in other places.
Rick Wash
Rhino comes to mind, it is a Java based Javascript compiler... or a Javascript to Java compiler deal. I'm not too sure, but I know it's out there and I'm not familiar with the license either. Sorry... but try searching on "Rhino" I recall some chatter on the jakarta mailing list as well as perhaps mozilla.org However, I'd move away from server-side javascript and dive straight into Java. Where you can use neat things like Java Servlets, JSP (Java server pages), JavaBeans, Enterprise JavaBeans, etc. etc. It's open, portable and great. If you are a small shop, then sure, go with a server-side solution (perl/php3/ss-javascript). But only Netscape has server-side javascript, it's their invention... Heads Up: Javascript has nothing to do with Java Although you can talk to Java objects through something called LiveConnect... another Netscape-ism.... My suggestion is to grab JRun for now... install it on linux and apache and have fun. Then you can wait for the fruitions of the Jakarta project to come through (jakarta.apache.org) and hopefully blackdown.org will have come out with a working JDK 1.2.x port by then.... or IBM gets a decent 1.1.7 or 1.1.8 port (stable, not decent...) Have fun! ;) I know I did....
if using two languages is so troublesome, why don't you use JS in the server side. i believe that netscape has released both C and java based JS implementations (http://www.mozilla.org/js). in fact, i am currently evaluating JS as a scripting framework with java and JSP in the serverside.
Security problems can threaten the existence of a company, whereas language design flaws tend to entrap only mediocre programmers. Of course, as a programmer you may not be much concerned with security management.
So one should worry that companies are using their Intranet web servers to steal "assets" from their own computers? OK.
--
Business. Numbers. Money. People. Computer World.
this is anal retentive thinking. the security problems with internet access are not acceptable to many companies too. i haven't seen any company pull down their website because it was cracked. you don't throw out the technology because of implementation bugs. you fix the problem.
Not dangerous at all. I'll be the first to agree with you that Active X is a volatile technology. But I've been programming with JavaScript for a while and, as far as I can tell, the worst you are looking at is being involuntarily sent to someone else's smutty site. Which in itself isn't particularly dangerous (unless your company logs browser connections).
Maybe you could perform a denial of service attack by with an infinite loop but that is pretty tame in comparison to the types of things you can get up to with Active X
...not that I would know!
You need to learn the security risks of Javascript. An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com. Read what BugTraq has to say about Ja vascript security problems. It should be no surprise that technically aware companies usually have a computer security policy which bans the use of Javascript and ActiveX.
I seem to recall that variable in functions are local iff your declare them with 'var'.
Scuttlemonkey is a troll
The security problems with any client-side scripting language including Javascript are simply not acceptable to most technically aware companies. Allowing Javascript on a company intranet is a security risk; the only way to remove the intrinsic security dangers is to forbid the use of Javascript in web browsers. References to Javascript security problems were given in this comment.
Hey, Coward!
.SWF suffix. Now, here is the crux of my argument: SWF files are flash files! Hence, a flash page. You see, there is an application called AfterShock that inserts a SWF file in HTML for you and its work is noticable by the HTML comments it produces. (You could take a coffee break here if this is all too strenous).
While the Odean web-site is only viewable when JavaScript is enabled, it is, nevertheless, a Flash page. You can tell in a very simple way, so pay attention. First select View Page Source and you'll see this text window pop-up (don't be frightened, now). This contains the HTML tags that define the document.
Inside you'll notice an EMBED tag. Now, if I am not mistaken, this mean that the document contains executable content, i.e. a plug-in. With me so far? You'll also notice that the EMBED tag calls a file with the
Oh, BTW thank-you for your offer from teaching me some JavaScript. If you need some basic lessons in web-page content, however, you'll know exactly where to find me.
Love and kisses...
No, if you make a var variable declaration outside a function then its scope is global.
If the question was, "can I/should I GPL Javascript code", the answer is "yes". GPL or free everything you feel good about freeing, the more code the merrier.
If you were asking, "is Javascript a good language?", my answer is a qualified "maybe". JS is OK, but it doesn't thrill me. I like the prototype-based language, but overall it's caught in the middle between too OOP and too loose.
Problems I have with JS:
- Variable scoping is strange, and has never been clear to me.
- It's great as a browser scripting tool; it's not very good as a server-side tool *at all*.
- It's nominally standardized via ECMA, but Netscape keeps trying to leapfrog the standard and innovate at the speed of light (they're up to Version 1.4! I've never even used 1.3 stuff, and hardly ever used 1.2)
I'm not a big Javascript fan. I use it only because it's the only built-in scripter for the browsers out there. If there were a Perl/Python/Tcl DOM/scripting layer, I'd use that.
It's a strange world -- let's keep it that way
I do a lot of client-server programming (usually in PHP with a DB backend) and I can't tell you how much time I have wasted writing code to do the same thing in JS and in PHP just so that they can keep some data object in sync without server round-trips. I think that for web apps to go to the next level, we absolutely need some kind of interaction standard. I would fully support an OSS project on this, I think that is the only way it will ever get done.
And, before you flame, yes I do know about Java, CORBA, RMI, etc etc etc. These are way too heavyweight for what I'm talking about.
Can your IM do this?
Actually, Internet Explorer has the ability to enable JavaScript (and ActiveX, etc) only for Intranet sites, and disable the risky stuff for all others. This can be all under central administrative control. (Mozilla 5 will apparently do the same thing.) Just because Netscape 4.x is feature defecient in this regard, it doesn't mean that Javascript can't be enabled safely in other situations.
The original poster is correct that the real sexy DHTML stuff is only really practical on an Intranet where you have complete control over the client browsers.
--
Business. Numbers. Money. People. Computer World.
Threats to company assets can be of internal or external origin. For many companies that have a computer security policy, client-side executable content presents unacceptable levels of risk in both intranet and Internet environments. The serious security risks of using Javascript and other executable content in web browsers are explained elsewhere -- one of the best information sources is BugTraq's Ja vascript security problems.
i haven't seen any company pull down their website because it was cracked.
You misunderstand; the security problems exist mainly at the client side when you let someone else's web site feed your computer with hazardous Javascript. That's the real security risk. Internet access by itself is neither good nor bad. The solution is to have a company security policy to control the content of the communications to and from the Internet. That's why many businesses already have a security policy that forbids the use of scripting languages like Javascript and ActiveX by web browsers. Of course, if you don't have any assets to protect, you probably don't care about such security problems!
An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com Read what BugTraq has to say about Ja vascript security problems.