Skip to content
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

any user can currently query any other user's displayname and avatar over federation if they know their userid. (SPEC-374) #168

Closed
matrixbot opened this issue Mar 26, 2016 · 10 comments
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@matrixbot
Copy link
Member

Submitted by @​matthew:matrix.org
this seems needlessly leaky

(Imported from https://matrix.org/jira/browse/SPEC-374)

@matrixbot matrixbot changed the title any user can currently query any other user's displayname and avatar over federation if they know their userid. any user can currently query any other user's displayname and avatar over federation if they know their userid. (SPEC-374) Oct 31, 2016
@matrixbot matrixbot added spec-bug Something which is in the spec, but is wrong enhancement A suggestion for a relatively simple improvement to the protocol and removed spec-bug Something which is in the spec, but is wrong labels Nov 7, 2016
@CySlider
Copy link

CySlider commented Sep 7, 2017

I would like to add, that the spec should allow to specify a different avatar for each room you are in.
Also in RL you would not show up with a tuxedo at your local hangout or in shorts on a business meeting.

If done right, this would allow to not set any default avatar, but a cute (maybe publicly embarrassing) one in the encrypted family chat that is not public (best avatar is also encrypted) hence not giving away anything unnecessary to the public as the OP mentioned.

@non-Jedi
Copy link
Contributor

non-Jedi commented Sep 7, 2017

@CySlider spec currently allows per-room displaynames and avatars. It's just not a functionality exposed in Riot. (Avatars and displaynames are really just per-room state events that Riot pretends are user attributes rather than room attributes)

@CySlider
Copy link

CySlider commented Sep 7, 2017

@non-Jedi Perfect. Kinda missed that in my quick scan. Sorry for my ignorance. If I find some free time I'll see if I can create a pull request for Riot making use of this.

@CySlider
Copy link

CySlider commented Sep 7, 2017

Hmm, I checked the spec again and I can not see any API call to set a room specific avatar.
Yes, a room event can carry an avatar, but it's purpose seems to be to have a history of avatars to be able to always display the avatar that the user has had, when he did send a message.

The only way for the client to set an avatar seems to be:

 "8.3   PUT /_matrix/client/r0/profile/{userId}/avatar_url"

which clearly is not room aware.

Even if I send an room event with the intent to override the user's avatar with an m.room.member event.
the spec says "avatar_url string The avatar URL for this user, if any. This is added by the homeserver." Which suggests that this field is not supposed to be set by the client, but rather by the server with the current profile avatar.

I would suggest a call like:

  PUT /_matrix/client/r0/rooms/{roomId}/members/{userId}/avatar_url

Which overrides the default avatar for the user in that room.

UPDATE: PUT not GET

@leonerd
Copy link
Contributor

leonerd commented Sep 7, 2017

You can set a per-room avatar or displayname by just setting the values into your own m.room.member event.

@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Sep 6, 2018
@ara4n
Copy link
Member

ara4n commented Aug 14, 2019

matrix-org/synapse#5083 covers this for the CS API, but not SS API

@Bubu
Copy link

Bubu commented Apr 1, 2020

Today I learned about one org that is running their synapse without federation because of privacy concerns regarding this issue.

@Bubu
Copy link

Bubu commented Mar 4, 2021

This seems to be fixed in synapse by matrix-org/synapse#9203?

@dkasak
Copy link
Member

dkasak commented Jul 19, 2022

This seems to be fixed in synapse by matrix-org/synapse#9203?

Correct, this was handled on Synapse's side, but it's still not standardized in Matrix.

@Johennes
Copy link
Contributor

The behavior that was implemented in matrix-org/synapse#9203 has since been added to the spec through MSC3550. So I think this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

9 participants