tashian

I think of it as a long term negotiation with society about what we are all willing to sacrifice for the conveniences of a new technology.

I don't think that negotiation ever ends, either. It just evolves with the tech. Robert Moses exuberantly covered New York City with highways during the mid 20th century. Each new bridge and highway he built induced demand for more cars. So, every road was clogged as soon as it opened. And his answer was always to build more roads.

Moses built a base of power that depended in part on revenue from toll booths. But, some of his projects were disastrous for communities and should not have ever happened. Because of his fixation on cars, and because of how he was benefitting from cars, he was unable to recognize that a city's transportation infrastructure must be balanced between different modes.

Personal cars are almost the least ideal form of transportation for a dense city and for intercity traffic. But once the power around a single technology becomes locked in, it can freeze the negotiation around it and the power structures can safely ignore any further resistance.

Interesting note ... a 2017 review of 70 London sites where Transport for London removed railings found serious and fatal pedestrian injuries fell 53% in the three years afterwards compared with the three years before.

https://content.tfl.gov.uk/pedestrian-railings-removal-repor...

What Facebook has is an opaque process run by AI with no way for most people to appeal.

But:

- You cannot prove that no one has ever been able to break a Secure Enclave or a YubiKey or another secure element. That's okay, these companies focus on making it so expensive that it's not worth doing.

- The analog "attack vector" is real, but that was always true with analog cameras as well. Anyone could have taken an analog picture of a screen, or even painted a hyper realistic image of something that never happened.

I think a realistic goal for provenance is to at least get to parity with analog cameras ("this is a picture directly from a sensor"), not to make the perfect system for proving that a photo is of a real world event.

And, Apple could choose to integrate a LiDAR depth map into the signed photo as a mitigation against the analog attacks (eg. pictures of screens).

VPN providers all run the same two or three VPN protocols, all with similar security guarantees and privacy limitations.

I've been playing with MASQUE relays over the last year. Apple's iCloud Private Relay is a MASQUE relay (two, actually). MASQUE can offer genuine privacy improvements via traffic separation, preventing any single party from correlating the traffic source and destination.

Some of the privacy concerns of VPN users can be mitigated with better technology. And relays are built into Apple operating systems today. I'm surprised that they aren't very widely deployed yet.

https://waves.tashian.com

That's the next step for me in learning AI... playing with different integrated editor tools.

Six months ago, I tried building this app with ChatGPT and got nowhere fast.

Building it with Claude required a gluing together a few things that I didn't know much about: JavaScript audio processing, drawing on a JavaScript canvas, an algorithm for bilinear interpolation.

I don't write JavaScript often. But I know how to program and I understand what I'm looking at. The project came together easily and the creative momentum of it felt great to me. The most amazing moment was when I reported a bug—I told Claude that the audio was stuttering whenever I moved the controls—and it figured out that we needed to use an AudioWorklet thread instead of trying to play the audio directly from the React component. I had never even heard of AudioWorklet. Claude refactored my code to use the AudioWorklet, and the stutter disappeared.

I wouldn't have built this without Claude, because I didn't need it to exist that badly. Claude reduced the creative inertia just enough for me to get it done.

Primarily, the YubiKey is there to lock away the private key while making it available to the running CA. Certificate signing happens inside the YubiKey, and the CA private key is not exportable.

This uses the YubiKey PIV application, not FIDO.

As an aside, step-ca supports several approaches for key protection, but the YubiKey is relatively inexpensive.

Another fun approach is to use systemd-creds to help encrypt the CA's private key password inside a TPM 2.0 module and tie it to PCR values, similar to what LUKS or BitLocker can do for auto disk unlocking based on system integrity. The Raspberry Pi doesn't have TPM 2.0 but there are HATs available.

As for the "hours" max interval, this is the result of a design decision in Go's time duration library, dealing with the quirks of our calendaring system.

> -Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it's to protect against physical theft of the keys, they'll just put the entire Raspberry Pi in their pocket.

Yep, it's overkill. Homelabs are learning environments. People want tutorials when trying new things. It's a poor man's HSM because not many people will buy an HSM for their homelab, but almost everyone already has a YubiKey they can play with.

The project solves the problem of people wanting to learn and play with new technology.

