Comment by wmf

13 days ago

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.

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

    • 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?