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

[WIPish] MSC1777: peeking over federation #1777

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@ara4n
Copy link
Member

ara4n commented Jan 6, 2019

Rendered


## Solution

If a client asks to peek into a room which its server is nor currently joined

This comment has been minimized.

@turt2live

turt2live Jan 7, 2019

Member
Suggested change Beta
If a client asks to peek into a room which its server is nor currently joined
If a client asks to peek into a room which its server is not currently joined
to, the server should attempt to join the room using a pseudouser account which
represents the server itself.

This allows the server to participate in the room and peek the data being

This comment has been minimized.

@turt2live

turt2live Jan 7, 2019

Member

Should the special user be allowed to post anything in the room? Because they'd be joined and hidden from the memberlist, it opens up a vector for abuse which is difficult to mitigate. Enforcing that the special case user is read only (with the exception of join and leave explicitly) would prevent most forms of abuse.


This replaces the `world_readable` setting on `m.room.history_visibility`.

XXX: Presumably this requires a room version upgrade.

This comment has been minimized.

@turt2live

turt2live Jan 7, 2019

Member

Most definitely. It might be worth the extra effort to split out this particular change into a dedicated proposal so it can make it in to v2, leaving the specifics of how peeking work to this proposal. Only real reason would be we're cutting rooms v2 at the end of the month, and it'd be a bit annoying to have a v3 very shortly after (particularly if the change is just peeking - that's not a lot of motivation to update rooms, particularly when compared to v2's changelog).

which could be a DoS vector. If a user creates a peekable room, and invites a
remote user in, it's now possible for that server to join via their pseudouser
in order to (say) participate in E2E... even if the user themselves hasn't
acted on the invitation. Care must be taken in being lured into peekable rooms.

This comment has been minimized.

@turt2live

turt2live Jan 7, 2019

Member

If we're bumping the room version, might as well enforce the user being effectively read-only at the same time.

This comment has been minimized.

@Half-Shot

Half-Shot Jan 9, 2019

Contributor

I assume this would break Pseudousers could potentially also act on behalf of ASes since that would requite the user to write into the room?

@anoadragon453 anoadragon453 added proposal and removed proposal labels Jan 8, 2019

`m.room.join_rules` is extended with a new type: `peekable`, which describes
public-joinable rooms which may also be joined by `@:server` pseudousers.
Otherwise, server pseudousers must not be allowed to join the room, unless a
user from that server has already joined or been invited.

This comment has been minimized.

@Half-Shot

Half-Shot Jan 9, 2019

Contributor

What happens to pseudousers if the join_rules become more restrictive after they have joined it. Does it work like current room semantics and keeps them joined, keeping the room peekable for servers who have peeked it once already?

(i.e I can see the situation where lots of servers peek your room, you downgrade from peekable and are surprised to learn it doesn't help you.)

@Half-Shot
Copy link
Contributor

Half-Shot left a comment

This looks largely fine and elegant aside from one edge case I'm concerned about 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment