The "calamity" of "apps"

September 2014

A race for client control

Some may remember that the web used to be strictly composed of declarative documents; so was gopher. With the advent of Javascript, it became possible to have more control over the HTTP client (the browser). Initially, this seemed rather harmless, but as the functionality which JS permitted grew, and as we discovered the bugs which plagued some JS implementations, and which were exploited to for instance access user bookmarks and data, place a script as a spying proxy between the user and third party sites, the security community realized that a can of worms had been opened.

Also followed ActiveX controls, Java, and Flash (and later analogues), which allowed even greater control than what the Javascript of the time could. In the case of Flash, the user accepts to install a proprietary, closed-source, hence unauditable system, which has also proved to be heavily exploited, especially that Flash allows remote software to access not only one's files, but also one's camera or audio feed.

Motivations for enhanced client control include DRM (preventing the user to manipulate or access remote-provided content), enhanced multimedia experience, in some cases client-side security enhancements (ironically), vendor lock-in of some services, more interactive experiences for chat and desktop-like GUI forms, providing difficult-to-avoid ads, the implementation of user tracking web-beacons, and other reasons.

We could consider client-side scripts to be arbitrary remote-execution vulnerabilities exploited by server-side applications, although oftentimes there is an effort on the part of the implementors to sandbox and restrict what is possible to execute. An effort which is however often defeated. Recently, we discovered that even CSS, which was initially designed to be declarative, can be used to execute code. Javascript nowadays allows to access one's browser version (despite purposely forged HTTP User-Agent, which is an abomination by itself, as much as HTTP Referrer). Javascript even now allows filtered access to video hardware (WEBGL for instance, permitting the exploitation of hardware or software GL implementation bugs), and to arbitrary sockets (Websockets). Via the use of JIT and jsasm, it may also be possible in some cases to exploit CPU bugs. It suffices to say that some security-conscious organizations filter scripts at the proxy-level, for justified security reasons. This becomes increasingly crippling, as more and more sites do not degrade properly when used without scripts.

The advent of "apps"

"Apps" become ubiquitous, especially on "mobile platforms". These are applications which users accept to install on their computers, and which every site now wants users to download as part of a new fashion.

What too many users ignore is that by accepting to install those, they provide even more control to that third party than their web site ever could achieve, despite Flash and Javascript. Some devices will prompt the user on installation that the application needs access to this or that resource to function. Most people are unaware of the implications of this and install everything anyway. Moreover, most applications request access to resources which are unrelated to their actual purpose, in order to precisely obtain the more control possible on the user's device and stored information.

It is not far fetched for "apps" to remind us about the dangerous "screensaver" trojans, which many Windows users frequently downloaded from random sites. Installing third party "apps" is not much different.

Another interesting point is that various corporations have long fought to control the user experience by limiting and controlling what their computers can do, and pushing DRM. While many desktops and laptops have hardware DRM enforcing measures included, they usually are turned off, and won court orders permitted users to meanwhile expect that they can turn this feature off on off-the-shelf desktop and laptop hardware. This is however different with "mobile" devices. These usually ship with TPM or equivalent enabled, with a cryptographically signed operating system installed, and the user has no "root" or administrator access, unless bugs can be exploited to obtain such access on our own devices. This also hinders control like installing a third party, open source operating system of one's choice.

To finish this section, let's mention that those devices often track the user's position, and can even appear to be off when the camera or speaker might be actively recording and forwarding their streams to a spying party. And that GSM enabled devices are prey to mandatory silent/covert SMS messages, and that cell providers must also themselves implement mandatory "lawful interception" facilities on their networks. Last but not least, covert clandestine cell towers may be setup as espionnage and interception relays not only by governments, but by any corporation or criminal organization.


A popular example of malpractice is Badoo. A user who installs its "app", allows it to steal the contact/address book. Badoo then spams every address, voilating good IT practices as well as basic privacy; most of that user's friends now know that the user has recently joined Badoo. Those spam emails pretend that we received a message from that user, providing an URL to visit to read the message. That link redirects the Badoo sign-in process, pretending that an account is necessary to access the message. Once signed in, the user is deceived, there never was any such message in the first place, it was only spam; and if this user also installed their "app", their friends may also get caught in the same scam.

Better solutions

AJAX now mostly simulates an interactive terminal to a server (or cluster of servers), which is a type of return to the old days of mainframe and terminals. However, this is achieved with tremendous bloat, including compatibility with every silly web standard, and based on both unefficient and insecure technology.

The development of a new standard terminal, updated with all the necessary features for today, from scratch, could use interactive persistent connections, a declarative only protocol avoiding execution of remote-provided code. Although based on suboptimal technologies itself, the BEEP protocol and XForms seemed like promising future technologies. Unfortunately, AJAX now dominates, with XForms only present in the server-backend of some web applications, with an AJAX client frontend. Flash could have been a step in the right direction, had it been open source and auditable since the start, and designed properly, with efficiency and security in mind.

Instead of being embedded in existing web pages and run as a plugin in current browsers, the new technology should ideally run within its own separate application, such that it may discard every arcane kludge of the web, and avoid common pitfalls such as bloat, XSS vulnerabilities, inter-site local-storage and user tracking, etc. An application like online access to a bank could become more secure than with current browsers, the web and SSL/TLS alone.

Clustering, aggregating, etc, could be done server-side, or at the level of a middle-proxy, acting as the server-side. But this is the contrary to what vendors want: more client control. The resulting system would be lightweight enough that embedded devices, including "mobile" computers, could run it properly. This could then also replace the "apps". Web widgets, without the web. It could also encourage net neutrality.