My question is now: Which company is gonna buy the IRS now?

In the US?

Hahaha, that was a good one, buddy.

That's the real reason.

If you don't believe me, take a look at the leaked codebase from a couple weeks ago. It's the stuff of nightmares, because too many junior devs slopcoded in all places without any plan or understanding of software architecture patterns. They never actually take the time to refactor, there's dozens of outdated redundancies and orphaned modules all over the place.

Without good architecture patterns, there can be no good GUI nor good UX.

I laughed out loud when I read this paragraph. There are so many "consciousness" or "memory" or "learning" AI bullshit startups right now...all of them not understanding how positional encoding of LLMs work. It's getting so ridiculous that I don't even understand why they're in the (uncurated) news everywhere.

It's like everyone tries it out, and writes without any journalistic integrity because it's a sponsored article that costs 100$, and moves on. Spamming as a bought in service or something. It doesn't make sense to me, and I have no clue how broken the economics of this must be to get into the state of "AI news" we are in right now. Excuse my French, but something must be utterly broken.

The slow turtle wins the race against the overly eager rabbit... so I'm okay with that

That was the original stealth game in my opinion :D

... well, apart from XIII, NOLF, Commander Keen and Agent Sam, of course.

The 90s sure had some awesome games

It's actually more like 50 devs, each of them specialized in their own field, with 20+ years programming experience.

And even they make mistakes sometimes (see the recent TOCTOU exploit wave).

What vibecoders never get: it's about stability of software. Nobody will rely on your vibecoded project if even you yourself don't give a damn about any API stability or API contracts.

If you expect others to use vibecode assistants to use your software/library... then what was the reason in the first place to write it, if it's effectively not solving a problem? The whole points of dependencies and packages goes out of the window once the library maintainers start to use slopcoding practices.

Managing agents is a lot like managing children. They will outsmart you 99% of the time. If your agentic environment isn't built for good sandboxing, you won't succeed.

If you build an environment that can represent mutual cooperation (e.g. helping an agent by doing the tool calls yourself if it was stuck) then it's soooo much better than just trying to rephrase the ruleset of the engagement.

Don't optimize for retries. Optimize for sandboxing and strong agent to agent communication that you can also observe, modify, and summarize.

...because they never patch it, and are busy building robots instead.

Assuming reasonable implementation standards at this point is the irrational assumption, not the rational one.

Your mismatch is that you think in policies, not assessments here. Nothing in my normal go workflow will ask me if I want to run "curl download whatever from the internet" when I run go build.

Though I agree with the difference in workflow, there is not a single mechanism in go catching this. go.mod files can be just patched by the worm, and/or hidden behind a /v123 folder or whatever to play shenanigans on API differences.

Examples that come to mind: webview/webview, webkit, cilium/ebpf and most other CGo projects that I have seen.

NPM's achilles is the pre/postinstall step which can run arbitrary commands and shell scripts without the user having any way to intervene.

Dependencies must be run in isolated chroot sandboxes or better, inside containers. That would be the only way to mitigate this problem, as the filesystem of the operating system must be separated from the filesystem of the development workflow.

On top of that most host based firewalls are per-binary instead of per-cmdline. That leads to the warnings and rules relying on that e.g. "python" or "nodejs" getting network access allowlisted, instead of say "nodejs myworm.js". So firewalls in general are pretty useless against this type of malware.

How could anybody besides a Microsoft employee, given the appearance of this bypass technique?

> thats an LPE, not an encryption backdoor

No. RedSun and Bluehammer were LPEs

> the USB stick doesnt decrypt bitlocker, it just gives you root after bitlocker was AUTOMATICALLY decrypted

No, that's not what the bypass does. Maybe go try it out and verify it before you come to your quickly made conclusions?

It's not tied to "automatically decrypted" volumes, whatever that would imply for your setup requiring a pretty pointless TPM keystore for that.

If your case were true, it would also imply that any bitlocker cryptography never really worked because it was automatically decryptable without the need for a password/hash/whatever to get your keys from the keystore, which actually makes it so much worse. Even worse than the previously known coldboot attacks.

A USB stick containing a masterkey to decrypt a bitlocker volume is literally the definition of a backdoor.

Go on, try it out. It works.