Rebuild the World!

The situation when a code is downloaded from the Internet and then immediately executed, is too usual nowadays. It is not only JavaScript executed within the user's browser; automatic software updates are effectively the same sh*t. And all this is not only inappropriate, it is horrible. When you get your code executed on someone else's device, it means you take over the control, and this is not the thing to do without explicit consent of the device's owner. In fact, “download-and-execute” is an anti-pattern; ideally, this should be considered criminal and punished by several years in prison; if it is not yet so, it's only because all these law-makers don't understand how computers work.

But we do understand, right?

So, as a rule, any program can be executed on someone's computer only after explicit installation performed by the user, and upon explicitly given user's well-informed consent.

Once again: the consent must be given by the user explicitly, for every particular case when any new program code is transferred to the user's device, before it is actually executed. All these “implicit consents”, and even some “explicit” cases like a paragraph in a EULA which no one reads, don't work here.

So, first of all, forget about any automation for software updates. If you have an update for your software and believe all your users should definitely install it as soon as possible, the only thing you can do is to make the update available, so that people can download it and install. By their own explicit action. Willingly.

Most of your users will perhaps ignore the update. You may think they're wrong, and, actually, you may think whatever you want; however, they are on their right. Absolutely no measures are acceptable to force the users to update, anyhow, no matter how 'soft' the measures are.

Actually, each time an 'automated' software update is done, it is more or less clear that, should this update was not automated, only a small fraction of the users would install it manually. All the rest, who wouldn't, are to be considered as crime victims, and the crime is commited by those who — no matter how — made the innocent users have the software update they don't need. Hell, what? You think they do need? You're wrong, they know better. It is their hardware, not yours.

And don't bother telling stories about those 'security-critical' things. Any automation of software updates is an obvious backdoor, which is a security hole in itself, so automated software updates, being implemented, ruin any security, making all these stories a nonsense.

This all means, BTW, that you definitely must pay more attention to your code quality. Generally, once you made a release, you can't take it back and you can't fix anything. If you introduced a security hole into your users' systems, this can not be effectively undone. There are no excuses for irresponsibility.

The second, but perhaps even more important thing, is: forget about the very possibility of executing anything within the browser. Absolutely no exceptions are tolerable here.

Most of the existing web-sites nowadays transmit a lot of JavaScript to be executed on the visitor's computer, and the vast majority of them simply don't work with JS being disabled in the browser. This is horrible. And this can't in no way be tolerated. Furthermore, CSS level 3 appears to be Turing-complete, so using it is not appropriate, too. Besides, HTML5, adopted as a 'standard', has no right to exist because it implies heavy use of client-side scripting; this is not the only reason for it do be sentenced to death. Actually, the World Wide Web in its present state must be demolished completely, and not only because of JavaScript, but this is a topic for a separate writing. As of now, we repeat it once again: it is absolutely intolerable to transmit any code to users' machines and devices and expect it to be executed, specially if there's even a small bit of pressure on the user to let this happen. Actually, the pressure must be right the opposit: we must do our best to convince our users they should never let any downloaded code get executed.

Some devil's advocates are likely to ask one question they're sure to be smart: hey, HTML is a code, too, and it is interpreted at the user's computer, and perhaps formats like jpeg or mp3 are not much different from programs, too. And if these are not programs but simply data, then why don't consider JavaScript being just data, not a program, as well? Where is the exact border between programs and data?

The obvious answer here is Turing-completeness of the interpreter, but unfortunately this doesn't work against devil's advocates. Once they hear about Turing machine, they always come up with the argument they tend to consider killing: all the real-world computers are finite, so they are always Turing-incomplete. Computer scientists often try to argue somehow, but the problem is that devil's advocates are not willing to gain any knowledge, they merely wish to convince the public (not the opponent) that the “download-and-execute” crime is not really a crime nor even a problem, that's all.

So, Turing-completeness doesn't work for us, and here's our answer on where's the border: a format must be considered representing programs, not data, in case it allows to make loops of any kind, be it explicit loop constructions, an implicit loop made by a jump backwards, or a recursion.

HTML, fortunately, doesn't have anything of these. Okay, we know about these XML entity bombs, but the possibility to create new XML entities is disabled in browsers.

Once again: if a data format has features to let a certain portion of data to be interpreted more than once, then it's no data, it's a program code.

By the way, yes, PDF is no data. PDF “documents” are actually programs. And it is a real problem.