Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-03 17:54:14 +02:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Remove security considerations (moved to MSC3083).

Browse source
This commit is contained in:
Patrick Cloke 2021-05-12 10:14:02 -04:00 committed by Richard van der Hoff
parent 34f006ce8b
commit bf41af7c15
1 changed files with 1 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
proposals/3173-expose-stripped-state-events.md
View file

@ -84,7 +84,7 @@ include the following as stripped state events:
This also implies that the above information is available to any potential joiner This also implies that the above information is available to any potential joiner
in the API proposed in [MSC2946: Spaces summary](https://github.com/matrix-org/matrix-doc/pull/2946). in the API proposed in [MSC2946: Spaces summary](https://github.com/matrix-org/matrix-doc/pull/2946).
I.e. rooms which could be joined due to [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) E.g. rooms which could be joined due to [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083)
can expose the information available in stripped state events. can expose the information available in stripped state events.
## Potential issues ## Potential issues
@ -99,29 +99,6 @@ knocking.
## Security considerations ## Security considerations
The server-server API discussed in [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946)
does not know the user who is requesting a summary of the space, but should divulge
the above information if any member of a server could see it. It is up to the
calling server to properly filter this information.
Consider that Alice and Bob share a server; Alice is a member of a space, but Bob
is not. The remote server will not know whether the request is on behalf of Alice
or Bob (and hence whether it should share details of private rooms within that
space).
Trust is placed in the calling server: if there are any users on the calling
server in the correct space, that calling server has a right to know about the
rooms in that space and should return the relevant summaries, along with enough
information that the calling server can then do some filtering.
(The alternative, where the calling server sends the requesting `user_id`, and
the target server does the filtering, is unattractive because it rules out a
future world where the calling server can cache the result.)
This does not decrease security since a server could lie and make a request on
behalf of a user in the proper space to see the given information. I.e. the
calling server must be trusted anyway.
## Future extensions ## Future extensions
Dedicated client-server and server-server APIs could be added to request the Dedicated client-server and server-server APIs could be added to request the