This is a brief overview of authorization.

The server authorizes all instantiation messages. If a user is not authorized, instantiation messages from them will not be sent to peers.
For update messages, the client authorizes and filters. Authorization is two stage:
- First, we check if a message is affirmatively authorized, meaning that it is explicitly allowed by policy. This check happens in authorizeEntityManipulation in permissions-utils.js.
- If that check fails, then the message is sanitized, which to strips it down to just a specific, optional subset component attributes which do not require authorization.
  - These components are defined as nonAuthorizedComponents in network-schemas.js
  - The reason for this component whitelist is dictated by use case. For example, we allow anyone in the room currently to manipulate the video playback state or pager state on media, because to lock that down otherwise would mean that scene-owned assets would never be controllable by users.

One confusing bit is for videos:

For unpinned videos, all actions are both authorized and visible in the UI regardless of permissions
For pinned videos:
- Play/pause are unauthorized for members without pin permission, because that would impact the pin state
- Seeking is always authorized, because to do otherwise would prevent an arbitrary timekeeper
- However, by convention, we disable the seeking controls (after https://github.com/mozilla/hubs/pull/2064) to make pinning effectively be a soft contract that discouages seeking by non-privileged users

Similarly, PDFs will be permitted to be paged by anyone if unpinned, but not pagable if pinned by members without pin permissions.

Hubs User Guides

Hubs Design Documents