Hacker News Reader

Comment by abound | Hacker News Reader

It's a generative art platform/marketplace. You write an algo that generates art according to some number of parameters, upload it as a Docker image, and let other people tinker and generate things they like the aesthetics of. Basically remote code execution as a service, but I spent a lot of time on the sandboxing side of things and feel pretty good about it.

The infra is tuned for "saving money" and not "scale", so there's a chance it falls over under even modest load. If folks are interested I can tweak it a bit to make it more scale-y.

It's also my HN name, because all the other (one word) ones I could think of were taken.

View on HN

I wanted to build something very similar a while back. Spotify (or Instagram) for generative art. I guess https://www.dwitter.net is kind of like that as well. But specifically, I wanted to build some sort of revenue sharing for the artists, similar to Spotify's model.

Re: revenue sharing - we (my friend who I built this with, and I) were thinking along the same lines, it's actually fully implemented here. If user A uploads an algo, user B generates art with it, and user C buys that art, money will be distributed to user A and user B. Details are here: https://abound.art/artists

This is really cool! How did you solve the sandboxing?

Assuming this isn't an attempt to mine cryptocurrency on it :), here's what I did:

- Turn the Docker image into a Firecracker VM, I stole the idea from Fly.io [1]. Add all the trimmings like jailer and stuff, don't give it any network interfaces

- Run our own shim as PID 0 in the VM, which sets up a bunch of things to make the environment hermetic (time set to 1970, etc), and does some stuff with eBPF to monitor usage by the child process, and also enforces 1 minute timeout

- Run the jobs on a parent VM that doesn't otherwise have any privileges

- Copy images pixel by pixel (for raster images) or remove all the shady parts of an SVG that we don't otherwise trust

- Other general defense-in-depth stuff, validating request/response sizes, minimal privileges on separate services, private networking throughout.

[1] https://fly.io/blog/docker-without-docker/

This seems very comprehensive, thanks for sharing :) I'm working on something similar myself which involves running untrusted user-provided JavaScript... It's a little scary but I'll definitely be taking a closer look into Firecracker. Cheers!

Reply on news.ycombinator.com