Project Glasswing: An Initial Update • Hacker News Board

Re: Project Glasswing: An Initial Update

#291

Post by jtbayly » Sat, May 23, 2026, 1:19 PM UTC

Forgeties79 wrote: post #204

ygjb wrote: post #101

Earlier quoted context omitted.

> the developers learn from mistakes and avoid them in the future No. Humans learn from mistakes and try to avoid them in the future, but there is a whole pile of other stuff in the bag of neurons between our ears that prevent us from avoiding repetition of errors. I have seen extremely talented engineers write trivial to avoid memory corruption bugs because they were thinking about the problem they were trying to so…

The problem is you as a person are not incentivized to introduce bugs in your code. If I am a company that provide provides an LLM/agent, and I know that the more bugs you have the more money I’m going to make, then I am not exactly incentivized to make my LLM/Agent better at preventing bugs. I don’t even have to explicitly make it introduce them. The incentive structure is simply out of whack.

That’s like saying screw manufacturers are incentivized to give you crappy screws because it means you will buy more.

No. You will switch to a competitor that does a better job or charges less or both.

This is why monopolies are such a big problem. Because under a monopoly you are right.

Re: Project Glasswing: An Initial Update

#292

Post by Forgeties79 » Sat, May 23, 2026, 1:22 PM UTC

jtbayly wrote: post #291

Forgeties79 wrote: post #204

Earlier quoted context omitted.

The problem is you as a person are not incentivized to introduce bugs in your code. If I am a company that provide provides an LLM/agent, and I know that the more bugs you have the more money I’m going to make, then I am not exactly incentivized to make my LLM/Agent better at preventing bugs. I don’t even have to explicitly make it introduce them. The incentive structure is simply out of whack.

That’s like saying screw manufacturers are incentivized to give you crappy screws because it means you will buy more. No. You will switch to a competitor that does a better job or charges less or both. This is why monopolies are such a big problem. Because under a monopoly you are right.

What you’re describing is a one-to-one quality/failure problem by choosing to ruin the basic, core functionality of an item (while also endangering people at that). Or if you start with a bad screw, that just means you’re talking about people’s tolerance for bad products. What I’m talking about is similar but a little more nuanced and has plausible deniability. The relationship I’m describing is more indirect and it doesn’t require explicit effort to cheapen a product, but rather simply not improving a specific element of the product.

Apple made a ton of money off of lightning port accessories, you see it referenced here all the time. Apple had no incentive to swap to USB-C though it would create a better product and be more uniform with the rest of the world, so they kept with it despite incredibly vocal calls to swap because there was a ton of money they were making in the accessories. And it didn’t stop until they were forced to stop by the EU.

When we are talking about products at scale, these kinds of incentive structures play out in very tangible ways. If I have an LLM product and I’m getting two pulls at the hose because you’re burning tokens making stuff and correcting it, I don’t need to do anything. People are willing to tolerate that system to a pretty high degree so long as they ultimately get what they wanted in the end - unfortunately that is a great space to make money in.

Re: Project Glasswing: An Initial Update

#293

Post by IndeanCondor » Sat, May 23, 2026, 1:32 PM UTC

moomin wrote: post #142

mukmuk wrote: post #122

I’m not sure how to reconcile anthropic’s update / some of the exuberant comments here with recent feedback like the following from curl maintainer Daniel Steinberg: “I see no evidence that this setup [Mythos] finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to…

You’re right, it’s a valid data point. But the U.K. government report is also a data point, and the Firefox report is a data point, and they suggest that it is, indeed, significantly better than current generation models. Maybe curl is significantly better hardened than most projects? In any event, it barely matters. As Anthropic acknowledges, next level models are comings, theirs is only one of them. Current generat…

The same UK security research body ran the same CTF against GPT5.5. GPT5.5 got the same result as Mythos.

Anthropic promised us that Mythos was such an existential threat that it would compromise "every OS and browser on devices across the planet". They've held conferences and meetings with banks and govts across the world, shouting how critical this issue is.

GPT5.5 has been out for a month. Every device on earth has not been breached yet. It's very fair to criticize Anthropic's maximalist posturing when it's becoming exceedingly clear their models are fairly behind OpenAI's in capability.

In my opinion, the original commenter's statement stands, and the UK govt data point only helps support that due to the equal result between Mythos and GPT.

I'd advise reading into the specifics of what happened with Firefox; the TL;DR is a reduced safety version of its code was scanned by Opus 4.6 (yes Opus) and found a multitude of bugs and 4 high severity vulns that did not escape sandbox. The Mythos system card test describes running Mythos against the same issues Opus found to see if it could reliably replicate and chain together an attack.

Re: Project Glasswing: An Initial Update

#294

Post by [deleted] » Sat, May 23, 2026, 2:17 PM UTC

rco8786 wrote: post #275

winstonwinston wrote: post #54

Earlier quoted context omitted.

> I expect tools like this to be a regular part of the development lifecycle from here on. We code with AI, we review with AI, we search for vulns with AI. Even if it isn't perfect, it is easily worth the cost IMHO. So, how is that supposed to work? Claude Code generates security bugs, then Claude Security finds them, then Claude Code generate fix, spend tokens, profit?

Software engineers generate security bugs, Software engineers find them, then Software engineers generate fix, collect salary, profit?

[deleted]

Re: Project Glasswing: An Initial Update

#295

Post by firesteelrain » Sat, May 23, 2026, 2:28 PM UTC

dyauspitr wrote: post #248

