Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec that AS virtual users & aliases should begin with a _ (SPEC-426) #689

Closed
matrixbot opened this issue Jul 14, 2016 · 11 comments
Closed
Labels
application services spec-omission implemented but not currently specified

Comments

@matrixbot
Copy link
Member

The current mechanism we use to ensure a clean namespacing split between "human" (i.e. real signup) accounts vs. ghosts of 3PUs (such as IRC or gitter bridge ghosts) is that ASes that define these bridges can reserve themselves an "exclusive" part of the namespace, thus preventing new user signups within that namespace.

Unfortunately, this mechanism doesn't prevent clashes between historical users who had signed up before that particular namespace exclusion was added. For example, the gitter bridge was only added about 2 months ago; so anyone could have signed up a real user account called @​gitter_anything:matrix.org before then. As we continue to gain more users and more bridges, the likelihood of a collision will increase.

Depending on how it's implemented, the potential issues of such a collusion could be:

  • The user loses control of their account
  • The AS is unable to puppet that account
  • Information leakage - Matrix users trying to contact the 3PU via their matrix ghost inadvertantly talk to the real human account.

We need a better fix for this than the current mechanism.

(Imported from https://matrix.org/jira/browse/SPEC-426)

(Reported by @leonerd)

@matrixbot
Copy link
Member Author

Jira watchers: @leonerd @richvdh

@matrixbot
Copy link
Member Author

matrixbot commented Jul 14, 2016

Links exported from Jira:

is duplicated by SPEC-436
relates to SYN-738

@matrixbot
Copy link
Member Author

An easy way we could stop this in future (at least) is that just because spec happens to allow some particular set of characters in user IDs, we could reserve a character (or a pattern) in common for all AS-hosted bridges, rather than just the ones we're using now and continue to add. That way, the pattern will be reserved for future ones we add too.

Unfortunately, while it would be nice to suggest we'll reserve any user ID with an underscore in it (and thus capturing the existing IRC, Slack and Gitter bridges), that won't work because many existing users have underscores, and also it would be nice to let users have names with underscores in.

One idea that might be nice is to forbid accounts whose ID start with some particular name pattern; for example starting with a dot or underscore; while still allowing that character somewhere else inside. It's quite likely no human would ever want a leading dot in their name (or if they do they won't be too upset to be told it's not allowed); so one easy solution might be to have 3PUs have names of the form @​.asname.3PUname-here:matrix.org for example. This still allows a real human to sign up an account of @​firstname.lastname:matrix.org if they so desire it.

At this point, the bug becomes more a suggestion in the spec of "Ohyes, so you might want to reserve something like this", and the real bug becomes one to point at existing homeserver implementations, to allow that sort of restriction.

-- @leonerd

@matrixbot
Copy link
Member Author

The idea of reserving mxids which start with a particular bit of punctuation sounds like an excellent idea. A spec PR to formalise it would be delightful :)

Do we need to consider potentially overlapping AS identifiers though? Can I have an AS which is registered as "gitter.snaffler" which will then scupper your chances as the real gitter bridge faced with user "snaffler"?

-- @richvdh

@matrixbot
Copy link
Member Author

This doesn't need to be a SPEC bug to formalise it further. Specifically, synapse could just have a bit of code saying "Ah, I see you're trying to create a username starting with . and you're not an AS, so no, go away 403"

We still want to consider how different ASes split themselves from each other, sure; but that's why they're namespaced by the HS admin anyway. This is just a future-proofing mechanism to ensure we can always add new ASes in namespaces guaranteed not to be taken by existing signed-up users.

-- @leonerd

@matrixbot
Copy link
Member Author

At current count, we have 16 users on matrix.org whose names begin with _ but no users beginning with .}}, so I think {{. is heavily in favour.

as per

matrix=# SELECT COUNT(name) FROM matrix.users WHERE matrix.users.name LIKE '@​.%';
 count 
~~--~~---
     0

matrix=# SELECT COUNT(name) FROM matrix.users WHERE matrix.users.name LIKE '@​\_%';
 count 
~~--~~---
    16

-- @leonerd

@matrixbot
Copy link
Member Author

did we go with _ in the end ?

-- @richvdh

@matrixbot
Copy link
Member Author

Yes. The new networks (IRC/OFTC, IRC/Snoonet, Slack) are using underscore-prefixed user IDs. Not a lot we can do that isn't very disruptive to existing IRC/Freenode, IRC/Mozilla or Gitter users though.

-- @leonerd

@matrixbot
Copy link
Member Author

matrixbot commented Sep 27, 2016

So is the work to be done for this bug just to recommend that HSes reserve the @_ namespace (and #_ ?) for ASes?

-- @richvdh

@matrixbot matrixbot changed the title Prevent signups from shadowing bridge ghosts Prevent signups from shadowing bridge ghosts (SPEC-426) Oct 31, 2016
@matrixbot matrixbot added the spec-bug Something which is in the spec, but is wrong label Nov 7, 2016
@richvdh richvdh added clarification An area where the spec could do with being more explicit and removed spec-bug Something which is in the spec, but is wrong labels Nov 7, 2016
@ara4n
Copy link
Member

ara4n commented Dec 11, 2016

yes, afaik.

@ara4n ara4n changed the title Prevent signups from shadowing bridge ghosts (SPEC-426) Spec that AS virtual users & aliases should begin with a _ (SPEC-426) Dec 11, 2016
@ara4n ara4n added spec-bug Something which is in the spec, but is wrong and removed clarification An area where the spec could do with being more explicit labels Dec 11, 2016
@richvdh richvdh added clarification An area where the spec could do with being more explicit spec-omission implemented but not currently specified and removed spec-omission implemented but not currently specified spec-bug Something which is in the spec, but is wrong clarification An area where the spec could do with being more explicit labels Oct 11, 2017
@turt2live
Copy link
Member

ftr, there was some lengthy discussion a long while ago that perhaps appservices should use . instead of _ as it's less intrusive. Not sure what the final say was though.

August 2018 r0 automation moved this from In review to Done (this list will be incomplete) Aug 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
application services spec-omission implemented but not currently specified
Projects
No open projects
August 2018 r0
  
Done (this list will be incomplete)
Development

No branches or pull requests

4 participants