Require two-way confirmation of domain association (harrassment risk mitigation)

[MikeBeas]

Currently it's possible for anyone to assign a handle to anyone else and have that handle work network-wide.

Example:

• Own a domain (or buy a new one)
• Get a user's DID (easy via a whois lookup)
• Add a new TXT record to your domain with that person's DID as the value (say, _atproto.big-dumb-idiot.mikebeas.com, or _atproto.big-dumb-idiot.com)
• Tag @big-dumb-idiot.mikebeas.com or @big-dumb-idiot.com or whatever name you went with on Bluesky
• They will see this notification in the app with this handle displayed
• Anyone on any atproto app can tag them with this handle, enabling a whole new kind of harrassment

I tested this by setting up a new TXT record on my secondary domain and not associating it with any accounts through the Bluesky UI, then tagging that from a second Bluesky account.

I'm not super well versed in all of the PDS stuff yet, but I think the solution here is for the PDS to only accept mentions from confirmed handles that were written to it by an authenticated user. i.e., I have to actually add an "also known as" value to my PDS before it will accept or display notifications sent to that name.

The publication of a post containing a malicious/hijacked mention like this should probably be rejected entirely if the PDS being mentioned does not acknowledge ownership of the handle, and the DID resolver should not return this DID in that situation. Tapping the malicous mention in a post that gets past this limitation should not lead to the profile being "tagged" via the fake handle.

[dholms]

Totally agree with the motivation here. However, it is a bit tricky. What if a user updates their handle? The hard link to their did in past mentions will stay intact, but we cannot update the text of the post (where the handle is). However, those records should still be passing validation & not be rejected.

A couple options:

• we flag "outdated" handles in posts which would cover the case I describe above & also the case you're describing
• we only enforce on first index, which will work in most cases, but could cause some issues in race conditions & historical backfill
• we dynamically overwrite the text of the post in UIs with the current handle

We're planning on doing something like option 1 for links, but I think option 3 may work nicely for handles

[MikeBeas]

I think option 3 would be the best for handles, if it’s feasible. I don’t know if character counts or anything like that might become an issue if the current handle is longer than the old one. But always displaying the current handle would be really great.

[ericsampson]

I'm glad that someone created this issue and that it's being considered! Definitely seems like something that will need to be addressed before going live.

it seems like a bit of a bummer if every client/UI is going to have to implement this feature, if I'm following your suggested "option 3" solution to the "handles can change" problem.
I guess option 1 would also have the same implication.