[accounts] expose indefinitely unique and unchanging account IDs

[jesopo]

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.

[jesopo]

Existing software

Spoke to @ilbelkyr and Atheme already internally stores a unique ID per account. Not sure about Anope currently but will query them.

[justjanne]

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.

[jesopo]

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.

[SadieCat]

:+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.

[jesopo]

Knowing a user's account ID before they speak might be useful

[SadieCat]

How does having an account id tag on their join message like with the account tag currently not accomplish that?

[jesopo]

• extended-join -> shows us account when they signed in before joining
• account-notify -> shows us their account when they sign in after joining
• WHOX -> 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.

[genius3000]

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 , same for messaging users, etc.

[jesopo]

the ID really ought to be opaque

[RyanSquared]

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.

[edk0]

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:

1. provide account IDs in WHOIS for all clients, so users on legacy software can still see them
2. provide some way to query account info by ID
3. provide some way for a user to hide and/or change their ID

[trobotham]

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

[jesopo]

I agree that to change your ID, you should be required to recreate your account. I think that might be non-normative though

[ilbelkyr]

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.

[trobotham]

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.

[ilbelkyr]

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

[jesopo]

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-id cap
• attach an account-id message-tag to JOIN, ACCOUNT, PRIVMSG, NOTICE, TAGMSG etc (like account-tag) when the above CAP is negotiated
• expose account IDs through a WHOX flag, regardless of CAP negotiation

[SadieCat]

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.

[ilbelkyr]

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

[prawnsalad]

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.

[edk0]

because we might want to facilitate accounts as a source of authentication for third parties without making account names immutable?

[ilbelkyr]

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

[prawnsalad]

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

[edk0]

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

[grawity]

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

[prawnsalad]

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.

[edk0]

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.

[prawnsalad]

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.

[justjanne]

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?

[grawity]

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.

[justjanne]

So, we can conclude the discussion of the past hour:

1. Account names should remain changeable, we've presented realistic user stories for why they might want to change them.
2. We need a static identifier which is standardized and easily globally available, allowing to uniquely identify an account, even if all other attributes about the account change.

This brings us back to the questions we had before:

1. Should there be a way to reset the account identifier, and what should this mean? Should this also reset all access the account has, so the ACL a bot and the server store don't de-sync?
2. Should this account identifier be always visible, or should users be able to turn it off/on with a user mode? (And if so, how do we tell bots that on this server, account ids are optional?)

[SadieCat]

If the account identifier is not immutable then its essentially worthless and no different to the account name.

If the account identifier is not always visible then its essentially worthless because if someone wanted to e.g. avoid being account banned they'd just hide it.

I can't see us implementing either of these things unless it was absolutely required by the spec.

[justjanne]

If the account identifier is not always visible then its essentially worthless because if someone wanted to e.g. avoid being account banned they'd just hide it.

That's an obvious issue, but we had previously a discussion, e.g. channels might make it mandatory to have visible account names for people joining, or bots might require everyone on the ACL to have it visible. Similar to today's +r channels.

[prawnsalad]

Just to second @SaberUK comment. A form of account ID where its purpose is to be used by other services but can be changed or be hidden makes it pointless in most cases.

[trobotham]

Agreed, there is no valid reason to allow hiding account id, if a vendor chooses to do this that is there prerogative (they likely should not implement account id at all) and this should be implementation specific not spec

[justjanne]

On a previous discussion, people worried about being able to be tracked, which is why I included this question here.

Personally, I'd also love unique eternal account ids, mostly to improve right-click menus on historic backlog in our client as well as automated query merging if a user changed their nick.

[ilbelkyr]

@SaberUK wrote:

I can't see us implementing either of these things [mutability, ability to hide the ID] unless it was absolutely required by the spec.

That's absolutely fine with me; I wouldn't want the spec to require either of these, I just don't want it to forbid them, either. If the majority of implementations, or even all of them, decide to keep IDs static and visible, that is perfectly fine. What I'm opposed to is merely trying to make this decision via the specification, rather than letting the implementation decide.

@prawnsalad wrote:

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.

I'm not a fan of the proposed outcome either, but nicks being a (user-facing, mutable) way to address a single connection and account names being a (user-facing, mutable) way to address a registered, well, account is the situation we ended up with, and I don't think there's a way to avoid introducing a third kind of ID if we want to preserve the existing semantics.

[trobotham]

We’ve established that there are several other ways to track people on irc and services, setting some sort of privacy expectation under those pretenses is dangerous and enables a false sense of privacy

[edk0]

hiding (or changing) the ID doesn't make it less useful for anything except bans, which I'm not convinced that this spec should be very concerned with anyway—IRCv3 isn't generally.

I don't think the existence of other ways to track users should taken as justification to add more. We can aim to improve the situation incrementally.

[ilbelkyr]

We’ve established that there are several other ways to track people on irc and services, setting some sort of privacy expectation under those pretenses is dangerous and enables a false sense of privacy

I'm mainly concerned about automated tracking of entire userbases – I do realize that tracking individuals is a much harder problem to solve. Giving everyone a unique account identifier they can't change feels like it would very much offer potential to be abused for that, and while there are benefits to it as well, it's quite reasonable to be concerned about this.

[GIJack]

This needs to be the center of IRCv3 and one of the major pain points. Right now where are seperate accounts for i/p lines for connecting users o lines for operators nickserv accounts. nicknames held by the server.

What is needed is a unified accounting system. A person registers a nickname, centrally, and it is theres, the network/server remembers that. Everything else, such as oper status is just a flag on their stored profile in a database.

Also throw in the usual app passwords/API keys for things like phone/desktop/bouncers to be saved to avoid saving password to devices, and can be revoked.

[prdes]

This is blocking some pretty good client/bot interactions. Can we please get rid of the inability to trust in an account?

It allows for reliable ACLs with bot frameworks. Also, modern clients can take advantage of this to create user interfaces which reflect your permissions and the ability to do a lot with them on the fly. There are no other chat platforms with the type of bot interactions possible here and that can only be enhanced by this.

I am curious about the kind of mass tracking that is being prevented by stalling this.

Edit: I am aware of https://github.com/ircv3/ircv3-specifications/issues/402