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

Presence confidentiality #428

Open
MatMaul opened this issue Feb 11, 2019 · 4 comments
Open

Presence confidentiality #428

MatMaul opened this issue Feb 11, 2019 · 4 comments
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@MatMaul
Copy link

MatMaul commented Feb 11, 2019

Hi all,

So I just set up my server with presence tracking enabled. However presence tracking is sent to every people I share a room with, and I don't really like that.

I browsed the spec looking for details regarding that, there is a warning regarding this in the spec. However I can't see anything related to the fact that sending presence to all people you share a room with is mandatory.

Can anyone confirm that ?

I was thinking about implementing an option in synapse to NOT share presence with people I only share public rooms with them.

That should probably be an option handled by the client at some point in a later spec version, with some presence_list like mechanism to override the default behavior for a room/person.
I was thinking about writing a MSC for that.

Thoughts ?

@MatMaul
Copy link
Author

MatMaul commented Feb 11, 2019

My main concern here is that if it is mandatory per spec it blocks the implementation of a new client API endpoint/property that would still be compatible with 1.0.

@turt2live turt2live added clarification An area where the expected behaviour is understood, but the spec could do with being more explicit enhancement A suggestion for a relatively simple improvement to the protocol A-Client-Server Issues affecting the CS API labels Feb 11, 2019
@ara4n
Copy link
Member

ara4n commented Feb 12, 2019

agreed that we should provide a standard specified way for clients to tell servers not to relay presence information for them (whether or not the client is providing explicit presence info). An MSC for this would be great.

Meanwhile, presence_lists have been removed from the spec in matrix-org/matrix-spec-proposals#1819, but equivalent functionality will reappear in future. I'm not sure it helps your use case, though, which is for a client to say "please don't relay my presence to the general public"

@MatMaul
Copy link
Author

MatMaul commented Feb 12, 2019

Good so we are not stuck by a too-precise spec great :)

Presence list seems to have been designed so people can request presence from someone right ?

I think it is too complicated, if we have a user-handled list of forbidden and mandatory targets on top of a sensible default (nothing by default, or non-public rooms attendees by default) I don't think we need an invitation-like mechanism.

@richvdh richvdh removed the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Aug 2, 2021
@HarHarLinks
Copy link
Contributor

I think I have seen an issue on element github at some point that is about setting your own status manually, including "invisible" (appear offline, no presence) for privacy. Theoretically between 2 homeservers with enabled presence, anyone from a public room could create a online/offline profile of me, which I consider a substantial privacy problem. However presence is pretty nice with a couple trusted contacts. This may extend to "custom status messages" which I don't know are included with presence, but in principle all I mention here applies for them, too.

Most importantly, presence must be opt-in by the user! It is one of the most sensitive pieces of information on a user! It should only be "exploitable" when consciously opting in.

I would further like some ways to manage my online status for even more privacy. Particularly I would like to be "invisible" by default and then allow sharing my status with/based on

  • single contacts
  • everyone on certain homeservers
  • room members
  • space members
  • existing DM
  • existing e2ee conversation
  • verified (only fully verified/cross-signed?) contacts

Some scenarios that extend the implied by above list require the same flexibility to exempt ("superseding blocklist") users from these rules:

  • share presence with your "friends" space, but not your "work" space: which supersedes which for possible intersections? => need for explicit single contact management
  • share presence with your verified e2ee DMs, except your boss or members of your "work" space
  • different rich presence info for different scopes as mentioned in Per-room/space presence #873

Yes, these are fairly fine grained and also a lots of knobs to tweak.

  • upsides: detailed management, group scopes to ease management
  • downsides: it may become non-obvious whether a contact will or will not see my presence

UI suggestions based on element:

  • list of all rules in the client main privacy settings
  • show a toggle when viewing a single user's profile (right pane)
  • similarly in room overview pane
  • in room settings -> privacy, similar to url previews
  • on the space overview/explore page
  • right clicking anything in the room list/space panel

A related way I have thought about back when my server was to small and suffered from performance issues due to federated presence is a presence router module for synapse, that would accept a list of MXID regex to indicate what federated servers/users will receive presence updates. But I'm not too certain on how presence currently works, nor how to write a synapse plugin module. Homeservers should implement a mechanism that overrides the user setting such that only the intersection set is allowed. This will likely also alleviate performance issues: usefulness of sending presence to big public rooms is questionable imo and a default off would alleviate load unless you opt in.

I haven't dug into it yet, but I expect that presence is some kind of global user profile state, and not room state/timeline event or similar. That means that in principle a malicious homeserver that hosts one of my contacts whom I explicitly share presence with could share that with all of its users or the world. In principle, state could be hidden from homeservers by e2ee it, provided you send it only to contacts you share a e2ee DM with or similar.

Current workarounds: use different accounts for different purposes (possibly on different servers which have presence enabled or disabled). This is pretty bad, I haven't found a client yet which is mostly fully featured and also allows multiple accounts in the same window.

Imo it is pressing that at least default off in profiles with a toggle in client profile settings is implemented asap. A server should ignore presence updates if it is off.

I integrated the points made in matrix-org/matrix-spec-proposals#1221 (comment) which were missing from my original idea to create this comprehensive post.

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
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

5 participants