Room Access Controls

[gfodor]

Here’s a short write-up about proposed access controls for rooms.

Currently rooms are accessible to anyone who has the link. The only exception are bound rooms, which are only possible to create via our discord integration. (Which incidentally will not be available initially to Hubs Cloud instances.)

There are a variety of use-cases where people need to be able to have finer grained control over who has access to a room. Some examples are below in the “Use-Cases” section.

Within this, there is the need to also control who has access to the lobby vs room entry.

New Room Access Control Settings

Here are the proposed new settings I think we should add for un-bound rooms, under a Access Control tab in the Room Settings dialog:

• Room Access

  • Public: Public rooms will be visible on the homepage.
    • By default, only admins can set rooms to public. Additionally, there is a site-wide config admins can enable to allow anyone to make their room public.
  • Private (default): The current model, where anyone with the link can join.
  • Invite-only: A more privacy-focused model, where the room creator can generate invite links, which have a limited number of uses and an expiration time. (Similar to Discord.) Visitors who have not accessed the room via the invite link (which will flip a bit in their local storage + account) will be denied access.

• Room Entry

  • Open (default): Anyone with access to the room, can enter the room.
  • Invite-only: Only those given invite links can enter the room.

The UI which lets you create invite links will have the following options:

• Expiration
• Number of uses
• Permissions:
  • Recipient can enter the lobby
  • Recipient can enter the room
  • Recipient is promoted to moderator role

Additional Options

The following additional options seem like a good idea to add to fully enable a variety of audience-centric use cases:

• Enable/disable chat from the lobby
• Enable/disable ability for full fly mode controls from the lobby
• When in spectator mode, ability to enter VR mode and fly around if flying is enabled

Other concepts

Other concepts which were suggested that seem less critical relative to the above:

• Password-based access control
  • Seems less useful and harder to use vs expiring secret invite links
• Email whitelists
  • Invite links seem better, and less brittle since often email addresses are easy to mistype, often unknown, or not the preferred method for contacting someone.
• Additional new binding contexts (eg Twitter)
  • Seems complex insofar as these do not mirror discord semantics. Twitter’s asymmetric links for example are a unique structure vs the symmetric, closed network of Discord. However, expanding our binding targets to similar platforms like Slack and Matrix still seem like a great idea.

Use-cases

The following use cases show how these configuration options can be tweaked

• I am hosting a highly private gathering and want more certainty that unauthorized visitors will not get access due to a URL leak

  • Room Access: Invite-only, Room Entry: Open (invite-only entry is meaningless here)

• A bad actor has entered a previously public room and I’d like to lock it down

  • Flip Room Access and Room Entry to invite-only, and kick the person. Share the invite link in the chat with others who are in the room. Subsequent access will require invite links.

• I am running an event with VIPs in the room and want a large passive audience who can spectate

  • Room Access: Public or Private, Entry Access: Invite-only. Disable lobby chat, enable lobby locomotion. Send invite links to the VIPs.

• I am planning an event or gathering and have a few moderators who I want to be sure have moderation controls

  • Previously, you’d promote them in-room. Under this model, you can send them via email an invite link which will let them promote themselves beforehand

Follow-up features

Beyond this, there may be a need once these are implemented to further enable the various ‘large audience’ use cases:

• Ability to “knock” to be permitted to enter the room by a room owner/moderator, live
• Ability to temporarily grant access to the room for a short duration (for Q&A, etc)

[bpeiris (Brian Peiris)]

• Can you revoke an invite link after you’ve created it? This is important if an invite link has been leaked.
• Can you set an infinite expiration and infinite number of uses on an invite link?
• Can you mutate the options on an invite link after it has been created?
• Can you label invite links for future reference?
• How are invite links tied to Hubs accounts? Can you be granted moderator permissions without a Hubs account? Do you have to sign in to Hubs first, before/after using a moderator invite link?
• Mixing moderator permissions into invite links seems like it could lead to a dangerous game of “did I copy/paste the right link in the right place”, especially if the link contains a long unreadable secret. Maybe we should make the link it self easily identifiable as a MODERATOR link.

Advantages of other approaches:

• Depending on how complex your invite link secrets will be, passwords are often relatively easy to type, which means that I would be able to switch devices more easily without having to transfer a long link between them through some other channel.
• In some cases (conference or event, with well-known participants) you already have emails of people you want to add to a room as attendees or moderators. In which case it would be much easier to take advantage of our existing email login system to add a whitelist. In comparison, invite links require a back-and-forth between room creator and participants, whereas an email whitelist would be asynchronous and can be setup well ahead of time. With invite links, you would have to ask attendees to go fish for invite links in whatever communication channel you chose to share them, vs just logging in with their email.
• You mention Twitter as a binding context, but you could also just see it as a login mechanism – where the only thing we do with Twitter or Google Accounts integration is we grab your email address and then everything else is the same from there – this is also an advantage of using email whitelists.

[gfodor]

In general, I was not imagining this UX having a “management” flow where you can list invite links, revoke them, etc. I think thats probably the high order bit for some of your concerns, is if we want to introduce that level of complexity to the way these links are created and managed. I was imagining a simpler approch where there’s just a create-a-link flow and then the link lives forever in the way it was created, and after you’re done with that flow, no user-facing functionality re-surfaces that link.

• I think we could make a “revoke all invites” button as a failsafe in the case of an individual link getting leaked.
• wrt accounts, I was imagining us doing a thing similar to what we do for room ownership, where we keep a record in local storage you accrued rights pre-emptively, and then if/when you log in, those rights are transferred to your account.
• the moderator link concern seems right, we might want to just punt on this aspect of this if we thought it was a bad idea. in previous discussions, i think there was concensus we wanted an async mechanic, which is why i layered it on here

with regards to email, there are a few things that i think are somewhat problematic with using emails that i can list (though not necessarily showstoppers)

• currently, the use of email addresses in hubs is, fundamentally, an authentication method, not a user identifier. so any place where we introduce email to identify users is a big step into how people identify each other in the product, and one we might have to live with if we build features around it
• practically speaking, there’s no guarantee that the email address you have for someone will be the correct email address, since they may have used a different email address (or an +alias, etc) for their hubs account. so my guess is that this will be somewhat error prone. also, we would not be able to do any kind of smart case-insensitivty or matching easily, since we do not store the email address. and the failure here is pretty bad. ie, something like 1-2% of your email list gets no emails or their accounts are not updated to give them access, and there’s no discernible way for you to know if it was a system error or due to a mismatch between their account email and the email you had.
• in general, i’m a bit nervous about just more places where emails are transmitted to our server. in this case, emails would have to hit our backend, be hashed, and then compared against hashes in the db. we’d then have to either send a bunch of emails (presumably batching them) or update account information. overall, having a setup where an individual can provide a set of inputs and cause those kinds of side effects on other people/accounts/email addresses seems like a relatively risky change, vs one where there is no possibility of such side effects.

[gfodor]

also one more aspect of links vs emails. if we had to choose between the two, from a user’s perspective links (or passwords I suppose) are much more versatile vs emails, though potentially more cumbersome in the specific case you mention where email is clearly easiest to work with if you have such a list (mod the issue I mentioned where some % will be wrong, which I think probably is a legit problem.)

ie, you may have some emails, but also a few people on twitter whose emails you don’t have. or you may be coordinating via a messaging app like slack, where you have nobody’s emails. so it seems to me that an email-agnostic approch is strictly necessary, and if we were to take an approach where we wanted to optimize the “email list” case, that would almost certainly need to be a supplementary feature, not the core mechanic due to its limitations.

[bpeiris (Brian Peiris)]

Fair points about the concerns around handling emails. I agree that it should be a supplementary feature, in addition to invite links.

I was actually thinking of a simple approach to a whitelist, where we just store the list with the room and then check accounts against the list on entry, instead of sending emails out or mutating accounts. But now that I think of it, we would have to store the whitelist of emails in the clear (or encrypted), in order to display them back to the room creator for editing, so that’s not great.

[gfodor]

Ah yep. I think any whitelisting we do seems to require that the account id resolution step happens at whitelist creation/modification time, to prevent the need from storing the identifying information, if we want to maintain our current contracts around PII etc.

[gfodor]

Ofc, you could theoretically let the user know at submission time if any of the email addresses are invalid, but this would be a potential security hole since it would allow an attacker to bulk search for valid email addresses in our database. It’s somewhat less of a concern for us vs sites that use email/password for authentication, and also could be mitigated somewhat by rate limiting, but it probably isn’t worth opening that door unless we have to.

[bpeiris (Brian Peiris)]

Regarding moderator invites. I would prefer having an async mechanism vs not having one at all. Accidental moderator invite leaks are still a concern, but I think a good compromise is to identify them in the link.
Like https://hub.link/invite-moderator/<secret>