A few years ago, the servers of my favorite online game were down for a few days and I was already afraid that my game character would get lost and die with all his achievements. Fortunately they fixed his problem and a few days later everything was back online. I wanted to be prepared for the next such incident, so I logged onto their website and took a screenshot of all my character properties.

For a moment I was happy. Next time, even if all the data was lost, I could prove what I had won and get all my stuff back. Then I looked at my screenshot and realized that I could just as easily modify it to get even better items in the game. So basically it was worth nothing. Digitally signing it myself wouldn’t improve that.

This scenario is not limited to online games. Being able to prove that an order has been placed, a violation has been committed or some task has been fulfilled seems to be worth the investment in general consideration.

Obviously, you cannot make and sign such a screenshot yourself. One needs the help of a trusted third party, but often the problem is too trivial to involve or even pay for a “real world” attorney. Your first thought might be to check if some archival websites like archive.org might happen to have a copy of that page. They often don’t. And even if it was, they could never have accessed the parts protected by login.

No automatic tool can master the steps of the login process, and if website owners consider using a captcha, there is little hope that a program can bypass it. This has to be done by hand and by a web browser. So some people try to use plugins to save and digitally sign all the data sent from the server.

Once again, this is not the solution. It’s relatively easy to manipulate DNS or routing on your machine so that another computer or even a virtual machine plays the “server” role. Browsers protect against this type of fraud by using SSL and certificates, but this only applies to encrypted traffic and installing your own “root certificate” to allow man-in-the-middle manipulations is common practice.

Careful verification of the keys used could expose such methods. If all transmitted data were encrypted by asymmetric codes like RSA, this could even be considered already signed by the origin server, almost killing the problem. But for performance reasons in SSL, asymmetric methods are only used to transmit key phrases for faster symmetric encryption. So spoofing a record of the encrypted code of the data actually transmitted is theoretically possible for the client, since it knows that symmetric key (though probably even more difficult than reverse engineering some plugin).

To avoid all these problems, the browser should not be running on your own computer. What is needed is the so-called “Remote Controlled Browser” (ReCoBS) as it is used, for entirely different reasons, in high-security installations. This is a browser running on a different computer, controlled by a third party, that sends only a video stream of its windows to the client and only accepts a limited set of commands. This remote browser can perform all login and signing operations as it cannot be tampered with by your user.

What paths of attack against this system should be considered? First, there is the possibility of hacking the entire ReCoBS. Having a browser controlled by a remote and possibly unknown user is a risk in itself. The browser has to run inside a tightly locked sandbox, not only protecting the system from hacking, but also preventing interdependencies between parallel or subsequent sessions on the same computer.

When it comes to spoofing web session results, DNS cache poisoning seems to be the most dangerous option. This can be addressed by using DNSSEC when this will one day include the entire web, or possibly by having a network of machines across the world and routing the DNS request down a random one. Script injections into visited websites are a second way to get manipulated results, but there can be no functional countermeasure by ReCoBS if the injection comes from a fourth party, and being open to such an attack in the first place should be a bigger problem. to the affected site than the logs created by it.

Even considering these problems, ReCoBS seems to be the only option that offers at least a theoretical chance of credible evidence. If implemented correctly, they can work. Most other technologies have design flaws and it is only a matter of time until public vulnerabilities become available.