firesteelrain wrote: post #244

How is using Mythos different than existing static analysis, dynamic analysis, fuzzing, or DAST tooling?

Stop with this nonsense. At the most basic level, it’s different because you just point it at a thing and it does everything else.

How is it nonsense? We already have these tools for years and magically Mythos comes around and makes old new again.

Re: Project Glasswing: An Initial Update

#296

Post by akoboldfrying » Sat, May 23, 2026, 2:41 PM UTC

dminik wrote: post #253

akoboldfrying wrote: post #133

Earlier quoted context omitted.

Absolutely. And not even making the connection. On a broader scale, the sheer face-eating-leopards-ness of programmers finally automating away our own jobs and then realising how much this sucks, after automating away so many other kinds of jobs, can feel darkly amusing to me too.

I keep reading this sort of comment quite a lot, but programming isn't always about automating jobs away. In my career I have not eliminated a single job. I don't consider that a failure on my part.

I didn't mean to imply that automation through programming is always bad. Like with any technology that increases productivity, there are many obvious benefits. We have all benefited enormously on the consumer side of the economy, for example. But I think it's recently become a lot clearer to many in the tech industry that automation can have downsides too, and those downsides are not evenly distributed. This truth was there all along, but because we were shielded from it for so long, we were able to look away. Not anymore.

Any computational task done by a computer could in principle be done by a person, albeit billions of times slower and with a larger error rate. If computer programs could not automate certain practical tasks -- that is to say, do them much more reliably and efficiently than people do them -- they would be an academic curiosity studied by a handful of professors instead of a central part of modern infrastructure.

So I'm sceptical of your claim not to have eliminated a single job. You might not have removed an existing job, but couldn't people be paid to do the work your code does?

Re: Project Glasswing: An Initial Update

#297

Post by jtbayly » Sat, May 23, 2026, 3:00 PM UTC

Forgeties79 wrote: post #292

jtbayly wrote: post #291

Earlier quoted context omitted.

That’s like saying screw manufacturers are incentivized to give you crappy screws because it means you will buy more. No. You will switch to a competitor that does a better job or charges less or both. This is why monopolies are such a big problem. Because under a monopoly you are right.

What you’re describing is a one-to-one quality/failure problem by choosing to ruin the basic, core functionality of an item (while also endangering people at that). Or if you start with a bad screw, that just means you’re talking about people’s tolerance for bad products. What I’m talking about is similar but a little more nuanced and has plausible deniability. The relationship I’m describing is more indirect and it…

This is the reason that people felt like Apple should be treated as a monopoly, though. The switching cost is high, and the benefits you lose are large. So people put up with it, in spite of being upset.

The switching cost is not high for LLMs as far as I can tell.

Re: Project Glasswing: An Initial Update

#298

Post by perlgeek » Sat, May 23, 2026, 3:35 PM UTC

> Software developers should shorten their patch cycles and make security fixes available as quickly as possible. [...]

> Network defenders should shorten their patch testing and deployment timelines.

Shortening patch cycles will only help so much. It's funny that whenever an NPM supply chain attack is published, people recommend a cooldown before installing new versions, and then when a vulnerability is discovered, everybody jumps to patch. Clearly these two strategies collide at some point.

> The critical controls laid out by organizations like the National Institute of Standards and Technology and the UK’s National Cyber Security Centre are now all the more important, since they improve security without depending on any single patch landing in time. These include steps like hardening networks’ default configurations, enforcing multi-factor authentication, and keeping comprehensive logs for detection and response.

Most of these proposed controls are not new at all, but they are often costly to implemented and harm velocity in other ways, which is why they aren't widely in place.

For example, a super effective control is filtering outgoing network traffic. Many exploits rely on loading second and maybe third stages from the Internet, and if you block outgoing requests by default, it won't work.

But, blocking outgoing requests by default is super hard, and you risk blocking security updates etc. It can kinda work for a deployed application, but for an employee workstation? Basically impossible.

I wonder if we're approaching an era where we have to go back to saying "you cannot do this, because security" much more often than we'd like.

Re: Project Glasswing: An Initial Update

#299

Post by perlgeek » Sat, May 23, 2026, 3:36 PM UTC

mdeeks wrote: post #34

You can get a taste of this today yourself with Codex Security. I turned it on just as an experiment and in less than a week it has now become essential to all of us. I was shocked how accurate it is, how many security issues it found in existing code, how it continually finds them as we commit, and how NO ONE is immune from making these mistakes. I'd say it is about 90% accurate for us. Often even the "Low" findings…

What kind of application are you developing?

Re: Project Glasswing: An Initial Update

#300

Post by Forgeties79 » Sat, May 23, 2026, 3:41 PM UTC

jtbayly wrote: post #297

Forgeties79 wrote: post #292

Earlier quoted context omitted.

What you’re describing is a one-to-one quality/failure problem by choosing to ruin the basic, core functionality of an item (while also endangering people at that). Or if you start with a bad screw, that just means you’re talking about people’s tolerance for bad products. What I’m talking about is similar but a little more nuanced and has plausible deniability. The relationship I’m describing is more indirect and it…

This is the reason that people felt like Apple should be treated as a monopoly, though. The switching cost is high, and the benefits you lose are large. So people put up with it, in spite of being upset. The switching cost is not high for LLMs as far as I can tell.

For an individual, no it is not. For a massive corporation that has a huge contract and has their entire workforce working on it? That’s not such an easy switch, especially depending on the tooling involved beyond just the core LLM.