bjackman

Hosting DeepSeek Pro yourself is gonna be wildly expensive though?

You have a wide choice of providers available, so if you can find one you trust you can get inference without data harvesting and it's still very cheap. But dedicated HW is insanely inefficient.

Opus estimates you can do it for $13k/month if you get committed pricing on the HW.

Re being away from the HW: with Tailscale and llama-server it's now super easy to just run an inference server at home and use it from wherever you are.

It's a good technical artifact yeah but it would need to be forked and degoogled, today it is only really useful with Google services as a backend.

Also it's coupled to the device ecosystem which is organised by Google. This coupling with the HW is one of its major technical strengths though, including for the security things I'm yapping about.

So yeah I think the two options for a EuroOS are:

- Fork and degoogle ChromiumOS/AOSP

- Invest in a Silverblue/bootc/Flatpak style system and just keep filling the gaps there

Hard to say which would be the better option. Both require at least tens of millions in investment over 5+ years.

SELinux is a framework not a solution. Main places that gap is closed are Android and ChromeOS, not normal distros.

MacOS has:

- Serious integrity story

- Actual kernel hardening

- No reams and reams of garbage in their kernel (wouldn't have equivalents to the recent AF_ALG vulns coz they don't have dumb stuff like AF_ALG).

- Filesystem security boundaries retrofitted onto the Unix model (interesting user data, browser creds etc are gated by special permissions that are tied to the application build, backed by the integrity story - a `curl | bash` command cannot dump your ~/Documents)

When people escalate privileges on MacOS it's news, when they do it on Linux it's Tuesday (you might think the recent spate of privesc vulns on Linux was unusual but that is totally normal).

I say this as someone who works on Linux security every day (I am a kernel developer) and uses Linux on every computer I have, both at work and at home, BTW. I am not a Linux hater or Apple fanboy by any means.

These are all solvable problems at EU scale too. Just, I think they should solve other problems first in the priority list of delivering sovereign IT.

