In gamedev, we often use UDP for network I/O.

I am far from an expert in security but I've done a bit of reversing/hacking when I was 16 years old (DOS era)

I think this is hard to check for everything, but in my opinion, good security can be achieved with extreme simplicity.

Packets are fixed-size, every fields are manually bound checked and the packet is rejected if anything looks wrong.

That jibes with my knowledge.

But I've seen some real weird stuff before. ;) Folks using variable-length fields and happily just dumping the contents into eval(), all sorts of awful.

Bad code is bad code, in any language.

If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.

No. Security is a full-stack endeavor. At all levels it is incumbent upon software professionals to build secure and resilient systems, any time they're exposed to a network. The OS should backstop your efforts, not replace them.

I disagree. As a user, I want to be able to run weird software without having it impact the rest of my system. Browsers and mobile OSs get this much more right than desktop OSs.

This does not meaningfully follow. What you "want" is orthogonal to the responsibility of the vendors of software.

The OS should protect where it can. So should software, lest your networked game nuke, say, the parts of your home directory to which it has permissions because without those permissions it can't do something it needs to.

This is just defense-in-depth. It's super basic stuff and HN is literally the only place I see people galaxy-braining about the idea that you have an obligation to not write shit code.

I suspect GP's point is that a networked game should be limited in access to only parts of one's home directory relevant for that game (that is: the game's own save data or configuration files or what have you). It is absolutely the job of the operating system to provide that sort of sandboxing/isolation.

Sure. That's great. That also breaks down sometimes, too.

Defense in depth. Write good, sane, secure, fail-closed code when you want to ship that code to other people--or don't write code.

That's not the point. The point is, if you do network I/O, you are processing untrusted packets from the internet. If a carefully crafted set of such packets can trigger, say, a buffer overflow, you're toast.

A first line of defence is authentication. Make sure the packets come from a trusted source (you can MAC each packet for this), so only those trusted sources could possibly trigger the vulnerability.

If the only trusted source is an authoritative server, you might be able to hide that buffer overflow. If your network code is peer to peer however, you have to trust the other players not to run a cheat that takes over your machine… but at least that's not the whole internet.