You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In all cases exceptworld_readable, a user needs to join a room to view events in that room.
It goes on to say:
world_readable - All events while this is the m.room.history_visibility value may be shared by any participating homeserver with anyone, regardless of whether they have ever joined the room.
Exhibited Behavior
Synapse denies world_readable information by imposing a condition which checks if the requesting server has at least one user joined to the room. It responds with the error:
403 Forbidden
{"errcode":"M_FORBIDDEN","error":"Host not in room."}
This is not world_readable as specified. This check occurs on all relevant federation endpoints, making it impossible to access information about a room without joining at least one user. This exhibits a shared rather than world_readable visibility.
Proper Behavior
Synapse should not care whether a requesting server is joined to a room when it attempts to elicit information for events covered by a world_readable visibility state.
Conclusion
As the reference implementation for the specification, this is a problem. Either this is an implementation error by synapse or this is an omission by the written specification. Should server implementations follow suit with synapse de facto or should they follow the specification de jure in contrast with it?
Furthermore, if this condition was implemented to mitigate a security vulnerability, spam or DoS vector, or even a performance problem: other implementations will surely fall victim to it, and the specification should not blindly lead them into doing so. In contrast, if a server developer believes the preceding statement might be true because this discrepancy merely exists, when it is not true, they will degrade the functionality of their server for no reason.
The text was updated successfully, but these errors were encountered:
This issue has been migrated from #4236.
The specification states in 13.12
It goes on to say:
Exhibited Behavior
Synapse denies
world_readable
information by imposing a condition which checks if the requesting server has at least one user joined to the room. It responds with the error:This is not
world_readable
as specified. This check occurs on all relevant federation endpoints, making it impossible to access information about a room without joining at least one user. This exhibits ashared
rather thanworld_readable
visibility.Proper Behavior
Synapse should not care whether a requesting server is joined to a room when it attempts to elicit information for events covered by a
world_readable
visibility state.Conclusion
As the reference implementation for the specification, this is a problem. Either this is an implementation error by synapse or this is an omission by the written specification. Should server implementations follow suit with synapse de facto or should they follow the specification de jure in contrast with it?
Furthermore, if this condition was implemented to mitigate a security vulnerability, spam or DoS vector, or even a performance problem: other implementations will surely fall victim to it, and the specification should not blindly lead them into doing so. In contrast, if a server developer believes the preceding statement might be true because this discrepancy merely exists, when it is not true, they will degrade the functionality of their server for no reason.
The text was updated successfully, but these errors were encountered: