The spectrum comes with multiple tradeoffs, and isn't a simple "bare metal is more secure" narrative. Because as you move into VMs, containers, and code sandboxes, you lose isolation which increases risks, but you also gain capabilities to limit the application which decreases risk. So I believe the most secure approach is layered with much multiple types of isolation working together.
For example, you may isolate a specific customer to bare metal so an escape doesn't compromise other customers. But within that bare metal, you may run containers because they make it easier to work with a read only root filesystem that's also trivial to upgrade. You can also add on user namespaces and seccomp in the container to minimize the risk of a container escape. And then the application may have its own sandbox that limits individual capabilities and which API calls it can run.
Every use case is different, and some layers may not be available depending on that use case. But rather than picking one point on the spectrum, one should pick a list of technologies that best solve each use case.
I wrote this because I kept seeing developers (myself included) confuse language-level isolation like Python venv with OS-level isolation like Docker. I wanted to trace the actual technical boundaries between them.
The article maps out the differences between common execution environments—from physical bare metal and VMs to containers, process sandboxes, and virtual environments—to create a mental model of where the "isolation boundary" actually sits for each tool.
It also has weird definitions. Is nix a virtual environment? Is homebrew a virtual environment? Why is a sandbox different to a container? Type-1 vs Type-2 hypervisors are quite different, and there's no discussion about processes vs threads.
> This website collects anonymous usage analytics data via GoatCounter and Umami.
My uBlock origin shows that googlefonts.com and fonts.googleapis.com are being blocked.
It irks me a bit that your message explicitly mentions two trackers but it fails to mention the Google tracking. Google is also not mentioned in your privacy policy. Is there a reason for this?
Your message sent me down a weird rabbit hole of trying to find privacy friendly alternative to google fonts. I found this: https://github.com/coollabsio/fonts
They claim to be a privacy friendly drop-in replacement. Their main website: https://fonts.coollabs.io/
The easiest solution is to use the default font. This has the additional benefit of being the most legible font for every reader, because it's the one they have the most experience reading.
1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM
2. to create plugins that extend the backend and add your own endpoint or middleware as a way to enforce the code run in a constrained environment without the ability to send people's file out
3. in the workflow engine to enable people to run their own sandboxed scripts without giving those a blank check to go crazy
It is more of a silent thing. Running in the background, internal libs, deployment tools, plugin tools.
But also - it's lacking things like a unified positioning + required knowledge to understand it is quite large compared to average dev + most people have no real use for it. It's mostly too "abstract high level" and "low level" for most devs.
I also think the article shouldn't mention chroot. From the man page:
> In particular, it is not intended to be used for any kind of security purpose,
I guess it could be part of a sandbox, but there are better tools for that purpose.
For example, you may isolate a specific customer to bare metal so an escape doesn't compromise other customers. But within that bare metal, you may run containers because they make it easier to work with a read only root filesystem that's also trivial to upgrade. You can also add on user namespaces and seccomp in the container to minimize the risk of a container escape. And then the application may have its own sandbox that limits individual capabilities and which API calls it can run.
Every use case is different, and some layers may not be available depending on that use case. But rather than picking one point on the spectrum, one should pick a list of technologies that best solve each use case.
The article maps out the differences between common execution environments—from physical bare metal and VMs to containers, process sandboxes, and virtual environments—to create a mental model of where the "isolation boundary" actually sits for each tool.
My uBlock origin shows that googlefonts.com and fonts.googleapis.com are being blocked.
It irks me a bit that your message explicitly mentions two trackers but it fails to mention the Google tracking. Google is also not mentioned in your privacy policy. Is there a reason for this?
1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM
2. to create plugins that extend the backend and add your own endpoint or middleware as a way to enforce the code run in a constrained environment without the ability to send people's file out
3. in the workflow engine to enable people to run their own sandboxed scripts without giving those a blank check to go crazy
But also - it's lacking things like a unified positioning + required knowledge to understand it is quite large compared to average dev + most people have no real use for it. It's mostly too "abstract high level" and "low level" for most devs.