Open agentjabsco opened 12 months ago
agentjabsco
commented
12 months ago Yeah, as I suspected, users can still take actions that identify them with their original handle, even after the domain record that verified it is changed to point at a different account. Feels like the kind of thing that could potentially end up leading to problems down the line
pfrazee
commented
12 months ago I'm going to bounce this issue to the atproto repo, but I can tell you there's some work being done on dealing with invalid handles (it's specced and in a backend PR and I think frontend just needs to implement). The behaviors around invalidation might need some further discussion (Im not sure where they're at on that)
bnewbold
commented
12 months ago Great question! We still need to write this up more formally in the specs, but as a quick non-canonical answer:
handle.invalid as a special-case. this is currently an invalid identifiers per the handle identifier spec, that will be updated. this value is only emitted; it doesn't work to supply as a login name, or query parameter, or things like that.agentjabsco
commented
12 months ago handle/DID mapping needs to be bi-directional, and services throughout the ecosystem should verify the bi-directional mapping. Clients (mobile, browser) shouldn't need to do this, their PDS (or even an AppView, etc) can do it on their behalf.
not sure what this is referring to: I'm guessing the thing where @notsorry.lol shouldn't be able to point to the same DID as @bsky.app without the DID's permission?
after an initial check, re-validation can be periodic and/or lazy, but shouldn't be "permanent". guidelines on timing around this are TBD (hourly? daily? weekly? which events trigger an immediate refresh? etc)
I was thinking something like every time the account takes, or is otherwise the subject of, any action, batched at 30-minute intervals (ie. so if I like a post, the server checks that both my handle and the handle of the account that posted the comment I'm liking is still current, and then it'll be satisfied with that for the next half-hour)
also, it should be possible for anyone to explicitly trigger a revocation check (ie. clear the cached value) on-demand within that 30-minute window, though I'm not sure what the UX surface for that would look like without burying it deep in some obscure corner of settings that virtually nobody but me would possibly be aware of (could be the sort of thing that's just an API call that can be invoked through external tooling, ie. something like Tweetdeck/Skyfeed)
if the handle-to-DID verification breaks, and there is no currently valid handle for an account (repo), services should substitute in handle.invalid as a special-case. this is currently an invalid identifiers per the handle identifier spec, that will be updated. this value is only emitted; it doesn't work to supply as a login name, or query parameter, or things like that.
pretty sure there needs to be a better answer than this: a magic handle that still lets a user post but makes their account unmentionable/otherwise-unactionable strikes me as the kind of thing that could end up being a really bad idea. at the very least, I would consider something that surfaces the underlying DID
generally "everything should keep working" with no currently valid handle
I actually think it wouldn't be a terrible idea if users who can't get along with any handle-providing party weren't allowed to post. like iirc Twitter saw a major reduction in certain forms of harassment just by adding a "don't show replies from users without a profile pic" button in settings
pfrazee
commented
11 months ago not sure what this is referring to: I'm guessing the thing where @notsorry.lol shouldn't be able to point to the same DID as @bsky.app without the DID's permission?
Correct. The bi-directional mapping happens by the DID Document referencing the handle in addition to the DNS/.well-known pointing to the DID.
I was thinking something like every time the account takes, or is otherwise the subject of, any action, batched at 30-minute intervals
That's a pretty short TTL. What are the threat models you're thinking about which would drive it down so far?
pretty sure there needs to be a better answer than this: a magic handle that still lets a user post but makes their account unmentionable/otherwise-unactionable strikes me as the kind of thing that could end up being a really bad idea. at the very least, I would consider something that surfaces the underlying DID
Yeah this is a specific concern we have been discussing. I dont have any reason to believe it will make the account difficult to action per-se, but it will make the account harder to find. We ran through a lot of scenarios internally to try to predict how users will use the behavior and even considered surfacing it as a kind of "anonymous mode" feature. We ultimately decided that it wasn't meaningfully anonymous so surfacing it as such a feature might create problems.
It's somewhat difficult in an open system to fully stop activity by an account -- a PDS can do that but the network can't stop other accounts from doing it. We do have options for handling this however: we can do similar things that we do with impersonation where we heavily mask posts by the accounts, or even go so far as using block-like logic where the account is massively gated off. We just have to remember that the invalid-handle state can happen by accident and take care not to nuke it while users are trying to fix it.
... like iirc Twitter saw a major reduction in certain forms of harassment just by adding a "don't show replies from users without a profile pic" button in settings
Right yeah, same thinking. I'm going to make some updates today that just make sure the software doesn't break around invalid handles. I'll follow up with more specific downregulation techniques as part of some other moderation tooling work I'm doing.
agentjabsco
commented
11 months ago I was thinking something like every time the account takes, or is otherwise the subject of, any action, batched at 30-minute intervals
That's a pretty short TTL. What are the threat models you're thinking about which would drive it down so far?
Let's say I were to grant users their own subdomain handles allowing them make posts under my own domain, so long as they adhere to certain rules, and one of them went rogue and made some posts violating those rules (such as misrepresenting their own authority within that domain). If I were unable to promptly revoke their handle, they could potentially use this to cause significant damage to my domain's "brand reputation", to say the least
bnewbold
commented
11 months ago Accounts in a situation with invalid handle: yeah, we probably don't want folks to be able to operate indefinitely with a broken handle. The flip side is that we don't want accidents or self-hosted whoopsies to be too harsh (eg, DNS messed up over a long weekend). This feels like an area where the network/ecosystem will iterate collectively. Maybe something like "account is normal for 1-7 days, after that repo doesn't get propagated but old content sticks around".
Wanting to have a specific SLA around revocation of handles is reasonable, but i'd be worried about over-committing and then we yank the rug for operational/efficiency reasons later. DNS propagation is often under an hour, but is infamously hard to put a time bound on in edge cases. If we are successful and have many, many accounts in the network, and there are many services, the traffic of DNS and well-known lookups could be huge and cause external problems.
Maybe it would help if there was an API to poke a PDS or BGS (or other services) to re-validate the handle of a specific account. If the handle was invalid, a repo stream event would be emitted indicating that the handle is now invalid, and downstream services would pick that up. We could also centralize the duty of verifying handle freshness to home PDS or BGS operators, so that not every service in the network doing lookups (unless they want to).
agentjabsco
commented
10 months ago agentjabsco
commented
10 months ago Wanting to have a specific SLA around revocation of handles is reasonable, but i'd be worried about over-committing and then we yank the rug for operational/efficiency reasons later. DNS propagation is often under an hour, but is infamously hard to put a time bound on in edge cases. If we are successful and have many, many accounts in the network, and there are many services, the traffic of DNS and well-known lookups could be huge and cause external problems.
Maybe it would help if there was an API to poke a PDS or BGS (or other services) to re-validate the handle of a specific account. If the handle was invalid, a repo stream event would be emitted indicating that the handle is now invalid, and downstream services would pick that up. We could also centralize the duty of verifying handle freshness to home PDS or BGS operators, so that not every service in the network doing lookups (unless they want to).
yeah, this seems like the most reasonable approach to handle the use case I outlined: having resilience / error tolerance be the normal behavior (iterating the details on that based on the externalities we're seeing pop up now that this is rolling out in the beta) is fine if there's a way to specifically invoke a revocation check at the API level (which anyone catering to this niche can code an appropriate corresponding UX for, as I said in July)
agentjabsco
commented
10 months ago as predicted, a user with an invalid handle is now harassing other users while using bugs the invalidity triggers as a form of cover
this is really the core of why I'm saying the "invalid handle" state should still be a unique and functional handle, something like "$BASE32_DID_HERE.plc.did.illegal.name" or something: anything more complicated/special than that is going to open the door to exactly the kind of under-tested corner cases that inevitably lead to exploitable bugs. for more insight into the nature of this problem, consult the "System failure" section of Systemantics
bnewbold
commented
10 months ago It is a real problem and concern!
An alternative to encoding DIDs in a special type of handle would be to just use the DIDs as DIDs. One of the earlier proposals around this was to display just the DID (with a warning icon/color) instead of a handle when there is a problem. We could also try to get mentions of DIDs working. I think that this introduces a similar amount of complexity and confusion as a backup handle which encodes the DID, but has the benefit of already being a part of the underlying protocol, not a new thing. Many of the API endpoints/parameters take either a DID or a handle. I think the same kinds of under-tested bugs would crop up around special backup handles as they would with DID-instead-of-handle.
I'm going to test how Bluesky currently handles this in a moment (I have a hypothesis, but I'm not gonna speak to it until I've determined the actual observed behavior), but this is a subject I've thought about: how should AT Protocol sites handle checking that a user's domain handle is still valid, and what should they do if it isn't?
It shouldn't just be a one-time thing: say, for example, a hellthread.vet user did something to dishonor the Hellthread. In a case like that, it should be possible to strip them of their "title" (note that, although I am referencing their culture for this example, I do not claim to speak for the Hellthreaders, who are a proud and powerful people)
There are other, more serious examples I could draw from here, along the same lines as why an employee at a company shouldn't still have access to their company email address after leaving the company.
Anyway, I will say that this is one reason I don't think Bluesky should release a user's *.bsky.social handle in the event that they change their presented handle to a different domain. just my 2¢