mirashii

That would be why it chose a VM that is explicitly designed for sandboxing rather than native executable code or similar, the risk can be minimized by reducing the surface area available to that executable code to almost nothing.

It would take those devices having synchronized atomic clocks, which they do not.

> CPUC exists. CAISO exists. The consumer experience is still bad. What this means is that there is not enough generation

The existence of CPUC and CAISO says nothing of their efficacy. Jumping all the way past any question of their efficacy is egregious.

Importantly, in that rule:

> Complaints about paywalls are off topic, so please don't post them.

Not with those exact terms, but it is certainly being discussed. Wes McKinney said in a recent talk that with current coding agents there’s no longer an excuse for shipping suboptimal code that takes on tech debt. Writing tests has never been cheaper, writing custom fuzzers, linters, and other harnesses that serve as guardrails has never been cheaper. His take is that “we didn’t have enough engineering time to do it right” is no longer an excuse, and the only excuses left are that you don’t know any better or you have bad taste.

What language that is actually used 40 years after release isn't undergoing big, fundamental changes?

Java? Nope, you're getting a fundamental change in Valhalla C++? Nope, new language edition every few years with fundamental changes C? C23 has a number of fairly fundamental changes, expect more in the next language revision

I think your sense of causality is backwards here. These languages are getting fundamental changes because they're being widely used. That is what motivates and drives the change. Languages with no users don't need to change.

I'd have hoped in 2026 that anyone publishing this type of report would understand that DNSSEC isn't helping anything, and is generally considered to be actively harmful to enable. I'd suggest doing a bit more research and dropping the DNSSEC stuff, or reversing it entirely.

If you read the article and the linked documentation, you'll see that those things aren't in the list of what this change applies to.

https://support.apple.com/en-us/126655

Do you have any reference to the Rust community “not allowing” something? This seems more like a case of a relatively niche tool doing what it needed to do to work, but not (yet) some broader effort to upstream or integrate this into cargo or rustup. I couldn’t find any RFCs or anything, for instance.

How about the boy who called nonsense security vulnerabilities. This is the same author who posts with incredulity that the ability to change a config file with a shell command in it gives you the ability to run the shell command you posted and wants it treated as some big CVE. Absolutely inconceivable that you might already have your harness in a sandbox where this is okay, and inconceivable that anyone might have a threat model that says that someone who can edit configuration of a tool can make that tool do arbitrary things allowed by its config.

https://www.flyingpenguin.com/ox-security-report-anthropic-m...

I can buy the idea that if you can have the MDM infrastructure attest the code signing identity through the designated requirements, that you can probably come pretty close, but I'm still not quite sure you get there with root on macOS (and I suspect that this is part of why DCAppAttest hasn't made it to macOS yet).

Certainly, it still doesn't get you there with their current implementation, as the attempts at blocking the debugger like PT_DENY_ATTACH are runtime syscalls, so you've got a race window where you can attach still. Maybe it gets you there with hardened runtime? I'd have to think a bit harder on that.

> If you can prove a public key is generated by the SEP of a machine running with all Apple's security systems enabled, then you can trivially extend that to confidential computing because the macOS security architecture allows apps to block external inspection even by the root user.

It only effectively allows this for applications that are in the set of things covered by SIP, but not for any third-party application. There's nothing that will allow you to attest that arbitrary third-party code is running some specific version without being tampered with, you can only attest that the base OS/kernel have not been tampered with. In their specific case, they attempt to patch over that by taking the hash of the binary, but you can simply patch it before it starts.

To do this properly requires a TEE to be available to third-party code for attestation. That's not a thing on macOS today.

MDMs on macOS are permissioned via AccessRights, and you can verify that their permission set is fairly minimal and does not allow what you've described here (bits 0, 4, 10).

That said, their privacy posture at the cornerstone of their claims is snake oil and has gaping holes in it, so I still wouldn't trust it, but it's worth being accurate about how exactly they're messing up.

A note, as others have posted on this thread: I mention this as a concrete and trivial flaw in their whole strategy, but the issue is fundamental: there's no hardware enclave for third-party code available to do the type of attestation that would be necessary. Any software approach they develop will ultimately fall to that hole.

Looking at their paper at [1], there's a gaping hole: there's no actual way to verify the contents of the running binaries. The binary hash they include in their signatures is self-reported, and can be modified. That's simply game over.

[1] https://github.com/Layr-Labs/d-inference/blob/master/papers/...

That idea was not expressed in the article, only the fact that the ads were removed. This is worth covering, especially when coupled with the context for what ads Meta regularly does allow. One does not have to believe that they're obligated to do so while also believing that it's incredibly scummy behavior that consumers should be aware of and question.

https://www.reuters.com/investigations/meta-is-earning-fortu...

Turns out the intent to do so was announced on April 2nd as well.

They have, but they also just announced this week that for business and enterprise plans, they’re switching from quotas for codex to token use based pricing, and I would expect that to eventually propagate to all their plans for all the same reasons.

You're not looking at the albedo of the solar panels in isolation though, you're comparing it to asphalt and cars. Typical solar panels have an albedo of ~0.3. Asphalt around ~0.05.

Using a release less than two months is hardly “so far behind”. The 1.24 series had considerable regressions that have taken a number of patch releases to fix, it stands to reason that the same would be true of newer releases. Given there's still miscompilations getting fixed as late as 1.25.8, and 1.25 brought in large changesets for the new experimental GC, sticking it out while 1.24 is still getting patches a mere handful of weeks ago is not unreasonable.

It’s been merged into the systemd project, so one must assume that the systemd maintainers have some level of influence over it.

> especially with the really short name limit of only 24 characters.

And with no meaningful separator characters available! No dashes, underscores, or dots. Numbers and lowercase letters only. At least S3 and GCS allow dashes so you can put a little organization prefix on them or something and not look like complete jibberish.

What a ridiculous take. Many people loudly raised the question and objected to the practice from the beginning, but a handful of companies ignored the objections and ran faster than the legal system. If they were in the wrong, legally or morally, they still deserve to face repercussions for it.

It is a measure of the intended level of care that the users of your interface have to take. If there's no unsafe in the interface, then that implies that the library has only provided safe interfaces, even if it uses unsafe internally, and that the interface exposed enforces all necessary invariants.

It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.

Generally speaking, there's prompt caching that can be enabled in the API with things like this: https://platform.claude.com/docs/en/build-with-claude/prompt...

For a specific harness, they've all found ways to optimize to get higher cache hit rates with their harness. Common system prompts and all, and more and more users hitting cache really makes the cost of inference go down dramatically.

What bothers me about a lot of the discussion about providers disallowing other harnesses with the subscription plans around here is the complete lack of awareness of how economies of scale from common caching practices across more users can enable the higher, cheaper quotas subscriptions give you.

The thing is that almost always isn't good enough. If it can't prove it, then a human has to be put back in the loop to verify and assert, and on sensitive timelines when you have regulatory requirements on time to acknowledge and resolve CVEs in dependencies.

cargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.

> Is there an equivalent to govulncheck for say NPM or Python?

There never could be, these languages are simply too dynamic.