❌ Software Removal | Element (Matrix) about privacytools.io HOT 6 CLOSED

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.

from privacytools.io.

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.

from privacytools.io.

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

from privacytools.io.

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.

from privacytools.io.

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.

from privacytools.io.

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

from privacytools.io.