The problem with putting this at the heart of the IP protocol is that IP needs to know the source and destination so you can communicate. If you want to obfuscate the source, it's more involved than what IP is tasked with.

IP is meant to try to get data from source to destination, with the absolute minimum info built in to support the notion of routing and subnets. Because it's called an internetworking protocol after all, meaning your traffic will traverse networks.

Anything else is not IP's job. Because IP is so simple it allows high performance networks to be built and expanded easily. When you make things at the IP layer complex, you get something like the phone network, which is hard to expand when needed. You want the core lean, mean, dumb, and fast.

I played around with some of the Linux TPM tools on a Dell system.

Seems like all that it's meant to be is a way to sign stuff with a key locked to a machine that cannot be retrieved unless you know how to read the nonvolatile memory of the TPM chip.

The whole remote attestation crap is handled by something else, Intel's TXT being such an implementation I think. That would seem to be the feature you want to stay away from, or NICs that have an integrated TPM and I presume something with TXT also available ...

And on this system I could tell the TPM to create a new, revocable EK, which to my understanding is the "root" key in the whole TPM scheme.

I kinda like it. What's the big deal about the TPM other than I'm sure it has a hidden debug mode that reveals the EK to whoever the manufacturer wants to give that ability to.

will never be the same.

QNX isn't a UNIX derivative at all. I think it has some POSIX compatibility stuff thrown in but it's not a unix.

How many unique such questions can you generate automatically?

Part of the advantage of a CAPTCHA based on random sequences of letters and numbers is that if done right it should be impossible to build a database of all possible CAPTCHAs and correlate them with anything the CAPTCHA generator creates.

Lol, you still had a parallel bus though, or channelized I/O or whatever you big iron types call it, not some CPU-driven molasses-based interface, right?

Yeah, with that super slow CPU driven bit-banged 3-wire bus connecting them and the 4K of RAM in the 1541 you could parallelize like it was 1899.

Citation needed. What spinning HDD uses wear leveling? Unless you mean sector sparing, but that's something different.

Or I guess it would not use any data network if it didn't contact a server. In the Slashdot tradition I haven't RTFI.

Because this would not use any traceable/loggable data network and may work in a situation where there is the cover of noise.

Maybe creation will just be so easy and commoditized that it isn't worth it to try to do it as profitable activity. Doesn't mean people won't do it. They'll do it for fun, or because they themselves need something. I'd love it if it was so easy to create a program I need that I could do it on my own without having to hire anyone or rely on someone else to come up with the idea and try to charge me for it. I don't ever see this happening, of course, but if it did, it's not a bad thing.

There isn't always a need for a middle man and no real reason to have one if one is not needed.

Nothing stopping you from using a PC as a router. 2 NICs + Linux or BSD, and some knowledge about how their respective packet filtering tools work, and there you go.

It is involved, and requires lots of networking knowledge, but a lot of fun.

how much longer until I can install Debian on my SIM card?

SSH over PPP.

Because I like transmitting and receiving at .56kbits/sec.

Barcodes aren't that difficult to decode. If you can't get a barcode reader, a program could likely easily decode it from a scanned image.