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.

 

Advertisement

Distributed development

DunDDD

One of the things I’ve enjoyed most in the last couple of DDD conferences I’ve been to has been the group discussion sessions that created the mindmaps you can see in my other posts. With DDD Scotland on hiatus this year, I’ve realised how much I miss the chance to talk to developers across the country about the things that matter to us. So, I’m going to start running the Google+ hangouts again as an opportunity to explore these issues, and with the addition of mindmaps as an app in Google Drive, we can generate a useful artifact for further discussion.

For the first topic, I was thinking about an issue that I’ve been dealing with, and have learnt a lot of lessons in, that plays into the same area as hangouts : how do you develop software when your developers and your users are distributed across multiple locations. Building a team and a client relationship is as much about the atmosphere and the team dynamics as it is about the skills and the people. Without that interplay, teams don’t gel as well, they don’t have the same trust in each other, and there is greater friction between locations.

And there are physical barriers too, even if you are in the same timezone. Central services will always be slower from remote locations, the serendipity of overhearing co-workers struggling with that problem you had last week is reduced, and any system of whiteboards and post-it notes doesn’t travel.

I’ve learnt a few ways to alleviate these potential hazards, and I think I can build an effective cross-location development team. But I want to learn from what others have done.

If you’re interested, let me know, and I’ll get a hangout set up for a week tomorrow (Wednesday 16th May)

If you’ve got any ideas for other discussion topics, please let me know.