Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The spectrum of isolation: From bare metal to WebAssembly

buildsoftwaresystems.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: The spectrum of isolation: From bare metal to WebAssembly

#21

Post by fuzzfactor »

ThierryBuilds wrote: post #2

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…

>1. Physical Machine (Bare Metal) This is the foundation.

Nobody should ever forget this.

But I would say this next part is about the opposite for bare metal though:

>Use Case: High-performance computing (HPC), large databases, or legacy systems that require direct hardware access.

To get the utmost reliability out of adequate hardware then bare metal is more suitable for almost everything except for special situations.

Unless something is really wrong with the software or the overall hardware/software approach.

Re: The spectrum of isolation: From bare metal to WebAssembly

#23

Post by bflesch »

rafram wrote: post #20
bflesch wrote: post #6

> 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?

Google Fonts is not a tracker. https://developers.google.com/fonts/faq/privacy > For clarity, Google does not use any information collected by Google Fonts to create profiles of end users or for targeted advertising.

Google has carte blanche to lie to foreigners for national security purposes, it's not even illegal for them. The data is fed into the mass surveillance systems.

IP, user agent, language headers and network timings are enough to fingerprint and associate you with any other accounts at US tech companies. The visited website is linked via Referer / Origin headers to your browsing history.

All of this tracking is passive and there is no way to check for an independent observer.

Yet here you are defending the most privacy invasive company on the planet.

Re: The spectrum of isolation: From bare metal to WebAssembly

#24

Post by bflesch »

Piraty wrote: post #18
cardanome wrote: post #12

Earlier quoted context omitted.

The easiest solution is to simply self host your fonts.

remember the times when common sense was to not accept the remote site's fonts, and thus web devs should not use them

Yes. I recommend everybody to do a deep dive into font file formats and you'll see a lot of monsters hiding.

Re: The spectrum of isolation: From bare metal to WebAssembly

#25

Post by ignoramous »

pjmlp wrote: post #11
ianand wrote: post #3

Earlier quoted context omitted.

Since you mention serverless it might be worth mentioning firecracker and v8 isolates.

Or CGIs running on httpd inside HP-UX Vaults, that is how old the idea happens to be.

> how old the idea happens to be

TFA is missing a host of many a popular isolation techniques like Isolates, Code Interp / Binary Translators [0], Enclaves, Exclaves, Domains/Worlds, (RISC V) SEEs, TEEs, SEs, HSMs, pKVMs ...

[0] https://news.ycombinator.com/item?id=38950949

Re: The spectrum of isolation: From bare metal to WebAssembly

#26

Post by pwdisswordfishy »

rafram wrote: post #20
bflesch wrote: post #6

> 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?

Google Fonts is not a tracker. https://developers.google.com/fonts/faq/privacy > For clarity, Google does not use any information collected by Google Fonts to create profiles of end users or for targeted advertising.

Well, if Google said it, it must be true.

Re: The spectrum of isolation: From bare metal to WebAssembly

#27

Post by ThierryBuilds »

fuzzfactor wrote: post #21
ThierryBuilds wrote: post #2

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…

>1. Physical Machine (Bare Metal) This is the foundation. Nobody should ever forget this. But I would say this next part is about the opposite for bare metal though: >Use Case: High-performance computing (HPC), large databases, or legacy systems that require direct hardware access. To get the utmost reliability out of adequate hardware then bare metal is more suitable for almost everything except for special situatio…

Thanks for the feedback. These are typical use cases where the convenience of higher level abstractions may be less important than the benefits of direct access to the hardware.

Re: The spectrum of isolation: From bare metal to WebAssembly

#28

Post by ThierryBuilds »

bmitch3020 wrote: post #15

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…

Agreed. Beyond security, we must consider other critical factors such as cost, ease of maintenance, and operational overhead.

Re: The spectrum of isolation: From bare metal to WebAssembly

#29

Post by ThierryBuilds »

creata wrote: post #16

venv and sandboxes are such categorically different things that painting it as a spectrum the way this article does is more misleading than helpful. 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. (I'm not sure what point there is in…

The article is not only about security. Thanks

Re: The spectrum of isolation: From bare metal to WebAssembly

#30

Post by Loic »

bmitch3020 wrote: post #15

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…

This is the engineering approach in a factory. You always have multiple layers of security systems.

The analogy is that each layer is a slice of Emmental cheese. You end up with a bad event, only if all the holes in the slices align.

Post reply on HN