ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
[accounts] expose indefinitely unique and unchanging account IDs
Problem
BitBot can have permissions assigned to nickserv account names (that are pulled from extended-join, account-notify, account-tag and WHOX)
If that nickserv account expires and someone registers it again, they will inherit those privileges due to the account name being the same.
Solution
Somehow also expose an opaque indefinitely unique (never reassigned to another account) and unchanging (persists through account name changes) identifier for the account. This could perhaps hop on board with account-tag and WHOX? Would be a pain to factor this in to extended-join and account-notify unless we add new versions of those.
Solution gripes
Having a unique and unchanging identifier on your account allows people to track you through account name changes (stalking etc)
A possible solution for this is to non-normatively recommend the ability to refresh this ID whilst warning the end user that it may cause issues with recognition by robots.
Existing software
Spoke to @ilbelkyr and Atheme already internally stores a unique ID per account. Not sure about Anope currently but will query them.
We previously had a discussion on this, and the issue is that it might allow tracking, and the conclusion was that, if such an identifier is introduced, users should have the choice to enable or disable it (bitbot might e.g. require users to enable it to use bitbot, but it should be optional).
Personally I’m in favor, regardless of if it’s optional or always visible.
Suggestion that because Atheme uses sequential IDs for user accounts, it would not be best to expose those to users and might not be suitable to just provide the user IDs hashed. maybe a randomly generated ID per user or so.
:+1: I was planning on adding this to InspIRCd anyway so it'd be good to be standardised.
I don't see the point of adding it to extended-join ~~and account-notify~~ though. Those are kinda obsolete now we have account-tag.
How does having an account id tag on their join message like with the account tag currently not accomplish that?
extended-join-> shows us account when they signed in before joiningaccount-notify-> shows us their account when they sign in after joiningWHOX-> shows us their account when they signed in before we joined
having a new message-tag on extended-join is great but if we need to cover at least those 3 bases and, from what I understand, you are just proposing the first and last.
For the ID what about using the time registered. It's not guaranteed to be unique nor is it random but it will be unique to that instance of the account.
I actually have some work on modules for InspIRCd and Anope that syncs the time registered with the account name, for additional channel and/or user protection. e.g., can't join channel unless registered longer than
There's no reason the form of generating the ID needs to be standardized AFAICT and in general I agree that they should be opaque, and not carry any other meaning than the fact it's an identifier for an account.
I'm dealing with something similar at work with sequential IDs. Trying to get them changed over to UUID4 which is probably overkill, but it works. It conveys no information about the client themselves and no information about any other client.
I think this should have a cap so that we don't have to send account IDs to everyone (with message-tags) indiscriminately, which would seem like a messy waste of bandwidth.
Enabling the cap should add something to the join message (I'm not massively fussed how, but I don't see any particular reason tags are better than parameters here) and account-notify. I think we probably don't need a WHOX flag to be predicated on any cap and can just add it.
I'd like wording that implementations SHOULD:
- provide account IDs in WHOIS for all clients, so users on legacy software can still see them
- provide some way to query account info by ID
- provide some way for a user to hide and/or change their ID
Changing ID would void the whole purpose of this, the idea is that account names can change, IDs cannot, ideally you would want to show them in WHO over WHOIS
If you want to change your ID ideally you would drop and recreate your account
I agree that to change your ID, you should be required to recreate your account. I think that might be non-normative though
I think it's fine to allow for functionality to "reset" your ID, given similar results can already be achieved given a drop-and-recreate sequence. There are two concerns with allowing this:
- Any special access associated with the old account ID will be lost. I don't think this can be avoided, given the goal of stopping tracking, unless we come up with a significantly more complex system than a simple ID displayed to everyone.
- Any "negative" access will also be lost, i.e. ignores/bans targeted against the old account ID. I feel that this is a reason a given implementation may decide against allowing an ID reset, but not necessarily for the specification to disallow such a thing in general.
Indeed, from the point of view of a third party, someone resetting their ID doesn't seem to differ much from the scenario where someone recreates their account and moves over any server-side configuration they had on the previous account.
I am not sure how a unique ID is any more "trackable" the anything else in services. An example is if someone changes there account name (for anonymity) I can easily check a channel (access|ban) list to see if they are in the same position that they previously were with a new account name. Allowing changing of account ID not only defeats the purpose of this but it encourages horrible privacy practices. Ideally if you want to change your identity you don't simply change account name, you will create a whole new account. The only way that this would make sense is to completely reset your account in services like it is a whole different account and wipe everything (vhosts, nick groups, channel access, etc etc etc) which would be out of the scope of IRCv3. This is the same as if you create an account on most any social media website, there is almost certainly some way to get a unique id that you cannot change.
@trobotham You raise a valid point: at which point it stops being "the same account" may be out of scope for the specification, and it's probably up to the implementation to decide if "resetting" your account (including channel access and any other such things) constitutes a new account. Indeed, it might offer such a command as simply a shortcut for registering a new account and moving over a few basic things such as your authentication credentials.
(Beyond that, however, being listed on an access list allows you to check if an account stayed the same in a given case; it's not quite the same as sending out a trackable ID with every message/join/etc by a given account, which I think is the issue people were more concerned about. There are privacy concerns about being able to check access lists and such as well, of course, but the ID allows for much easier automated tracking.)
I suggest that as long as we caveat "changing account IDs will make anything tied to your account ID invalid", we can leave the scenarios under which that can happen up to the implementors.
On the side of the specification, I'd suggest we:
- offer a
account-idcap - attach an
account-idmessage-tag toJOIN,ACCOUNT,PRIVMSG,NOTICE,TAGMSGetc (likeaccount-tag) when the above CAP is negotiated - expose account IDs through a WHOX flag, regardless of CAP negotiation
Having account ids that are changeable would allow bans based on them to be evadable and would defeat the point of having them (which is an issue with the current system and my main reason for being interested in this).
If people are that concerned about privacy they can make a new account or just not have an account.
@SaberUK it'd defeat one of the points of having them, the other being that if an account name is reused, third parties will apply the privileges they have recorded against that account name, even though there's potentially an entirely different person behind that name now.
If people are that concerned about privacy they can make a new account or just not have an account.
I'm not super happy with that approach at a specification level. If an implementation wants to provide a way to reset an identifier that could be leveraged for tracking, I'd say let it do that; the implications of that (including concerns about potential abuse) are then up to the implementation and possibly its users to work out.
That said, there's nothing stopping an implementation (or even most implementations) from taking your approach and keeping the ID static over the lifetime of the account. As @jesopo suggested, I'd recommend keeping the details up to the implementation.
What's the rationale behind adding yet another user identifier instead of just standardising on the existing account name? Account names are already in use and adding another ID just takes up more valuable line space.
If we want to make it known to clients that account names cannot be changed on a network, then either a warning/error can be shown if they do attempt to change it or a 005 token to indicate that they are static could be used.
because we might want to facilitate accounts as a source of authentication for third parties without making account names immutable?
@prawnsalad The issue is that account names can expire and be reused by other people, so assigning access based on them isn't very secure. Another issue is that usually, account names can be changed, which gets rid of both special access and sanctions associated with them by third parties, hence the idea of a non-human-readable unique ID that doesn't normally change and must not be reused.
@edk0 @ilbelkyr that's what I'm saying, we have account names already so we could just add an indicator that they cannot be changed - which hopefully would be the default option over time.
An ID or account name - either way works as some form of static ID is something I've needed for some time personally too, but at a protocol level it's weird that we would have:
- Nick - can be changed
- Account name - can be changed
- ID - static
The ID would be the exact same thing and used in the same way as the account name other than it being static.
I thought I was pretty clear that I didn't want to make account names immutable
edit: also I definitely don't want them to be reserved forever after they are used, whereas IDs used for authentication should be
@edk0 @ilbelkyr that's what I'm saying, we have account names already so we could just add an indicator that they cannot be changed - which hopefully would be the default option over time.
An ID or account name - either way works as some form of static ID is something I've needed for some time personally too, but at a protocol level it's weird that we would have:
- Nick - can be changed
- Account name - can be changed
- ID - static
Honestly it sounds quite normal to me. If the account name would just be user-facing but not used as an identifier. IRC wouldn't be the first protocol to do that.
Nick is short-term, easily changeable user-facing identity (like game character name); account is long-term but still easily changeable user-facing identity (like legal name); UID is permanent and only used on access lists.
Having 2 different user facing and changeable form of identifiers seems to be overcomplicating it all to me, but I'm not entirely against it.
Maybe, but it's what we already have, and there are good reasons to change one's account name, so if we can enable this use case without taking that away I think we ought to.
What other reasons are there for changing the account name other than not wanting to be tracked? As that's flawed since you can track users in other ways anyway, as others have mentioned above.
What other reasons are there for changing the account name other than not wanting to be tracked?
Having your deadname in the account name, but not wanting to lose access to the channels you own/op? Having created the accountname with 13 so it's now xXX_thebest_360_XXx and you now want a more serious one, but don't wanna lose access?
What other reasons are there for changing the account name other than not wanting to be tracked? As that's flawed since you can track users in other ways anyway, as others have mentioned above.
Simply, one just wants to go under a different name from now on. That's a thing.