An experiment with a secure web browser fails

A web browser is an attack surface. Because it downloads stuff from the Internet, it can download something malicious that infects your computer. Even reputable websites have been infected with malicious ads.

There are many ways to make web browsers secure, but to me, the most secure option is not running the browser on a computer you care about. Run it somewhere else. 

This way, if the browser does eventually serve as a gateway to infecting an operating system, the impact is minimal or trivial. And, you can start off with a safer operating system in the first place. 

One way to run a browser on another system is virtually. The browser runs inside a "guest" virtual operating system, walled off from the "host" real system. But virtual machines are complicated, resource-hungry things. I hoped for something simpler.

The most secure computer you are likely to encounter is a Chromebook (or Chromebox) running in Guest Mode. Guest mode starts and ends with a virgin copy of the operating system. There are no bookmarks, saved files or Chrome extensions in Guest Mode. Websites may track you, but only until you logoff. Guest mode offers the benefits of a virtual machine, without the hassle. 

So, I thought, why not remotely control a Chromebook?

Chromebooks support many remote control options, but they only allow it to be the "controller" rather than the "controllee". The one exception is Google's own Chrome Remote Desktop.

But, right off the bat, there is a limitation  - you can't remotely control a Guest mode session on a Chromebook. Chrome Remote Desktop is an extension and all extensions are off-limits in Guest mode. Still, even logged on as a Google user, Chrome OS should be much more secure than a desktop OS.

As seen above, there are two modes of operation for Chrome Remote Desktop; Remote Assistance and My Computers. The difference between them is not at all obvious, but it seems that a Chromebook can not be used with the "My Computers" approach. The screenshot was taken on a Windows machine, on a Chromebook there is no gray button to "Enable remote connections".

So, I started a Remote Assistance session by clicking on the green "Share" button on the Chromebook. This displays a 12 digit number that needs to be entered on the "controller" machine, in my case a Windows 7 laptop. 

The first time I tried this the Chromebook was using Wi-Fi and it was slow as heck. So, I disabled Wi-Fi and connected the Chromebook to my LAN via an Ethernet to USB adapter cable. The Windows laptop was also Ethernet connected. 

The first test revealed another limitation, the screen resolution. The Chromebook has a screen resolution of 1280x800, which looks awfully tiny on a laptop with a much higher resolution. Other remote control software can scale this up, but that doesn't seem to be an option with Chrome Remote Desktop.

I have used my fair share of remote control software and response time has not been an issue for years. Given that both machines were wired into the same LAN, I expected good performance. But no, the remote control session remained slow. Very slow.

Another limitation of Chrome Remote Desktop is the lack of performance tweaks. Competing products can limit the number of colors or suppress the desktop background to speed things up. Chrome Remote Desktop has no such options.

Some remote control programs can suppress the screen display on the remote machine. Perhaps in the "My Computers" mode of operation Chrome Remote Desktop can do so, but the Remote Assistance mode displays the screen image on both computers.

And, it seems this was putting too much of a strain on my admittedly low end Chromebook (an ASUS Flip with 2GB of RAM).

The Chrome browser has its own Task Manager, which you can access by clicking on the "More tools" option off the hamburger menu. On the Chromebook, it showed that the GPU Process was using 188% of the CPU (see above). Without Remote Desktop, the GPU Process uses only 5% of the CPU. Beats me why the percentage goes over 100.

Remote Assistance lets both computers drive. That is, the mouse and keyboard are functional on both the controller and the controllee machine. I mention this because performance was also poor on the Chromebook, perhaps even worse. A few times I tried using the Chromebook directly to click on buttons and couldn't. Not only did the cursor move slowly, it would jump over the button.

Despite the two machines being on the same LAN, they were not talking directly to each other. The Chromebook screen image was being sent out my router to Google, and then downloaded back from Google into the Windows 7 machine. Obviously, this is the wrong approach. While I like the idea of remotely controlling another LAN-resident computer to use its web browser as a sacrificial lamb, the remote control session should travel exclusively over the LAN.

But, even ignoring performance issues, Chrome Remote Assistance is just not designed for long sessions. After a few minutes, the warning below popped up, and it had to be responded to on the Chromebook.

And, to beat a dead horse, the session disconnected on me, twice.

BETTER OPTION? 

Going back to the drawing board, it seems that the safest option would be to remotely control a Linux system running inside a virtual machine.

Linux is the safest desktop operating system and it supports Firefox, Chrome and Opera. It also supports my preferred remote control software, RealVNC. The virtual machine lets me backout all activity and restore the system to the exact state it was in previously. 

Of course, setting this up takes a lot of work.

Just deciding on virtual machine software and a particular Linux distribution is hard enough.Then, both products need to be installed and configured along with the browsers and the remote control software. And afterwards, I would be on the hook for bug fixes to Linux, the remote control software and the virtual machine software. 

No wonder no one does this.