Comment by nl
15 days ago
> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.
But the design hole is treating (IMO unfortunately) transient identities (the web's domain name system) as something that should persistently identify something. Adding hacks like this doesn't fix the underlying mismatch but creates new issues as seen in the article.
Or to put it another way: Domain names changing hands is how the web works. If you design your system to support web identities in a way that domains can't change hands then you are not supporting web identities but rather something different.
2 replies →
> I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).
This is fairly accurrate
Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.
Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.
While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.
> if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways
Actually no. It's not supposed to break implementations that are made according to spec. It's not quite TOFU. Keys can be rotated. An Update activity would not work in this case because the new domain owner will not have the private key to sign it, but a periodic refresh that most implementations do will. The only fundamentally immutable field of any AP object, including an actor, is the ID. In practice, objects usually don't change types either, even though the spec technically doesn't forbid that. The only case I know when they do is when you edit a post and attach a poll, or remove a poll from a post that had one. Then the type changes between Note and Question.
Of course the dependency on DNS isn't nice. But we haven't invented anything better yet, so this will have to do for now.
Account migration on the fediverse is a thing, but it could be better by transferring past content. This is an active area of research right now.
3 replies →
"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time."
Email has that problem too, doesn't it?
4 replies →
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
I’m trying to understand how “burning” works here. If I understand correctly:
1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.
2. They deleted their account and let the domain expire.
3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.
I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.
(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)