development programming security

NMandelbrot : running arbitrary code on client

As part of my grand plan for map-reduce in JavaScript and zero-install distributed computing, I had to think about how to gain user trust in a security context where we don’t trust the server. I couldn’t come up with a good answer.

Since then, we’ve seen stories of malicious JavaScript installed to mine cryptocurrencies¬†, we know that JavaScript can be exploited to read kernel memory, including passwords, on the client, and I suspect we’ll see a lot more restrictions on what JavaScript is allowed to do – although as the Spectre exploit is fundamentally an array read, it’s going to be a complex fix at multiple levels.

I had ideas about how to sandbox the client JavaScript (I was looking at Python’s virtualenv and Docker containers to isolate code, as well as locking them into service workers which already have a vastly more limited API), but that relies on the browser and OS maintaining separation, and if VMs can’t maintain separation¬†with their levels of isolation, it’s not an easy job for browser developers, or anyone running on their platform.

I also wondered if the clients should be written in a functional language that transpiled to JavaScript, to have language level enforcement of immutability and safety checks. And of course, because a functional style and API provides a simpler context to reason about map-reduce, by avoiding any implicit shared context.

Do you allow someone else’s JavaScript on your site, whether a library, or a tracking script, or random ads from Russia, Korea, botnets and script kiddies? How do you keep your customers safe? And how do you isolate processes you trust from processes that deal with the outside world and users? JavaScript will be more secure in the future, and the research is fascinating (JavaScript Zero: real JavaScript, and zero side-channel attacks) but can you afford to wait?

Meltdown and Spectre shouldn’t change any of this. But now is a good time to think about it. Make 2018 the year you become paranoid about users, 3rd parties and other threats. The year is still young, but the exploits are piling up.


code lifehacks programming

Outrunning the lions

Just a short post today (stop cheering at the back). I’ll do a longer post on the html5 survey next month, it’s still open if you want to fill it in.

There are two explorers in the jungle, who come to a clearing and find themselves face to face with a lion. One of them immediately takes off his backpack and starts putting on his trainers. “What are you doing?” asks his friend, “You can’t outrun a lion.”

“I don’t have to outrun the lion,” he replies, “I just have to outrun you.”

When you’re you are choosing your security, or your feature set, are you trying to outrun the lion or are you just trying to outrun the competition? IE6 got away with a lot because it only had to outrun Netscape 4. Chrome re-wrote the rule book on browser speed and html5 features because it was trying to outrun the lion, not just ie and FireFox. Decide for yourself which browser represents the software you want to write.

Now, how about I move to California and start a motivational speaking course…