I don't know if I would personally fund such a venture though, for roughly the same reason existing manufacturers aren't expanding production.

That's basically project Glasswing; mixing responsible disclosure with frontier exploit generators.

The book fits into the current unknown-unknowns world of rapidly increasing machine-learning capabilities across most domains where there is little evidence to suggest that "intelligence" is limited to the human limit (which is already quite high relative to the 99.9th percentile; we get a few Einstein, Von Neumann, Turing class people in a century) or the human body.

How would one even word a bulletproof subscription contract for agentic tokens, anyway? You can't forbid automation because sub-agents are automation. You could forbid "using tokens for the benefit of more than the human who signed up" but then what do families (especially with kids) need to do? What if your friend asks you a question and you turn to a chat model? Forbidding "reselling" tokens outside of a household sounds like the closest terms but that's leaky for anyone who travels a lot, etc.

Fixed cost per token simply works.

Another way would be auto-enrolling passkeys from other devices you own through a standard API. Enroll your trusted Apple device in your Google Account's settings, or your Bitwarden/KeePass, and vice-versa. When your iPhone creates a passkey at a site, iCloud notifies Google, which issues a new passkey and sends the public key to iCloud, which auto-enrolls it at the site alongside the iCloud passkey. BitWarden gets the same treatment. When you open your KeePass vault it checks Google and iCloud and picks up any pending offers for passkey enrollment and completes them.

Simple, secure, opt-in, and users control their devices and passkey vaults with minimal hassle. If a device is lost, the other services can help you automatically delete the compromised passkeys and set up your new replacement device.

Matter does something very similar with cross-compatibility between Apple and Google (and the rest of the ecosystem) when new devices get enrolled with the user's choice of PAA; the only thing missing is roughly cross-PAA enrollment but that would be just one additional trivial trust relationship in both ecosystems.

There have been a few years now of arguments about the level to which transformers do or do not have a world model (v.s. being purely stochastic parrots like early pre-trained LLMs) and now we have some tools to actually make quantifiable determinations.

The tokenizer is, at best, a sensory mechanism as evidenced by 1) the random generation of the tokenization scheme, and 2) vastly different tokenization schemes produce virtually identical behavior. It'd be like if Noah Webster threw a bunch of movable type into a bucket (breaking some words in half) and then drew randomly to make the first English dictionary.

EDIT; I was too cavalier with the comparison of tokenizer to sensory modality; my ultimate point is that direct byte-to-token transformers can achieve similar overall performance which to me makes a weights to meat comparison pretty straightforward, but the particular tokenizer in use certainly has a large impact on both efficiency and accuracy on specific problems (e.g. digit representation)

Otherwise you have the right idea; exfiltration requires three things; input of a prompt injection, LLM processing the prompt injection along with private data, and finally some interaction with the outside world that contains the LLM output (or an externally-visible decision based on the output).

And side channels based on timing/ordering allowed network accesses, e.g. https://allowed.site/0 and https://allowed.site/1.

There's essentially no prevention against exfiltration prompt injections without a full classified data processing system that prevents interactions between different classification levels except through strict controls including provable redaction that excludes side-channels (e.g. information theoretic proof that side effects are limited to pre-defined finite outcomes).

It's also incredibly difficult to prevent prompt injection; attackers have the huge asymmetric advantage of being able to test prompts against all known security measures and trying multiple parallel attempts, including obfuscating them. Injections can be in dependencies, externally generated data, bug reports (which often contain externally-generated data), documentation, and many other useful places that we want agents to have access to.

My prediction: we'll continue to essentially YOLO it.

So if you keep rereading that section of the disk you eventually get all the data, save it somewhere, write a bunch of new patterns over it, then write the original data and verify it reads back correctly many times.

I believe the article's analysis about RAID is wrong though; most controllers will start resilvering or just fail a drive once it experiences too many IO errors.

In my mind, the biggest difference is whether front and rear drive shafts turn at exactly the same rate; if so it's "4WD". If clutch slippage or a differential allows different front and rear axle speeds then it's some form of AWD. But many AWD systems have clutches capable of effectively locking the front and rear driveshafts. E.g. the Suburban had tire-hop turning on pavement in 4WD mode which is about the most torque that drive-train would be expected to encounter.

https://en.wikipedia.org/wiki/Grafting

You can require approvals from N domains from (potentially) different people.