Hacker News Reader

That seems literally borderline impossible.

https://duckduckgo.com/?q=LPE+security&ia=web

wow

It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).

staticassertionon The woes of sanitizing SVGs

It's multi-faceted. Docs is part of it, but also, no one cares about security and they won't do literally anything to improve security if there's a papercut.

Right now if I want to render untrusted content and if I use React I have to escape from using React to leverage this, using https://react.dev/reference/react-dom/server/renderToString

And using null origins has tons of UX problems - virtual / sandbox origins would solve this. https://gist.github.com/ddworken/309363b5d140bcc5ff6b39fa4a8...

There's just a lot more work to do before I expect to see this. It would solve so many problems though. I personally put d3, markdown rendering, etc, all into iframe sandboxes, which means the entire library could be malicious and it won't matter. But it requires way more effort than I'd like.

staticassertionon The woes of sanitizing SVGs

iframe sandboxing is wildly underleveraged. I think it's because it doesn't work well with "modern" app development - you need the ability to slice bits and pieces out yourself.

I've been just using plain typescript/html and it's so easy to say "yeah all of that rendered content goes into an iframe", I've got all of d3 entirely sandboxed away with a strict CSP and no origin.

I do hope that iframe sandboxing grows some new primitives. It's still quite hacky - null origins suck and I want a virtual/sandbox origin primitive as well as better messaging primitives.

staticassertionon GTFOBins

Typically you do things like this to either work in restricted envs (distroless) or to evade detection logic. It's not about bypassing a boundary, it's about getting things done in the env you have available.

staticassertionon Show HN: AI memory with biological decay (52% recall)

I've had to remove any of the "knowledge" about me from any agent I use. "As a security engineer, blah blah blah" or "as a rust developer blah blah blah" even though my questions has nothing to do with those topics and they're a huge distraction.

staticassertionon Amateur armed with ChatGPT solves an Erdős problem

In my experience, you can tell them "Don't stop working on this until complete" and they'll go for an hour or more.

staticassertionon GPT‑5.5 Bio Bug Bounty

No it isn't. Confidentiality terms are the norm.

staticassertionon GPT‑5.5 Bio Bug Bounty

That's pretty much how every bounty works... obviously it's going to be at their discretion for an incomplete attempt.

staticassertionon Tell HN: Claude 4.7 is ignoring stop hooks

This assumes that the tokens it outputs are a good description of the tool's behavior. That's not necessarily true though. For example, the LLM may be trained such that a lot of its input data is "LLMs often hallucinate", so the LLM may be biased to say "I hallucinated that" even if there's some more structural issue.

I think there's something here to consider, but it's sort of like assuming that the LLM has reasons for doing things when it only has weights for which tokens are produced - thats the sum of its reasoning.

Maybe it's the case that LLM tokens to correlate to truth values or that this approach actually provides value but there's probably good reason to be skeptical, given that we'd need to posit some sort of causative function of "token outputs" to reasoning about prior behaviors.

staticassertionon I am building a cloud

I don't think there's a right answer, you need to sit down and try to think about these problems upfront. What will scaling look like? What decisions will you regret? Make the guesses you can, but don't ignore scale or performance.

staticassertionon I am building a cloud

Nix wraps your process in namespaces and seccomp?

staticassertionon I am building a cloud

There's one extra process that takes up a tiny bit of CPU and memory. For that, you get an immutable host, simple configuration, a minimal SBOM, a distributable set of your dependencies, x-platform for dev, etc.

staticassertionon I am building a cloud

This is why there's an endless cycle of shitty SaaS with slow APIs and high downtime. People keep thinking that scale is something you can just add later.

staticassertionon GitHub CLI now collects pseudoanonymous telemetry

I'm not taking a side on whether a product should add telemetry. I'm rejecting the absurd notion that these suggestions are at all giving the same information.

staticassertionon GitHub CLI now collects pseudoanonymous telemetry

Okay?

staticassertionon The zero-days are numbered

> On hardened targets and Firecracker specifically, here's a recent vulnerability found by "Anthropic": https://aws.amazon.com/security/security-bulletins/2026-015-...

