I disagree: self hosting and enterprise are not mutually exclusive. In fact, “enterprise on-prem” is the marketing description for self-hosting. I do not accept any definition of self-hosting that gate-keeps to any degree.

It is incongruous to talk about “only home self-hosting” or “only enterprise on-prem” when it comes to security mitigations, threat modeling, and risk management: it is merely a question of scale.

Sure, the user base for a home setup might be single digits, but the attackers are identically situated: their capabilities do not grow or shrink based on whether they are targeting a bank or a Jellyfin server.

In a nutshell, doing it this way adds robustness when – not if – the destination software changes its behavior, inadvertently or not. It’s very similar to software assertions: if this assumption stops holding, then we want to know ASAP because it means subsequent logic is no longer valid.

In the Immich case, the author writes:

This is a side effect of how Immich checks permissions, not a feature made for this purpose, so a future version of Immich could change it. If this ever changes, the share links will answer 404 and I will notice quickly.

Suppose the author updates their Immich instance but missed a remark in the release notes that share keys will be using a different hash algorithm. That’s a mistake with their upgrade procedure, sure, but it’d be ideal if such mistakes were detected sooner than later. Without the check for link validity, the only log that would record the now-invalid share links would be in Immich logs. But with this additional check, there is also a log at Caddy. More visibility, combined with an existing alerting regime, means errors and mistakes are captured earlier.

At first glance, it might seem like both approaches still result in a 404 for the user, which suggests neither approach is really “robust”. But one is a near-silent failure yet the other gives a loud, unmistakable signal that something is broken, meaning it can be addressed. Phrased another way, the signal-to-noise ratio of an assert fail is very strong.

If you’re dealing in probabilities, that’s not threat modeling; it might be in the larger umbrella of risk management though. Defining a threat model means to qualify what sort of attacker you expect to face and what they are assumed to be capable of. An assumption such as “this adversary can send arbitrary packets to the public IP address” is what would be documented in a threat model.

The raison d’etre of threat modeling is to methodically tackle the actual or assumed risks that an attacker can pose against you. It is not an exercise in swinging at shadows, though I wouldn’t discourage overstating the capabilities of an attacker, if needing to protect assets like patient info or PII. Doing threat modeling based on “gut feeling” is a recipe for not recognizing risk where it’s present and seeing risk when there isn’t any.

The fact remains: you cannot squeeze blood from a stone. Even the most sophisticated AI cannot steal PII from a computer that doesn’t store PII. Proper threat modeling means you don’t put anything on the line that you haven’t squared up against the risks, however improbable. For any non-zero concern, a good threat model will discuss its mitigation, whether it will be absorbed, or if it is an open question. For an out-of-scope concern, a good threat model will explicitly state that assumption.

Answering the titular question, why would the advent of AI-found vulnerabilities substantially change one’s threat model? Before LLMs, the prospect of an undiscovered vulnerability was non-zero probability then, so what exactly has changed now?

In terms of attacker capabilities, it would be a mistake to solely observe that attackers now have LLMs and conclude that this means the threat landscape has changed. The use of LLMs does not magically create a root escalation where one does not or cannot exist. Part of your threat model should include defense-in-depth mitigations, so that when (not if) an attacker finds a 0-day exploit, they are severely limited in gained functionality on your machines. In the simplest cases, jails or containers serve to keep separate the web-facing processes. VM isolation would be a further step, because an attacked cannot gain machine control without both a software exploit as well as a VM escape route. People hosting services can and should expect that their front line defense will fall, so they better have more defenses in place.

Phrased another way, the people who have done their threats analysis properly and have accepted the residual risk of hosting their own services that face the web, should not really be additionally perturbed by AI advances. This isn’t the same caliber of landscape change as would, say, the invention of a cryptographically relevant quantum computer. If the worst thing that can happen to your home IRC server is that it gets flooded by a script kiddie, AI does not mean your server can now burst into flames.

Much like with human hygiene, some basic rules are unusually effective against most threats. The equivalent to washing one’s hands is to stay on top of system and software updates. Institutionally funding the organizations (eg PHP Foundation, curl, USA CDC) so they can fix these problems would also help.

deleted by creator

If the backing files are referencing “snapd”, then it seems plausible that these are the sandbox filesystems for software packaged using the Snap environment.

This is an awesome series, but that 20 month wait for a /24 IPv4 subnet would be unbearable to me. I’d rather just go mostly-IPv6 and maybe run NAT64 or something on a VPS to cover legacy uses.

I say this because while some are fine with waiting, I view self hosting as an act of self sufficiency and resilience, which really shouldn’t be on someone else’s timeline. If IPv4 subnets are the only thing holding someone who’s willing and able to run an AS, I would genuinely recommend ditching IPv4 and the scarcity that comes with it, even with the translation costs elsewhere. Perfection must not become the enemy of good-enough.

Port forwarding is moderately simple but there are risks to just opening a port and not guarding it with appropriate firewall rules. This includes an SSH server if not up-to-date.

Whereas setting up something like Tailscale on your machine and on your laptop is exceedingly straightforward, avoids firewall reconfigurations, and Just Works™. You could then connect to whatever service you have running, just as if you were on your LAN. My only gripe is that you do need a Google/Microsoft/GitHub/Apple account or OIDC to set up.

In the long term, if you have misgivings about that company operating the coordination server necessary for this tunneling solution, then there’s always the open-source Headscale, which is a drop-in replacement.

My network and server setup eat about 200 W, split right down the middle. I have plans to cut the network consumption by replacing the PoE switch, so that I can use the savings to add another server.

So it’ll still be about 200 W, but more useful.

This is the homeserver written in Rust, right?

A suggestion: wherever a QR code is included, the human-readable content should be included next to it. Not everyone has a QR code reader handy, or their reader has the bad habit of immediately opening links or apps. In this case, I see that it just goes to https://continuwuity.org/ and is benign, but others may be apprehensive at naked QR codes.

(there’s obviously an exception for QR codes that are intended to convey machine info, like TOTP codes)