david_shaw

I suspect the opposite: a billionaire's escape from a potentially turbulent society.

It seems weird to me that a (relatively) straightforward workflow like that would elude crypto hobbyists for the last 21 years (since 2005 according to the article).

The alternative explanation is that alignment is really so bad that they can't prevent it.

Either way, all of the major AI players should be embarrassed and held accountable. If humans did this kind of thing and got caught, they'd go to jail.

Unfortunately, Trump is passionately opposed to any AI regulation and is actively calling AI risks a "dumocrat hoax."

So it's unlikely that we'll see any real regulation on the US side any time soon. I'm not banking on China to slow down their AI industry, either.

This seems like a great idea, but absolutely not one that will happen in practice. At least not yet.

As you can see in their marketing page, Muse is a personal assistant that reaches out and/or ingests data through apps, the web, your email/messages, etc.

If someone sends you a malicious email or if Muse finds a malicious website by accident, you wouldn't want it to send them all of your photos or to purchase things you don't want (or maybe that aren't even real).

The payment related examples on the page are of particular concern, but I imagine it kicks back to a human to actually pay for things. But who knows?

I agree. The time to launch something like this would have been during the OpenClaw hype cycle (although, obviously, Muse is much more limited in the types of tasks it can accomplish).

I thought about installing it, but I realized I couldn't think of any real uses for it in my personal life.

According to the Chrome release page (https://chromereleases.googleblog.com/2026/09/stable-channel...), Google paid a researcher $1000 for ethically reporting this.

The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?

Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?

It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.

Sad to see this going away, but I assume this is so Mullvad can focus on their primary services.

I think young people -- especially teenagers -- already talk enough about "brainrot" to know that scrolling for hours is not good for them.

Here's the link to the actual study, for those interested: https://jamanetwork.com/journals/jama-health-forum/fullartic...

I'm no designer, but I can't understand why someone would make a graphical choice like this. It absolutely detracts from the content, and in my case, will prevent me from reading it.

AI agents are not magic. Mythos/Glasswing does not magically create vulnerabilities in software projects. Advanced, cyber-capable models do not magically hack out of VMs or contained environments. They do not have a "hacking" stat that, if high enough, means that they can breach anything. They aren't Kevin Mitnick whistling nuclear launch codes into the prison payphone. This isn't a movie.

What these cyber-capable frontier models can do is find security problems and exploit them. The statement should not be that VMs won't contain cyber-capable agents, but rather that we need to focus on finding and fixing vulnerabilities and misconfigurations in these environments.

Even the article itself concludes with suggesting something like Firecracker, which was designed with security in mind.

Like most other security-related problems introduced by advanced cyber-capable AI, it's possible that these issues will get worse until they get better. But if frontier models are run against state-of-the-art VMs, and OpenAI or Anthropic or whoever works with the virtualization projects to address the issues, eventually it will run out of things to exploit.

The concept of virtualization is not inherently insecure. We just have a long way to go.

What I'm seeing now in industry -- and I think this autofix issue is a precise example of it -- is a natural evolution of the "LGTM!" review that's so prevalent in software development and similar disciplines.

For years, the dramatic majority of "code review" was a quick glance followed by "Looks good to me." Sure, critical workflows have more scrutiny. Sure, not everyone fell victim to this trap. Sure, there are many exceptions. But it's a meme for a reason: most people weren't really reviewing code assigned to them. They were effectively rubber-stamping most things.

So now, in the age of AI, those same people are (sometimes still) expected to be responsible for what their automated developer friend Claude is doing. It's absolutely unreasonable to think that most people are giving the PR more than a glance, and in many organizations they're explicitly trying to remove humans from the loop.

One day, AI development and code review will be so good that mistakes like this will be extraordinarily rare. For the near-future, though, I anticipate we'll see more of this before we see less.

It's not that I think this is fiction; I'm confident these events actually happened. But I think they were effectively allowed to happen because Anthropic and OpenAI are constantly chasing each other for the narrative of "hugely advanced, maybe almost sentient AI lives here."

It reads more like a press release than a security update, and I think that's because it is. I hope this type of marketing backfires and the companies face actual scrutiny and consequences for operating this way.

OpenAI has strongly fallen behind after the incredible lore surrounding Mythos/Glasswing security capabilities, even though the frontier models should be relatively similar.

I think making sure eyes on this is absolutely a marketing move, regardless of the facts of the case. It feels a little silly.

> A requirement for staying sane while working in public as an open source maintainer is realizing that every issue, PR, and piece of feedback is a present, not an obligation. You can accept it, ignore it, and use it partially or not at all.

> Except…

> For years, as lead of the Go Security team at the time, I’ve told new team members that it doesn’t apply to vulnerability reports. No, vulnerability reports are special. Security researchers are doing us a favor by reporting things confidentially instead of doing full disclosure, so we owe them something, which is not true of regular issues opened on the issue tracker.

[...]

> It’s 2026 and none of the premises are true anymore.

I respectfully disagree.

The premise is absolutely still true: if someone discovers a critical, exploitable vulnerability in your software, the impact and tradeoffs are exactly the same as they were before LLMs started finding bugs. There are just more of them now, so they're easier to come by.

But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report. This is just chugging through the backlog.

All of that said, I don't think finding vulnerabilities has really been the difficult security problem for most companies (or open source projects). The difficult problem is dedicating resources to fixing those vulnerabilities instead of building software, products, and/or infrastructure that people want. That problem is absolutely still here today, but I'm optimistic that agentic security developers will be able to take the burden off of development teams in the near future.

For tokens, of course.

This is a somewhat ironic take from someone who very publicly feuded with the US government about whether their AI could be used for waging war.

Do you mean policy-wise (like Dario is talking about), or more broadly?

I wonder about broad preparedness, but unfortunately there's not a lot that we "normal" people can do to prepare. Hoard savings and food? Learn physical trades?

I understand why Dario thinks this is crucial, but it's a very dystopian view of the medium-term future.

I'm not an optimist to the point that I believe that AI will lead to global Star Trek-style utopia (although it theoretically could), but ongoing disparity between "allied" and "enemy" powers relating to hardware technology and software models is both not really possible to enforce in the long term, and a pretty dismal state of global affairs even if successful.

I'd be interested in an expert geopolitical opinion on what the long tail of this would really look like in any sort of reasonable reality.

The real problem is balancing the need to fix vulnerabilities with the mandate of shipping new products and features. At every organization I've worked for or with, this has been the natural friction point. That's good: Product should make customers happy, and Security should keep the customers and their data safe.

Ultimately, the whole business should share these goals: everyone should strive for a resilient, useful product shipped quickly that delights customers. Easier said than done, but the friction should be tactical ("how do we spend engineering resources?") rather than strategic ("are security fixes important? do we care?").

Which is why I'm much more interested in automated (or semi-automated) PRs to actually fix discovered vulnerabilities rather than just identify them. But, as this project implies, it's not always that simple. It's easy to fix vulnerabilities if you don't care about breaking other functionality.

In my opinion, it's currently still necessary to have a human developer in the loop to make sure functionality in product is maintained, and potentially security in the loop to make sure the vulnerability is actually fixed and not just obfuscated.

Once this technology is sufficiently advanced -- and I think we're getting close -- my hope is that developer and security time will be spent thinking about resilient software design and architecture, not code-level vulnerabilities.

We'll see where it goes.

> Apparel (t-shirts, so far): https://openbsdstore.com/

Interesting.

In the image you linked (PinkPuffy.png), the cat's hat says "security." In the OpenBSD store, the cat's hat reads "POLICE" on several of the shirts.

Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.

It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic development.

I'm not just talking about Mythos/Glasswing surfacing vulnerabilities in pretty much everything it touches; I think the way we're developing software, pulling in dependencies, and potentially losing human thought modeling of complex systems is going to lead to a lot of hacked together software and infrastructure that humans won't fully understand.

I hope in a few years we don't look back at today and wonder how we could have been so naive -- how we failed to actually plan for the long-tail of AI development in a way that doesn't solve problems by attempting to just use AI to rebuild complex systems.

But the article was funny.

Back in 2010, as a security engineer, I also looked at OpenEMR. It was an absolute disaster, and was (and is) somewhat well-known as such. I found and published vulnerabilities very similar to these sixteen years ago. This is not exactly the Fort Knox of software.

It makes sense for AISLE to demonstrate that they're able to find vulnerabilities here, but I'd love to see a side-by-side comparison of modern SAST and DAST reviews. I bet we'd find similar vulnerabilities.

A very simple version of this would be if you set a user's default shell to "rbash" but the user can just run "bash" to get a real shell.

I found an article on The Cipher Brief describing them: https://www.thecipherbrief.com/defense-neoprime-innovation

Specifically, the idea here is that companies like Anduril, Palantir, and SpaceX are rapidly delivering cutting-edge technology (including software) as opposed to the traditional defense contractor process of long, drawn out, super expensive projects mostly focused on hardware (such as building a new type of jet).

It makes sense: this is basically what happened in civilian tech, too. Delivering high-tech solutions quickly -- dare I say with agility -- is usually the superior approach.

You're right. This is configurable via settings, but is not the default state.

That said: if I can get friends and family to use Signal instead of iMessage, that gives me the opportunity to disable those notifications and experience more security benefits.

But I agree with your point: most people think that Signal is bulletproof out of the box, and it's clearly not.