I worked at Google on post-Aurora endpoints security. Windows laptops are alive and well at Google. Linux laptops have had one foot in the grave for a while now (it's a bummer). Google historically made gLinux work only with enormous investments in customised distros and D&R.

> But maybe you could elaborate a bit more concretely about what kind of intra-host security boundaries are missing

- no boundaries between applications, everything runs as $USER which can read your browser creds

- no boundary between user and root, everything can trivially escalate privs (maybe we will fix this post Glasswing, let's see)

- no boundary between boots, root can trivially persist a compromise (probably non-root too)

The tech exists to solve all these problems on Linux, but there isn't a distro that strings it all together. (Unless you count ChromeOS/Android which are not really OSS).

> Genuinely interested: does it bring something to say "everything is crap anyway, but given that we must choose between one of them, we may as well choose the least bad" instead of "the best solution we currently have is X"

Well I dunno if that's true, that's why I didn't say it. Linux _may_ be the best solution overall I am not sure. It is definitely not the best solution from a security perspective.

> Secondly, are you sure that it is impossible to secure a system for a whole department? I have seen relatively big companies having an IT team managing their own Linux flavour. That is, whitelisting the packages that can be installed by the users.

Just whitelisting packages isn't enough. ChromeOS effectively does this and their whitelist is extremely small, yet they are still only ok with that because they backed it up with the rest of the pieces needed to make a secure Linux desktop, including a fully vertically integrated stack.

Sovereignty yes it's obviously better.

I am just talking about the pure tech fact that GNU/Linux desktops do not have any meaningful intra-host security boundaries.

Is this a worthwhile tradeoff against being tied to US tech? Yeah maybe, like I said there are no good options here, and Linux might be the least bad.

It's not alien tech but it's a basic fact that only the US has it right now.

Yes we could build a serious distro with a massive investment to get Flatpak, systemd, bootc, up to scratch, set up OSS endpoint management software, set up a safe package supply chain, etc. And yes I would love to see it. But I think in the short term the money would be better spent replacing crap like Outlook and OneDrive than Windows. Note this doesn't require building much software it's about figuring out how to run infrastructure in a way that's friendly to the bizarre world of public sector organisations.

Maybe Dunning-Kruger but the latter just seem like much easier problems to solve.

Also totally pointless until we have an OSS web browser that the whole sector can adopt (maybe we already do, but any funding gaps for Firefox should still be addressed before we build our own EuroOS). No point in having a wonderful sovereign OS that just serves as a bootloader for Chrome.

I do not think I want my public sector running GNU/Linux desktops. There is no distro that meets the security requirements.

I don't know if Windows is better, I have heard rumours that it's pretty bad.

I know MacOS is MUCH better from a security PoV but I definitely don't want my public sector shelling out to Apple and I don't think it meets the boring IT management requirements anyway (I think big tech has a lot of crazy workarounds to make their MacBook fleets workable).

So yeah overall no good options here. I would love to see the EU fund development of a better distro for this usecase, but doubt it's the highest ROI thing you can do in this space.

My "I saw this very early" claim deserves some skepticism, but...

Don't y'all remember GPT2? When they published that AI-generated unicorns-in-the-Andes article, my jaw was on the floor. I remember very clearly thinking "oh, history is now divided into the time before this moment and the time after it".

There's been a long series of "oh holy shit this is USEFUL NOW" moments in the last 2 years but none of them compare to that first moment. The day before, I didn't know if real AI was possible. Then one day it was suddenly clear that it was. And if you'd been thinking about AI at all it was obvious that if the technology was at all possible, it was gonna be a really fucking big deal sooner or later.

I think Conway's law is more interesting. It seems natural that networks of human relationships would mirror each other when the same groups of humans translate themselves into a new context.

Whereas the structure of technological products is a "different thing" than the human relationships that created it, it's less obvious that it would translate across that boundary.

As well as rational vs irrational they are also just different types of spending.

Hiring someone vs paying a vendor for a service:

- different level of commitment

- might tie your org to a physical location

- different legal risks

- shows investors a different picture (probably this would even influence a bank loan)

- manager has to fight a different bureaucracy

Not to mention that comparing the cost of a hire by looking at their salary is pretty dumb. ISTR hearing at Google that the overall estimated cost of employing a SWE is like 4X their compensation? Can't remember the exact figures though.

Ultimately I think the only way you can trust benchmarks is if you build them yourself and keep them secret from the AI labs.

There are different levels of "cheating" on benchmarks. The worst would be just literally putting them in the loss function during RL, I assume the major labs are not cheating at that level. And I am sure they are making a genuine effort to keep the benchmark content out of the training data.

But, ultimately it seems implausible that they completely abstain from benchmarking their model until they are about to release it. Even if they did do that, the benchmark is still ultimately a part of the outermost feedback loop. So these models are all, to _some_ degree, benchmark-solving machines.

I think all we can really do is live with the model for a while and develop a subjective feeling about its quality. This shouldn't be surprising, nobody believes that coding interviews work, we all know that you just have to work with someone to figure out if they're a good programmer. As AIs become more human like it's natural they should get harder to evaluate.

This is a bit awkward, it puts us in quite a weak position as consumers.

Maybe to some extent you can get a meaningful signal from sentiments on HN etc, but:

- There must be some amount of manipulation going on of this

- Even if it was fully organic, it's highly likely that your experience will differ materially from the median online nerd, because AIs are bizarre things that respond in unpredictable ways to intangible things.

Yeah I actually advocate for dropping to assembly quite a lot in BPF:

- portability isn't a concern

- BPF ASM syntax is quite readable

- it can often let you write simpler code by directly doing what the verifier needs instead of dancing around trying to make Clang do it for you.

I think the most exciting alternative BPF language would be one where the compiler interacts with the verifier. E.g. if the program included a logical proof of correctness that the verifier could check more efficiently than its limited builtin analysis.

FWIW uBlock Origin for Firefox on Android works fine here.

I think his agenda here is to point out that your probability distribution for AI outcomes should be broad (what you said), but most importantly: this means you must take seriously the possibility that we are gonna get superintelligence quite soon.

Basically a lot of people say "but isn't it also pretty likely that we DON'T get superintelligence?" And, yes, it is. But superintelligence being even a remotely plausible outcome is a big fucking deal. Your investment choices in that context are not important.

People really struggle to think rationally in the face of this shape of uncertainty.

> similar to a macOS experience but built on a standard Linux foundation.

From a security perspective, this cannot exist. MacOS is fundamentally superior to classical GNU/Linux distros. Android/ChromeOS are the only Linux systems that make a serious attempt to close that gap.

I think the closest thing I can imagine is a system that goes all in on a Snap/Flatpak type platform (basically, like Fedora Silverblue, plus throw ~50 million dollars at fixing all the sandboxing, improving the SELinux policies or whatever, cranking up the system integrity story, getting some kernel hardening in place, stuff like that). With Google's funding I do think that's technically viable, I would love to see it. But, I dunno if it would count as "standard Linux foundation". And, kinda a weird thing to do for a company that's already spent billions over the last 20 years to build several existing Linux OSs.

(BTW, this is a totally security-brained take. I do actually run classical GNU/Linux on all my personal computers, the fact that it's a fundamentally insecure OS doesn't actually bother me that much. But I don't think Google can realistically ship a "product" like that. If it really took off and gained the kinda adoption they are presumably hoping for, it would honestly be quite irresponsible of them).

It's very common, I believe all the Big Tech firms have you write code.

I think the example from my story was the only one I've had where I had to _read_ code. (I have heard of people doing "code review interviews" though).

I've also had a job interviews with no code though. For startups or non-FAANG type companies.

I once had a job interview where they wanted to evaluate my C knowledge. They showed me a printout of some pointer arithmetic and said spot the bug. (It may actually have been the old puzzle where it turns out that /* is always a comment opener and never a division by the referent of a pointer).

I said "well first, this is a mess, I'm putting parentheses here, here, here and here". They said "well you've fixed the bug but can you tell us where it was?"

I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.

Interviewing such an insufferable smartarse was probably quite annoying but they did give me the job and I do stand by the underlying principle!

Yes that is what i mean, anyone can do it technically, but they are gonna have to build a slightly crappy OS in order to do it.

But still, better multiple slightly crappy OSs instead of just one (plus Apple).

There is a fundamental tension here though - suppose DMA or something requires that online providers recognise reCAPTCHAs from non-Google-attested OS builds. What OSs can they safely trust?

Only ones that are difficult for fraudsters to use to generate bogus traffic. Whether or not those builds come from Google, they are inherently gonna be pretty constrained OSs. It's not gonna let you spoof your location or simulate user input.

I do think it's a problem if only Google can provide these attestations but even if that organisation problem is solved there is still a fundamental technologic problem here now that humans can't be detected by their ability to solve puzzles any more.

Linux does actually have a proper embargo process. But, you're correct that in this case it wouldn't usually have been followed anyway. Bugs like this are fixed multiple times a week, anyone with basic kernel knowledge can see that they are potentially LPEs.

Usually, nobody even bothers to check. LPEs like this are too common to even categorise effectively.

Updating your kernel isn't good enough, it never was.

Native unsandboxed execution == root. Only thing that's new is some people started making websites for their LPEs.

https://github.com/google/security-research/tree/master/pocs...

Well, there's still value in users and namespaces! Just, it's not a strong security boundary.

Also even if it's not strong, it doesn't mean it's entirely worthless. You can't rely on it, but it's usually free and it still buys you time / increases attack cost.

Like, if you leave 100k cash in a car on the street in SF, that's dumb. If you really need to do that for some strange reason, you should hire a security guard to watch your car, because cars a not a good security boundary. BUT, that doesn't mean you would leave the car unlocked just coz someone's watching it!

Look at kCTF results.

Look at the CVE database. Most of those UAFs are LPE. Many of the OOBs and many of the race conditions too. These are fixed in Linus' master but you are running an old kernel.

Then look at the KASAN reports on the syzkaller dashboard. Many of them are LPE. Many of the WARNs and crashes are revealing and underlying bugs that is also an LPE. Most of these never get fixed.

Then try pointing your LLM at the codebase and saying "find an LPE". It will find as many as you want (you will exhaust your tokens long before it stops finding bugs). 99.99% of them will be bogus so you need a way to evaluate them at scale, currently this is the weakest approach but we'll get better at it.

I can't actually point you to a list of confirmed LPEs coz the only way they get confirmed is when someone exploits them, but there aren't enough exploit authors to do this for all of them. If inference gets really cheap and someone builds a really good agent harness we might start to see it get automated at some point.

Yes but what I'm saying is that copy.fail is a minor detail in this scenario.

If you are running Ninja Forums you need to run it in its own VM so that if it gets compromised _you don't care if it has uid=0_.

You need to do that regardless of copy.fail. Now that you've patched copy.fail, there are loads and loads of other vulns that can be used the same way.

Yeah you need native code execution, and if you have AF_ALG access there is clearly no sandboxing in place. At that point it's game over on Linux, there are too many bugs. Even if you fix all the known ones in the current kernel, by the time the version with those fixes is qualified and released (not to mention, the machine must reboot), new LPEs have been discovered.

It's not RCE it's an LPE in an obscure corner of the kernel attack surface that no sensible application depends on. They are absolutely a dime a dozen.

Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair, in a lot of cases it's gonna be hard to escalate privs without crashing the machine).

Ubuntu has userns restrictions now which takes away the main sources of LPEs (random qdiscs, nftables, all that garbage) but there are still huge numbers of these vulns. This is why platforms that do native untrusted code executions have extreme sandboxing. Note Android and ChromeOS aren't affected coz they already knew this code was broken and hide it from unpriv workloads.

You can't run untrusted code on Linux without either a very very carefully designed sandboxing layer (like Android/ChromeOS) or virtualization. copy.fail is just one among tens of thousands of reasons for this, and it's a pretty uninteresting one at that.

What is "special" depends on your usecase but for my job it's mostly about stuff that's exposed to KVM guests. Biggest source of concerning vulns for us is probably vhost. I expect there are also lots of undiscovered and scary vulns in places like virtiofs, vfio, DAX, and wherever we do device passthrough.

> I could find any places running containered services and exfiltrate secrets parallel services, no?

Yes. Regardless of copy.fail. Cloud providers don't do that without a VM layer. (If yours does, you need to switch).

If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead.

The copy.fail website is very silly, it is not a special bug. If anyone gets compromised by that vuln their node architecture was broken anyway, patching copy.fail doesn't help.

99% is usually the best you can do. So you can only layer multiple defences together, this makes sense as one layer to me.

I have an issue with security layers that are inherently nondeterministic. You can't really reason strongly about what this tool provides as part of a security model.

But also, it's in an area where real security seems extremely hard. I think at some point everyone will have a situation where they wanna give an agent some private information and access to the web. You just can't do that in a way that's deterministically safe. But if there are usecase where making it probabilistically safer is enough to tip the balance, well, fine.