And yet, you are unlikely to know most of them. Why?

The browsers wars

In line with the military origins of the Internet, even the Web began with its own wars: the browsers wars. It was a set of complex commercial competitions — books-worth of material by itself, complete with twists, plots, Trojan horses, cleaver hacks and so on…

However, for our purposes it’s enough to note that in late 2004 one single browser was winning hands down.

That browser was Internet Explorer 6, serving 92% of the people of the Web.

I was young back then, and a strong supporter of cool technologies such as XHTML, CSS, XSLT, XSD, Atom and RSS — technologies I used daily in my job as a web developer (or what one would now call a full-stack developer).

The great idea behind XHTML was to make the web contents easy to parse from the machines while keeping them easy to write by humans.

With CSS and XSL we were half-way towards a full separation of concerns between presentation and contents. With XSL-FO I was even able to extract contents from well designed web pages and produce nice PDF reports.

The stack had its issues, but overall it was a godsend.

Back then, few lines of XSLT were able to extract contents from web pages, or to remove annoying contents such as Ads.

I was also quite good at JavaScript, a language that was useful when you had to handle the differences between browsers without overloading the server or when you wanted a faster validation feedback on a form.

In this context, IE6 was a pain, but I couldn’t imagine what was going to come.

HTML5

We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers — the Web page designers — would assemble components and automate their interactions using JavaScript.

The history of JavaScript starts with a 10 days hack from Brendan Eich.

This was in 1995.

JavaScript served its purpose pretty well for almost 10 years.

It was a small little language — a tool to move images on web pages, to do some early form validation, and few other DOM-related little stuffs.

It was also common to browse the web without JavaScript enabled, and every professional web developer used to test web sites for this use case.

After all, there was a huge effort ongoing to make the Web accessible.

But suddenly, in 2004, Apple, Mozilla and Opera became “increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML, and apparent disregard for the needs of real-world web developers”.

I was a real-world web developer back then (and I still am) but I couldn’t see the problem. Nevertheless, they created the WHATWG to fix the issue.

After all… they were serving 8% of the Web!

They introduced the concept of Living Standards — ever-evolving documents, unstable by design, that no one can really implement fully.

Somehow, in 2007 they convinced W3C to market the existing version of such unstable drafts as what we now know as HTML5.

HTML5 was not really about HTML. It was just about JavaScript.

Up to HTML4, the web was an HyperText.

Both the protocol and the markup language were very clear about that.

Its purpose was to serve interconnected texts to the people.

It was like a public library with great cross-references.

With HTML5, the web became a platform to deploy and distribute software.

The useful changes to the markup language were minimal. The only change worth noticing was the abandon of XHTML. And many asked: “why?”.

But with HTML5 a whole new set of browser services became available through various JavaScript APIs. These APIs created an huge entry barrier to anyone that wanted to create a browser: most browsers were unable to meet such ever-changing over-complicated requirements, and never implemented the WHATWG’s living standards.

So, HTML5 was a game changer.

The Web stopped to be an HyperText medium serving people.

It became a marketing platform serving personal data collection.

Suddenly, removing annoying contents became harder.

Suddenly, each click, each scroll down, each zoom on a text or a image became an observable event that can be recorded to profile a user.

…and JavaScript became a weapon

In 2007, I was really surprised by the W3C abandon of XHTML.

I was annoyed by this, since we had a pretty good infrastructure built upon the XML/XHTML stack. And while I did like JavaScript back then, I didn’t really understand the move.

My boss told me: “You shouldn’t ask why, but who!”. He was right.

In HTML4, JavaScript was a toy. It had his issues, but it was a toy.

With the HTML5 usage, a huge number of security issues became evident.

But with the scandal of Cambridge Analytica I realized that the worst security issue is inherent to JavaScript design itself.

You execute a custom program controlled by someone else.

Someone else that knows you very well. That can read your mails.

That knows what you read. That knows what you look for.

That knows where you live. That knows your opinions.

That knows your friends. Your tastes…

Someone else that can serve to you, specifically to you, custom JavaScript that you will run under the laws of your country, without responding to such laws.

A precision weapon

Today, most people cannot really browse the web without JavaScript enabled.

But, just like Ads target your specific desires, a web site can send you JavaScript that fills your disk with illegal contents. In the cache.

The illegal contents will be trivial to find during a forensic analysis, but the malicious script will be able to remove all evidences of the breach by simply reloading from its own URI an harmless version to rewrite the cache.

This is just one of the possible attacks, but not to every visitor; it would be too easy to catch: it’s just for you, because you are an annoying guy that does not conform with the masses.

Unlike the DNS system (a coarse weapon, only for the USA’s use, and only capable of targeting large regions), JavaScript is a weapon to target specific persons with plausible deniability.

The servers know you. Very well. Very very well. ;-)

And they serve you JavaScript programs that you execute blindly.

What can go wrong?

Enter, WebAssembly!

JavaScript is a poor language.

Dumb developers obfuscate it and smart hackers deobfuscate it.

And even in obfuscated form, a motivated JavaScript programmer can read and debug it anyway. Worse, as a reminiscence of old times, when the Web was a library instead of a market place, all browsers have that annoying View Source button that let you inspect the actual code executed by the browser, not just what such code want you to see.

Even as a weapon… JavaScript is a pain in the ass!

If you serve malicious JavaScript to a single user the probability that you will get caught is low, but it increases by an incredible margin when serving hackers and web developers.

We really need a binary format that no human could read!

And we really need to remove that annoying “View Source” button!