Yep. It's notable that they failed to exploit it.

> but there are plenty of projects that managed to fuzz/test/audit their way to making it much harder to find serious vulnerabilities

Agreed! But I think those projects have certain things in common, like being tightly scoped, slowly developed, and built with safety in mind from day 1.

I don't think that any of the projects that have managed to meaningfully improve safety through fuzzing have the same qualities as projects like Firefox, Linux, etc.

staticassertionon GitHub CLI now collects pseudoanonymous telemetry

You can set up a user forum if you'd like. If you think it will get you the same information that analytics will, you're obviously wrong.

staticassertionon GitHub CLI now collects pseudoanonymous telemetry

Not really. (a) People hate responding to surveys and hate emails, you're more likely to lose users than to get data (b) there's no way you're surveying people's in a way that gets you information like "time spent on a page" or "time between commits" or whatever.

This is just nonsense tbh. Surveys and customer outreach solve completely different problems from analytics.

staticassertionon GitHub CLI now collects pseudoanonymous telemetry

It's sort of hilarious to compare "talking to people" with analytics. I'm not defending Github here, but you can't possibly think that "talking to 1M customers" is viable.

staticassertionon Even 'uncensored' models can't say what they want

I'm not sure I understand your question but I'll try to answer as best I can - also keep in mind that this is simply one view. The structure of the brain encodes information based on experience in the same way that the force of gravity encodes information on two rocks that collide, or other physical forces encode information into chemical structures, etc.

In the case of the brain the encoding is such that various functions "fall out of" it, like being able to relate experiences, etc.

There's no magic proposed here, this is a physicalist functionalist view.

Nothing about this prevents a computer from being sentient. As I said, none of this even matters. The key premise is that LLMs are trained on language and not experiences. Unless you believe that a description of an experience is identical to the phenomenal experience, then we agree on the key premise. Do you think that they are identical?

staticassertionon The zero-days are numbered

So, my perspective on this is that the blog post doesn't motivate me very much.

First of all, the constant framing around Mythos as being capable of tackling "hardened" targets is invalid to me. Or it heavily depends on what "hardened" means. Firefox is an old codebase that has rapidly adopted new features over decades, much of its security has followed after implementation (JIT -> JIT hardening, single process -> multiprocess, etc), it's written in C++, it's extremely oriented towards performance and benchmarking, it has massive attack surface, etc. They have an incredible team working on it - genuinely best in class people are working to make Firefox safer. But does that mean Firefox is a hard target? That's not really my view of it, it's just more expensive than, say, phishing. I would maybe contrast this against Firecracker, which I think is a hard target despite having a tiny fraction of the investment of Firefox.

Similarly, Linux is a codebase with plenty of security investment - lots of research goes into Linux security. It is also an extraordinarily soft target in my opinion. Firefox is far better than Linux, I think, but the point is that Mythos has picked a lot of very specific targets here, called them "hardened", and I think it's misleading from Anthropic's marketing - they frame things like "heap spray" as advanced techniques and that's just nonsense.

Second, this article seems to be trying to convey a few things and then it has a really intense conclusion. I want to separate these out.

The article wants to convey that one of the advantages that attackers have is that the attacker's human-based attack exploration has been more effective than the difficult to scale automation-based attack exploration employed by defenders. The argument is that new AI capabilities change this because automation-based attack exploration via AI will close that gap.

One conclusion is then that because this gap will close that defenders can "win", which presumably means that attacks become too expensive (and therefor attackers move to other paths).

The final conclusion is seemingly that Firefox will have 0 exploitable vulnerabilities.

I want to separate that final conclusion out and focus on the first part.

1. The argument seems to rely on the advantage attackers have being singular. Attackers have a lot of advantages, so I'm not sure that removing this one will be sufficient.

2. It seems incorrect to me that AI will be so radically effective at finding vulnerabilities that attackers won't be able to find enough to build a chain. In fact, I think this is almost certainly false for a codebase like Firefox. It would be one thing if Firefox froze it's codebase today and spend years on hardening what's there, maybe I'd buy that... but no, I don't buy it at all for Firefox as it exists in reality.