And it's a way to kickstart a decently solid local PKI, if that's something you're interested in.

The RNG is completely unnecessary flair that just adds to the fun.

> -Creates a two-tier PKI... on the same device. This completely defeats the purpose so you can't revoke anything in case of key compromise. > -They're generating the private key on disk then importing into the YubiKey. Which defeats having an external key storage device because you have left traces of the key on disk.

The tutorial shows how to generate and store the private key offline on a USB stick, not on the device or the YubiKey. The key material never touches the disk of the Raspberry Pi.

Why store a copy of the CA keys offline? Because YubiKeys don't have the key-wrapped backup and restore feature of HSMs. So, if the YubiKey ever fails, you need a way to restore your CA. Storing the root on a USB stick is the backup. Put the USB stick in a safe.

If you want active revocation, you can set it up so that the intermediate is revocable—in case physical theft of the key is important to you. (We have instructions to do that in our docs.)

> -All this digital duct taping the windows and doors yet the article instructs you to download and run random binaries off GitHub with no verification whatsoever.

It's open source software downloaded from GitHub. The only non-smallstep code is the RNG driver (GitHub is the distribution point for that project). Was there a kind of verification that you expected to see?

> -Why do you need ACME in a homelab and can't just hand issue long lived certificates? -OpenSC and the crypto libraries are notoriously difficult to set up and working properly. A tiny CA this is not.

Most people don't need ACME in their homelab, they just want to learn stuff. That said, we have homelabbers in our community issuing certs to dozens of endpoints in their homelab.

Whether you issue long-lived or short-lived certs is a philosophical issue. If a short-lived cert is compromised, it's simply less valuable to the attacker. Short-lived certs encourage automation. Long-lived certs can be easier to manage and you can just manually renew them. But unplanned expiry of long-lived certs has caused a lot of multi-million dollar outages.

I hope this helps clarify things.

What I loved about the MUD as a learning environment was the players. On a busy night we'd have over a hundred people playing. So, I got to cut my teeth on a real, live production system with actual users. That motivated me. There were mild consequences if I broke things. And, if I made things better for the players, it felt good.

For me, this environment was so much better than doing programming problem sets by myself, writing code that no one would ever use.

https://tashian.com/articles/how-i-learned-to-program/

The problem is, baking bread is such a sensual activity.

You need to understand what it feels like when the texture of the dough is right. You need to learn how to fold and stretch the dough and shape it in ways that are very difficult to describe. None of this translates well into English, no matter how good of a writer you are. And photos are of limited utility.

Learning in person from a knowledgeable teacher is ideal. Just as with a board game.

But, since we are talking about media here, what helped me the most with bread baking was Instagram. I watched videos of bakers doing each stage of the process and talking me through it. I saw the texture of the dough they were using, and how they worked it.

I learned by example.

And I wonder if board games are similar to bread.

Would I rather read a 70-page rule book, or watch someone play the game for a while or teach it to me in a video?

I'd prefer the video content, and then I'd want rulebook as a reference guide rather than a tutorial.

See my post https://smallstep.com/blog/command-line-secrets/ for a bit more of a deep dive about using secrets on the command line.

Credential files are a good, simple, portable option. Files have permissions already. They don't depend on an external service or a proprietary API.

And, if your program accepts a credential file, it will be compatible with systemd credentials. systemd credentials offer more security than an unencrypted credential file. They are encrypted and can be TPM-bound, but they don't require the software using the credential to have native TPM support.

I write about various tech topics. Writing is thinking. It helps me learn.

TPMs do offer up their endorsement key (or an endorsement key certificate) to third parties.

And, TPMs can share attestations in a way that doesn't reveal the endorsement key. They use attestation keys for this. Attestation keys can sign TPM attestations, and these keys do not identify the TPM.

This approach requires a trusted CA. The CA confirms the TPM's identity (using an endorsement certificate issued by the TPM vendor), it confirms that the attestation key and endorsement key reside on the same TPM, and it issues a certificate for an attestation key.

The attestation certificate might contain TPM vendor info, firmware version number, and proof that the attestation private key is hardware-bound. But it need not contain any permanent identifier. The TPM can now use its attestation key and certificate to sign attestations for a third party.