6 ms·

> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky? Presumably to stop credential reuse attacks on Bluesky

by nl 9mo 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.

wmf 9mo ago
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
- embedding-shape 9mo ago
  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.
  - account42 9mo ago
    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.
    - a022311 9mo ago
      I totally agree. This is the fundamental reason I've stayed off there until now. I'm not about to tie my permanent identity to a domain which I might not own tomorrow. And did:plc is not an option for obvious reasons.
    - troyvit 9mo ago
      Even though naively I treat my own domain as my online identity I see what you mean since they can be taken away by actions outside of our control. What would work better though? Like are we talking a more hardened identification system tied to personal data that can't change? If that's the case are there negative privacy effects of that, especially with whatever system controls that data?
grishka 9mo ago
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.
- steveklabnik 9mo ago
  Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
- fc417fc802 9mo ago
  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.
  - Meneth 9mo ago
    "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?
fc417fc802 9mo ago
> 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.)
- WorldMaker 9mo ago
  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).
  - nl 9mo ago
    This is fairly accurrate
- nl 9mo ago
  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).

by nl 9mo ago

wmf 9mo ago

It seems backwards to worry about attacks when basic functionality is undocumented/broken.

embedding-shape 9mo ago
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.
- account42 9mo ago
  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.
  - a022311 9mo ago
    I totally agree. This is the fundamental reason I've stayed off there until now. I'm not about to tie my permanent identity to a domain which I might not own tomorrow. And did:plc is not an option for obvious reasons.
  - troyvit 9mo ago
    Even though naively I treat my own domain as my online identity I see what you mean since they can be taken away by actions outside of our control. What would work better though? Like are we talking a more hardened identification system tied to personal data that can't change? If that's the case are there negative privacy effects of that, especially with whatever system controls that data?

grishka 9mo ago

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.

steveklabnik 9mo ago
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
fc417fc802 9mo ago
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.
- Meneth 9mo ago
  "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?

fc417fc802 9mo ago

> 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.)

WorldMaker 9mo ago
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).
- nl 9mo ago
  This is fairly accurrate
nl 9mo ago
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).