Related
Javascript doesn't let you give private data or methods to objects, like you can in C++. Oh, well actually, yes it does, via some workarounds involving closure. But coming from a Python background, I am inclined to believe that "pretend privacy" (via naming conventions and documentation) is good enough, or maybe even preferable to "enforced privacy" (enforced by Javascript itself). Sure, I can think of situations where this is not true -- e.g. people interface with my code without RTFM but I get blamed -- but I'm not in that situation.
But, something gives me pause. Javascript guru Douglas Crockford, in "Javascript: The Good Parts" and elsewhere, repeatedly refers to fake-privacy as a "security" issue. For example, "an attacker can easily access the fields directly and replace the methods with his own".
I'm confused by this. It seems to me that if I follow minimal security practices (validate, don't blindly trust, data sent from a browser to my server; don't include third-party scripts on my site without inspecting them) then there is no situation where pretend-privacy is less "secure" than enforced privacy. Is that right? If not, what's a situation where pretend-privacy versus enforced-privacy has security implications?
Not in itself. However, it does mean you cannot safely load untrusted JavaScript code into your HTML documents, as Crockford points out. If you really need to run such untrusted JavaScript code in the browser (e.g. for user-submitted widgets in social networking sites), consider iframe sandboxing.
As a Web developer, your security problem is often that major Internet advertising brokers do not support (or even prohibit) framing their ad code. Unfortunately, you have to trust Google to not deliver malicious JavaScript, whether intentionally or unintentionally (e.g. they get hacked).
Here is a short description of iframe sandboxing I had posted as an answer to another question:
Set up a completely separate domain name (e.g. "exampleusercontent.com") exclusively for user-submitted HTML, CSS, and JavaScript. Do not allow this content to be loaded through your main domain name. Then embed the user content in your pages using iframes.
If you need tighter integration than simple framing, window.postMessage() may help, allowing scripts in different frames to communicate with each other in a controlled manner.
It seems the answer is "No, fake privacy is fine". Here are some elaborations:
In javascript as it exists today, you cannot include an unknown and untrusted third-party script on your webpage. It can wreak havoc: It can rewrite all the HTML on the page, it can prompt the user for his password and then send it to an evil server, etc. etc. Javascript coding style makes no difference to this basic fact. See PleaseStand's answer for a discussion of methods to deal with this.
An incompetent but not evil script might unintentionally mess things up through name conflicts. This is a good argument against creating lots of global variables with common names, but has nothing to do with whether to avoid fake-private variables. For example, my banana-selling website might use the fake-private variable window.BANANA_STORE_MODULE.cart.__cart_item_array. It is not completely impossible that this variable would be accidentally overwritten by a third-party script, but it's extraordinarily unlikely.
There are ideas floating around for a future modification of javascript that would provide a controlled environment where untrusted code can act in prescribed ways. I could let the untrusted third-party javascript interact with my javascript through specific exposed methods, and block the third-party script from accessing the HTML, etc. If this ever exists, it could be a scenario where private variables are essential for security. But it doesn't exist yet.
Writing clear and bug-free code is always, obviously, helpful for security. Insofar as truly-private variables and methods make it easier or harder to write clear and bug-free code, there's a security implication. Whether they are helpful or not will always be a matter of debate and taste, and whether your background is, say, C++ (where private variables are central) versus Python (where private variables are nonexistent). There are arguments in both directions, including the famous blog post Javascript Private Variables are Evil.
For my part, I will keep using fake privacy: A leading underscore (or whatever) indicates to myself and my collaborators that some property or method is not part of the publicly-supported interface of a module. My fake-privacy code is more readable (IMO), and I have more freedom in structuring it (e.g. a closure cannot span two files), and I can access those fake-private variables while I debug and experiment. I'm not going to worry that these programs are somehow more insecure than any other javascript program.
I want to allow user contributed Javascript in areas of my website.
Is this completely insane?
Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Should this process be manually authorized (by a human checking the Javascript)?
Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
Thanks
I think the correct answer is 1.
As soon as you allow Javascript, you open yourself and your users to all kinds of issues. There is no perfect way to clean Javascript, and people like the Troll Army will take it as their personal mission to mess you up.
1. Is this completely insane?
Don't think so, but near. Let's see.
2. Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Yeah, at least there are Google Caja and ADSafe to sanitize the code, allowing it to be sandboxed. I don't know up to what degree of trustworthiest they provide, though.
3. Should this process be manually authorized (by a human checking the Javascript)?
It may be possible that sandbox fails, so it would be a sensible solution, depending on the risk and the trade-off of being attacked by malicious (or faulty) code.
4. Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
JQuery is just plain Javascript, so if you're trying to protect from attacks, it won't help at all.
If it is crucial to prevent these kind of attacks, you can implement a custom language, parse it in the backend and produce the controlled, safe javascript; or you may consider another strategy, like providing an API and accessing it from a third-party component of your app.
Take a look at Google Caja:
Caja allows websites to safely embed DHTML web applications from third parties, and enables rich interaction between the embedding page and the embedded applications. It uses an object-capability security model to allow for a wide range of flexible security policies, so that the containing page can effectively control the embedded applications' use of user data and to allow gadgets to prevent interference between gadgets' UI elements.
Instead of checking for evil things like script includes, I would go for regex-based whitelisting of the few commands you expect to be used. Then involve a human to authorize and add new acceptable commands to the whitelist.
Think about all of the things YOU can do with javascript. Then think about the things you would do if you could do it on someone elses site. These are things that people will do just because they can, or to find out if they can. I don't think it is a good idea at all.
It might be safer to design/implement your own restricted scripting language, which can be very similar to JavaScript, but which is under the control of your own interpreter.
Probably. The scope for doing bad things is going to be much greater than it is when you simply allow HTML but try to avoid alloing JavaScript.I do not know.Well, two things: do you really want to spend your time doing this, and if you do this you had better make sure they see the javascript code rather than actual live JavaScript!I can't see why this would make any difference, unless you do have someone approving posts and that person happens to be more at home with jQuery than plain JavaScript.
Host it on a different domain. Same-origin security policy in browsers will then prevent user-submitted JS from attacking your site.
It's not enough to host it on a different subdomain, because subdomains can set cookies on higher-level domain, and this could be used for session fixation attacks.
During a recient PCI audit the auditor said that we had major security risks because
It was possible to download static resources from our website such as images css and javascript without prior authentication.
Our javascript had comments in it.
Personally I think that this is not a security risk at all. The images css and javascript where not dynamically created and they contained no data on our backend, our customer details and on mechanisms.
The comments within the javascript were just simply explaining what the methods in the javascript file did. Which anyone who reads JS could have found out anyway.
How does that show "information leakage"?
Are comments within javascript really a security risk?
Depending on how strict the audit, downloading images etc without authentication COULD be seen as a security risk (think diagrams, charts, graphs...).
Removing comments in the javascript is like obfuscating the code: it makes it a bit harder, but still not impossible to understand what's going on. JavaScript should be seen as enhancing-only anyway, all your security should be (duplicated) at server-side. Having anyone understand what the JS does should not be considered a risk.
It depends on the content of the commentary. Because there is no way, without human intervention, to examine the content of comments to determine whether they are risky, the most efficient way to audit this is to declare all comments in client-facing source code to be risky.
The following are examples of potentially risky comments.
// doesn't really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);
or
// don't forget to include the length,
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}
or
function doSomething() {
querystring = ""
//querystring = "?TRACING_MODE=true&"
...
//print_server_trace();
}
Another example might be if you include a source code history header, someone might be able to find some security weakness by examining the kinds of bugs that have been fixed. At least, a cracker might be able to better target his attacks, if he knows which attack vectors have already been closed.
Now, all of these examples are bad practices anyway (both the comments and the code), and the best way to prevent it is by having code reviews and good programmers. The first example is particularly bad, but innocent warnings to your team mates, like the second example, or commented-out debugging code, like the third, are the kinds of security holes that could slip through the net.
Without getting into if they are a security risk or not, minify your JS on production environment, this will prevent the "information leakage" and help (in some way at least) to secure the information of your website.
regarding the security risk, I don't think JS comments are a risk at all, every website content (static) can be downloaded without authentication. (unless defined otherwise)
Not if they only reveal how the code works. Any sufficiently determined person could find that out anyway.
That said, it is probably a good idea to minify the JavaScript; not because of security, but because it will reduce download times and therefore make your site a bit more responsive.
JavaScript comments can be. depends on your logic, but certainly as it is publically available, you are giving more visibility to the workings of your code.
There are other reasons for removing this as as well, such as file size, and as a result download size.
Tools such asd JSMin can help you remove the comments and perfrom a crude obfuscation of the code.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I need to write a GUI related javascript library. It will give my website a bit of an edge (in terms of functionality I can offer) - up until my competitors play with it long enough to figure out how to write it by themselves (or finally hack the downloaded script). I can accept the fact that it will be emulated over time - thats par for the course (its part of business). I just want to have a few months breathing space where people go "Wow - how the f*** did they do that?" - which gives me a few months of free publicity and some momentum to move onto other things.
To be clear, I am not even concerned about hard core hackers who will still hack the source - thats a losing battle not worth fighting (and in any case I accept that my code is not "so precious"). However, what I cannot bear, is the idea of effectively, simply handing over all the hard work that would have gone into the library to my competitors, by using plain javascript that anyone can download and use. If someone is going to use what I have worked on, then I sure as hell don't want to simply hand it over to them - I want them to work hard at decoding it. If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order) - So, I'm not claiming that no one could have written this (which would be a preposterous claim in any case) - but rather, what I am saying is that no one (up to now) has made the functionality I am talking about, available to this particular industry - and I (thinking as an entrepreneur rather than a geek/coder), want to milk it for all its worth, while it lasts i.e until it (inevitably) gets hacked.
It is an established fact that not one website in the industry I am "attacking" has this functionality, so the value of such a library is undeniable and is not up for discussion (i.e. thats not what I'm asking here).
What I am seeking to find out are the pros and cons of obfuscating a javascript library, so that I can come to a final decision.
Two of my biggest concerns are debugging, and subtle errors that may be introduced by the obfuscator.
I would like to know:
How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)
Are there any good quality industry standard obfuscators you can recommend (preferably something you use yourself).
What are your experiences of using obfuscated code in a production environment?
If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order).
So really, you're trying to solve a business issue with technical measures.
Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.
Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.
In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.
If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.
While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.
The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.
The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.
What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.
You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.
If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.
Javascript obfuscation facts:
No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
Obfuscation != encryption - This one is obvious but its common mistake people make.
Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)
Javascript obfuscation fiction: ( I will skip this section ;) )
Answer to Q2 - Sugested obfuscation tools:
For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.
Answer to Q3 - experiences of using obfuscated code
To date no new bugs introduced by obfuscation
Much better client retention. They must come to the source to get the source;)
Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com
Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?
IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.
How can I manage those risks (being
able to debug faulty code,
ensuring/minimizing against
obfuscation errors)
Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.
What are your experiences of using
obfuscated code in a production
environment?
Being completely bypassed by side channel attacks, replay attacks, etc.
Bugs.
Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.
You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.
Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.
Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.
JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.
If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar
While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.
The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.
Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Why is JavaScript allowed to be disabled in the browser? (i.e. Why is it considered bad?)
<body onload="for(i=0; i<1000000; i++){window.open(
'samplesite.com?pageid=' + i);}">
Why is javascript allowed to be disabled in the browser? (i.e. Why is it considered bad?)
Because it can be grossly misused (blinking images, anyone?), may slow the browser down and of course there's always the (very justified!) fear of exploited security holes.
First of all with Javascript you can create events that the user might not want you to, like e.g. changing the size of the window...
On the other hand think about people who are somehow limited... What if your user was blind and uses a screenreader while your page continously changes its content somehow... There are many reasons against Javascript when it comes to accessibility...
Back in time, it used to be:
A source of annoying cursor-following animations (I am sure you remember stuff, like raining sheeps or clocks following your cursor... I want to find the smart*** who thought of that and slap them with a trout)
Considered insecure
Served no purpose but bog down the browser
However, over the years it has become more advanced and applied with more thinking behind it.
Historically it has been a huge security problem for web based services. Also with any technology that is exploitable and has a low technical barrier for entry it ends up the tool of the low brow trouble maker (script kiddies). Quick searches for javascript or xss in a security exploit database will show hundreds of pages of vulnerability.
JavaScript is often considered dangerous or at least annoying for two reasons:
Websites can suddenly do stuff that you don't want them to do, e.g. open popups
Websites can suddenly keep you from doing stuff that you want to do, e.g. disabling right-clicks
Now, in the vast majority of cases JavaScript is harmless and can really enhance the user experience (Ajax comes to mind). But all it takes is one malicious site that uses JavaScript to do evil (TM) things like Cross-site Scripting. For that reason it is commonly considered best practice to disable JavaScript globally and to allow it for just those sites or domains that you explicitly trust. In this day and age being paranoid on the Internet is actually a good thing.
It's a weakly-typed scripting language. Programmers who usually use "big strong" languages look down upon such nonsense. Shame on you for even considering using it, and my God have mercy on your soul.
It can cause security problems. Especially in old versions of IE (not so much anymore).
Or maybe it has something to do with Stallman's ranting ;-)
The main consideration is security. Drive-by downloads that exploit browser security holes via JavaScript are currently the most common way for malware to spread.
As well as what others have said it confuses search engines. The more 'dynamic' content you add the higher the chances it cannot be indexed. In addition the Internet is used by many as a reference library. Books in a real library do not change things around while you are reading the page. You may think of your site as an "application" but your users may prefer to treat it as a "document".
In short JavaScript obfuscates information, sometimes to the point of completely denying access (i.e., the JavaScript code is buggy and crashing). A classic example of this was that I was unable to watch the Live8 concert broadcast by AOL a few years back because the JavaScript code was so poorly written it didn't actually work on my girlfriends' AOL browser (ironic I know). I tried to get to the movie URL directly but the obfuscation was so complex I couldn't find it. It did nothing to endear me to AOL.
BTW, I happen to be one of those people who disable JavaScript by default. If I need it I can enable it for a specific site or page in 2 seconds (really) using the NoScript add-on for Firefox.
Some companies, or business units, have a policy of not allowing javascript turned on, as there are concerns about any risk of security exploits, and that may be the biggest problem, that since it can't be locked down securely then it must be disabled. If you can run javascript in a strict mode, that doesn't allow ajax requests, for example, then you may find that more people are willing to use it on computers that are concerned about security.
As long as a user can go to a website, and information can be sent transparently over the Internet regarding what a user is doing, then these security concerns will exist.
For example, I could have a Firefox plugin that appears to be useful, but, it can do possibly send unwanted info to a website.
Because it shifts load from the server to the client and there is no way to control to what extent.
I work with Javascript every day and respectfully acknowledge what it has made possible, but sometimes when I browse a very simple page, and the interface reacts lightning fast because there is nothing to render but pure, simple HTML, I think that that used to be the original purpose the purpose of the internet. You can, and I am exaggerating only little, browse these pages with a 600 MhZ Pentium with 128 megabytes of RAM without problems. While for a Javascript-heavy, effectful "rich" website, you need massive resources on the client side for a halfway smooth experience, and you need to update your equipent almost as often as gamers do.
Also, I generally feel some, not hostility, but slight annoyance towards Javascript because it massively increased development costs by adding a host of incompatible target platforms, version, obscurities and specialties to cater for, as well as a generally bug-prone, hard to debug and volatile environment to work in.
That said, I think the industry owes the creators of JQuery, Prototype and the likes big, big thanks, among many others.
JavaScript, as the inventor of JSON called it, is the virtual machine for the world. It's where billions of people are. This great exposure comes with some dangers other languages do not have to face.
Example. Write a site that just 'redirects' you to another site, where you can sign in. If you are not completely in control of your browser/URL etc. some JavaScript just could have loaded the page content from another site and will log your keystrokes. This could be achieved with a few lines of JavaScript. It's not really the fault (if it's a fault at all) of JavaScript, but all the components (browser, HTML, and this vast space, we call Internet).
Why is javascript allowed to be
disabled in the browser? (i.e. Why is
it considered bad?)
Because browsers are not prefect! And Its give you the way to safe yourself when you need it.
When security risk found out, they will just post in their home page
Please disable javascript until its fixed
Like this, (I dont have offical page right now, so googled from somewhere)
http://browsers.about.com/b/2009/07/16/firefox-3-5-users-should-take-action-immediately.htm
However, until a fix is released, I
recommend that you either disable
JavaScript completely or use another
browser.
There are a few rare instances where JavaScript can be dangerous (but so can anything, including the massively ubiquitous Flash). The reason users actually do disable it or use addons like NoScript is largely unjustified paranoia.
In the end, users don't stick with behavior that breaks the websites they want to experience. So, I wouldn't expect JavaScript paranoia to be a long-term issue as only more and more sites depend on it (like this one).
It's similar to the hype we saw around cookies several years ago.
It can crash the browser, or do annoying things to users.
However, now a days Javascript has become such an integrated part of the internet (Gmail, bill paying for many companies sites, ect) that if you did disable it then browsing could arguably be difficult for you unless you had exceptions.
JavaScript has some very "odd" language features, like the handling of missing semicolons at statement endings by just ignoring the parse error ("semicolon insertion") or the behaviour of the typeof operator (array is an object).
You really need to know the language to know which things you should do and which are bad.
But there are also really good points about the language, like that it fully supports functional programming.
It is bad only you visit questionable sites. Without javascript you won't have apps like gmail, yahoo finance, etc.
Why is JavaScript allowed to be disabled in the browser?
Perhaps because computers are tools that serve humans? Computers speaking to computers via a protocol can mandate specific behaviour. Developers writing software for users have no such luxury.
It would be pointless for browser vendors to mandate that JavaScript "must" be enabled, since there are plenty of people who can't or don't want it. Especially since 90% of the time it's just being used by some spotty hipster to animate a cat picture.