3. This all relies on Firefox reducing the bug density such that viable chains can not be built. There is, I think, some threshold in which a codebase's bug density is so low that full attack chains are not viable. I do not think Firefox will ever reach that low of a threshold. The claim here seems to be that bugs can be found so quickly that the threshold can be met, or it rejects my threshold idea entirely.

I don't think any of this makes sense to me, personally. I don't think we've ever seen a moving codebase made significantly safer via any "bug squashing" technique. The value of squashing bugs is to track where bugs crop up so that you are informed about what mitigations should be built; you see a lot of vulnerabilities that leverage JIT RWX? Time to harden how JIT pages are emitted. Any bug isn't the interesting part, it's the mitigations and layered defenses that help. Fixing 100 XSS vulns on a website will never be as good as deploying a CSP, or updating your CSP, etc. This has always been the case, I don't think AI is so radically different that it will change this.

So anyway, I sort of don't buy anything the blog post says so far. And then it ends on this note:

> The defects are finite, and we are entering a world where we can finally find them all.

As far as I'm concerned, the defects in Firefox should be considered ~roughly infinite. But even if we say "no, there's some finite number of them", the idea that we'll drive to zero is just... not something I'm going to take seriously.

Earlier in the article "Nevertheless, we’ve all long quietly acknowledged that bringing exploits to zero was an unrealistic goal." is stated so it does seem to me that whoever wrote this actually believes that a zero vulnerability firefox is achievable. I think that it's not even achievable to reach a low enough threshold to break entire chains of exploits, so obviously I think it's not correct to say zero is achievable.

I think I can probably justify this to some degree.

1. We've never seen any bug squashing technology, including insanely highly leveraged ones like fuzzing, meaningfully reduce exploitability in similar projects. I doubt anyone thinks that 0 days are rare ITW because of fuzzing when it's very obviously because of sandboxing and mitigations. Is that contentious? Feel free to push back.

2. Rice's Theorem makes it seem highly implausible that we can reach a true "zero point" computationally through formal means, which to me implies that AI would have to be so effective at exploring insanely massive state spaces for a moving target for so many different properties, that it just doesn't sound realistic to me.

I am extremely skeptical of a lot of the statements made in this post. I do not think Mythos will help defenders by squashing bugs at all in a codebase like Firefox, I do not think Firefox is safer just because they patched 500 vulnerabilities, I do not think Firefox will meaningfully reduce vulnerability counts long term with Mythos, and I do not think that this should change their strategy of using fundamentally safer technologies / implementing mitigation techniques.

I will weakly predict that AI usage for bug squashing will look quite a lot like fuzzing. A win in the short term, just another automated tool in the long term, and the highest impact will be watching it for trends. I think AI will likely fare worse than fuzzing though.

staticassertionon Garbage collection without unsafe code

> so the domain in which you can beat their performance

Not in my experience.

staticassertionon Kernel code removals driven by LLM-created security reports

They can't maintain the code so they are no longer going to maintain the code.

staticassertionon Even 'uncensored' models can't say what they want

There are things that happen in the world that are external to us. We observe those things, and that observation is what I'm calling an experience. We can say things about the experience, but those words are not the experience.

As to what the experience maps to, I think the simplest answer is that our phenomenal experiences are encoded as structures in our brain, but that's not necessary to understanding the difference between words that describe experiences and experiences themselves.

staticassertionon Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys

I really appreciate the links, this'll give me a lot to read about.

staticassertionon Even 'uncensored' models can't say what they want

Sentences only have semantic meaning because you have experiences that they map to. The LLM isn't training on the experiences, just the characters. At least, that seems about right to me.

staticassertionon Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys

Is there any reason to believe that Grover's is as good as it gets? I'm on board here, and I think the article caveats that it's a matter of cost, priority, and assumptions. Cool, cool, I'm already using xaes-256-gcm. But I'm just curious if quantum could have new applications for algorithmic analysis, or take advantage of other weaknesses?

staticassertionon Vercel April 2026 security incident

It's very typical to have a retainer / insurance to bring in "emergency" incident responders beyond your existing team. Not saying that's the case here but it wouldn't be surprising.