[Aurornis]

This cheap criticism of the headline doesn’t actually apply to the problems brought up in the article:

> Your PDS operator can post as you, like things as you, follow people as you, and it would be cryptographically indistinguishable from your real activity. The signatures are valid.

Your domain name owner or DNS provider cannot redirect your domain name to a different server and cryptographically impersonate you.

[jacobgold]

Your DNS provider can obtain a TLS certificate for your domain and cryptographically impersonate https://yourdomain.tld

It's not exactly the same thing but it's close.

[Aurornis]

Still not the same thing as in the article. Server side TLS certificates are widely understood to be tied to the current owner of the domain.

In a social protocol or context, I would expect a private key to be in the private control of the individual, such as when someone uses their private key to sign an email or git commit.

The purpose of signing your emails or commits is to provide a good indicator that it actually came from you, not someone who managed to get access to your email account at the time.

[OneDeuxTriSeiGo]

> The purpose of signing your emails or commits is to provide a good indicator that it actually came from you, not someone who managed to get access to your email account at the time.

This is true and it's still true in the ATProto ecosystem but in a different context.

It asserts that events and records are authored by your PDS, not by you specifically. Which is certainly closer to the intent of TLS certs.

And technically you can maintain a PDS proxy that can only host, broadcast events, and receive content but that doesn't have any keys or signing capabilities.

Then you can have a local PDS that does your signing and sends signed events and records (basically signed state updates) to the PDS proxy to actually emit to the network. This then allows you to lock your keys behind a hardware key to better lock everything down. Of course there are trade offs to this. If it requires physical auth then it can only work on one device at a time or you have to self host it homelab style at which point it might just make more sense to host the PDS yourself anyways.

There's a project thats working on this very thing but I've not kept up with it and I can't remember what the name of it is. If any ATproto people in the comments knows the name/link feel free to reply under this to enlighten me + everyone else.

[arjie]

If you use your private key to sign your commit, I don’t see how your PDS can impersonate it. There are different layers here. Your commit is still signed by you and non-impersonatable by the PDS operator. But the ATProto layer signing is under control of the PDS. So in that case you’d see either unsigned or differently signed git commits being reported at the ATProto layer as by you.

That seems entirely normal. The PDS handles ATProto actions but it cannot modify the git signature (obviously!). It’s no different than the fact that GitHub can post that you’ve committed a “verified” badge commit by adding a new signing key to your account and signing new commits with it.

The storage entity can always claim power over this by reporting a new key and signatures with that key. Seems entirely normal.

[jacobgold]

This is why your DNS hosting provider, despite not being the "current owner of the domain", being able to impersonate your site (terminate a cryptographically secure TLS session) with your customers is a similar problem.

I do agree they're not the same but the trust and risk are very similar.

[edoceo]

DNS providers and registrars seem to have a longer trust established, that reduces the risk.

They are similar in that: jerks can be jerks. But one of the jerks I've trusted for 30 years and I hardly know the the other jerk.

[OneDeuxTriSeiGo]

Kind of. Your PDS can impersonate you but you can have higher ranked "recovery keys" that can undo/recover all the damage.

Socially whether you can explain off that your PDS acted maliciously or that it was hacked or whatever is a different story but if you keep recovery keys for your DID you can take back control and undo everything your PDS did that you didn't authorise pretty trivially. The UX for it needs to be improved but technically the process is super simple/straight forward.

And those recovery keys provide a mechanism for declaring "hey i didn't do this I was hacked" on top of specific events but nothing for taking advantage of that cryptographic opportunity has been built out yet.