❌ Software Removal | Element (Matrix)

[Mikaela]

Description

I think Element and Matrix should be delisted, or at least have heavy warnings added to them as currently I am unable to consider them as privacy friendly tools. The issues I list have been open for several years in the worst cases.

Why I am making the suggestion

• The defacto server implementation, Synapse, leaks per-room profiles when /myroomnick or /myroomavatar are used. This may result to anything between awkwarness, serious harm and death
  • User Directory leaks Per-room Nicknames and Avatars matrix-org/synapse#5677
• The defacto server implementation, Synapse, doesn't actually remove non-text content when the remove button is pressed in client. This may be a nasty surprise in case of posting and then removing sensitive material, especially in bridged rooms.
  • When we redact events, any mxc content they refer to should be redacted too (SYN-216) matrix-org/synapse#1263
• Self-destructing messages are implemented difficultly from user point of view, requiring advanced knowledge to enable and every Synapse instance in the room to enable a non-default option.

My connection with the software

I have been using Matrix daily since 2016, and it's important for me to stay in contact with a lot of people, same as XMPP, IRC, Signal, Telegram and WhatsApp. I have friends involveved in Matrix and IRC developments, but wouldn't consider myself affiliated with any of the three. I have additionally written a blog post about these issues and how Element iOS is very behind Element Web and Element Android.

• I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

[freddy-m]

You raise valid points. Interested in your thoughts on this @privacytools/editorial and @lynn-stephenson in particular.

[dngray]

It's unlikely to be removed for these things alone.

Regarding matrix-org/synapse#5677 I wouldn't depend purely on those features for anonymity/different personas. I do not believe they were designed with that threat model in mind. In any case your Matrix ID is the same, thus allowing for linking of identities anyway. For the usecase suggested I think we're really waiting on a nicer solution to element-hq/element-web#2320

Regarding matrix-org/synapse#1263 it's worth noting the next point as well. With bridged rooms there is no assurance the bridge will redact the message, (impossible for things like IRC). Users should not expect that messages are deleted because they demand so. Certain clients or loggers could be written to ignore these requests too.

Regarding self-destructing messages, that doesn't currently exist as a feature. It isn't one of our requirements either. The main reason for this is because it's a false sense of security, anyone can take a photo of their device or a screenshot and post it anyway. We see this with Twitter all the time when people delete tweets. Moral of the story is anything you post online is there forever.

[infinitewaveparticle]

I agree... There's no such thing as perfect privacy/anonymity or security. If you choose to communicate online in any form you're choosing to risk your communication being seen by anyone... And the more you use online services the more you risk your identity being known and linked to your communications/posts. We should strive to use the best services available, and for that reason we should include the best services available in privacytools, complete with caveats and notes so that users can choose what works best for them based on the available information for each service. Only serious/egregious/universal violations should be cause for removal.

[Mikaela]

It's unlikely to be removed for these things alone.

I am happy with getting a warning added as discussed in the dev room.

Regarding matrix-org/synapse#5677 I wouldn't depend purely on those features for anonymity/different personas. I do not believe they were designed with that threat model in mind. In any case your Matrix ID is the same, thus allowing for linking of identities anyway. For the usecase suggested I think we're really waiting on a nicer solution to element-hq/element-web#2320

If I recall correctly, the target audience of PrivacyTools used to be not-so-technical or privacy-minded users. You may notice the feature and treat it with suspicion for that reason, but I wonder if that would apply to someone new to thinking of privacy who was looking to replace Discord or Slack (I will be referring to those names a lot as they are mentioned above Element on the page as something to replace)? Discord implements similar feature in their guilds and while it does show your global ID to everyone, your nickname in a specific guild is not shown to people who aren't in that guild as far as I am aware of.

Regarding matrix-org/synapse#1263 it's worth noting the next point as well. With bridged rooms there is no assurance the bridge will redact the message, (impossible for things like IRC). Users should not expect that messages are deleted because they demand so. Certain clients or loggers could be written to ignore these requests too.

Perhaps PrivacyTools should mention this somewhere? I didn't see a mention on the page that removal is best-effort and I think this behaviour is contrary to that of Discord and Slack which also make bridges easier to detect (due to webhooks or labels), while I don't think Element particularly tells a new user that there is a bridge in the room, the most that happens is someone having a Matrix ID that begins with name of another protocol.

Regarding self-destructing messages, that doesn't currently exist as a feature.

I guess I am trying to see it too hard in room retention as it's becoming a common feature on some other platforms such as Signal, Telegram and even WhatsApp.

It isn't one of our requirements either.

Just to confirm the requirements are currently these?

• has end-to-end encryption.
• it's FOSS unless otherwise mentioned.

The main reason for this is because it's a false sense of security, anyone can take a photo of their device or a screenshot and post it anyway. We see this with Twitter all the time when people delete tweets. Moral of the story is anything you post online is there forever.

I think this could be a good subject for a blog post if not something more. My personal view is that self-destructing messages include an element of trust and actual people who aren't all adversaries and going to screenshot or log everything I say (while they are of course free to do that should they care as it cannot be prevented). Additionally I would highly recommend reading the original comment in Element Web issue tracker requesting actual self-destructing messages, https://github.com/vector-im/element-web/issues/2497#issue-184595152, it communicates the case for them better than I do.

[dngray]

If I recall correctly, the target audience of PrivacyTools used to be not-so-technical or privacy-minded users. You may notice the feature and treat it with suspicion for that reason, but I wonder if that would apply to someone new to thinking of privacy who was looking to replace Discord or Slack (I will be referring to those names a lot as they are mentioned above Element on the page as something to replace)? Discord implements similar feature in their guilds and while it does show your global ID to everyone, your nickname in a specific guild is not shown to people who aren't in that guild as far as I am aware of.

I think of the Matrix ID as your email address. /myroomnick is like changing the Reply-To.

Perhaps PrivacyTools should mention this somewhere? I didn't see a mention on the page that removal is best-effort and I think this behaviour is contrary to that of Discord and Slack which also make bridges easier to detect (due to webhooks or labels), while I don't think Element particularly tells a new user that there is a bridge in the room, the most that happens is someone having a Matrix ID that begins with name of another protocol.

Generally these rooms are public rooms anyway.

I'm kind of worried that if we start putting too many warnings the description will get too cluttered.

Just to confirm the requirements are currently these?

• has end-to-end encryption.
• it's FOSS unless otherwise mentioned.

In addition to:

• the E2EE being formally audited, and
• the server being open source.

We should at this point formalize that on the bottom of the page like we did for the VPN page.

I think this could be a good subject for a blog post if not something more. My personal view is that self-destructing messages include an element of trust and actual people who aren't all adversaries and going to screenshot or log everything I say (while they are of course free to do that should they care as it cannot be prevented). Additionally I would highly recommend reading the original comment in Element Web issue tracker requesting actual self-destructing messages, vector-im/element-web#2497 (comment), it communicates the case for them better than I do.

Indeed, and it might be worth mentioning. I hope when implemented they do give the option to disable it though for public rooms.

One of the major problems we had with Keybase and public rooms was people deleting every message too soon after typing it. It made for a very poor-quality room because you could only see one side of the conversation. Privacy advantages to doing this are minimal because you shouldn't be oversharing in a public room anyway.

[Mikaela]

What is the basis for closure? I am not seeing a fixing commit or reference from a new issue.