Suggestion/discussion: E2E practicability in social rooms / missing "Enable URL previews by default" for E2E rooms setting and its impact

[ell1e]

Sorry that I am proposing this in such an essay, but I am expecting this to be somewhat controversial but it is somewhat important to me:

Currently, I feel like there is a somewhat notable incentive to never enable E2E for any social non-super-private rooms if non-techies are in it. That makes me sad, I want encryption to be everywhere where it is practical, and it feels like here it could also be with minor changes.

The reason social hangouts clash with E2E is that the link preview will automatically be broken with "Enable URL previews by default for participants in this room" unavailable/forced off. And I get that it'd default to Off, but it being entirely unchangeable for room admins poses a problem: some rooms are just fun social hang outs, and if regular users (like, imagine WhatsApp crowd coming over, and shouldn't that be great?) need to poke in the settings for such a basic feature, some users will likely just move on. And you can blame or not blame them for that, but the result is that it makes an E2E setup way less practical for more casual non-techie social rooms.

And here I get you could argue why even enable E2E then? Also, wouldn't letting room admins mess with this default risk security-conscious people unintentionally exposing themselves to a spying homeserver? Obviously it's a trade-off, but maybe think of it like this: it's still more secure to have an E2E room where link previews are enabled for regular unaware users by default (which they can still opt-out of!) than to have an unencrypted room entirely. And if gif previews are always, unchangeably opt-in even for fun social rooms, the truth is just many of these places won't enable E2E which is a total loss of security in numbers. It turns enabling E2E for a room admin from a no-brainer (outside of corner cases like bridges) to a difficult decision in some cases.

I am therefore proposing the following combined changes for discussion to balance this difficult situation:

• Step 1: Reintroduce Enable URL previews by default for participants in this room for room admins of encrypted rooms, but default it to off
• Step 2: Introduce a new user setting Override URL preview in encrypted rooms to off, no matter the room's default that defaults to off

And yes, I realize more settings is bad, and some people will miss both the per-channel opt-out and the new global opt-out and have links leaked when they thought they wouldn't be. I do realize many security hardliners will not like this. But I hope that you find it worth at least debating, in a possible future where hopefully E2E can reach everyone and their families, and security-conscious people can still find themselves at least somewhat sufficiently empowered to deviate and override to the defaults they want if they don't like how things are set by default. And I agree this isn't ideal, but neither does the current situation seem to be.

I am looking forward to your input!

[ell1e]

I just got some additional input for this from another user: it made me realize that essentially, Show previews/thumbnails for images in the settings would to my understanding currently turn ineffective if all rooms move to E2E, which seems possibly counter-intuitive for newcomers. With my proposed change, it would retain meaning in places where room admins decide that given the room's target audience, it's appropriate and sensible that link previews stay enabled by default (with opt-out always still available, including the new global setting I am suggesting). I just felt like that might be one additional thought that could help when considering this.

[ell1e]

Fwiw, I made some protocol change suggestions to help with this: vector-im/element-meta#288 specifically to move the link preview generation from the home server to the sender client (such that receiver clients cannot be tricked into contacting rogue IP collecting servers), either only for E2E rooms or in general. I figured I'd just note this here since it seems like the matrix-central issue will remain closed in favor of this one, just so that this suggestion doesn't get lost. I think with this suggestion it might be possible to not only allow E2E rooms to opt-in to making link preview enabled by default for everyone who joins, but to actually make it the default as with all other rooms for more consistency. (But that's just my opinion of course, further input and discussion would be very appreciated.) Ideally, other clients would be convinced to pick up whatever solution is found here to get somewhere somewhat consistent, making this less of an element-specific thing in the longer run.

[Victor239]

I think you meant to link https://github.com/vector-im/element-meta/issues/1139 as the suggestion regarding moving URL preview to sender-side rather than relinking to this same issue.

Notably this is how Signal generates URL previews too.

[t3chguy]

The issue with url preview generation at sending client is it aids phishing.

[ell1e]

It does, but so does in general the ability to send URLs. If your URL is malicious to start with you can make it present any sort of preview you want in any case. If it's trustworthy then I'm not sure what presenting it with a misleading preview would achieve. (Tricking people to click a mostly harmless site?) So it seems like a smaller concern in comparison in my eyes, but I can see how you would find that debatable.

[HarHarLinks]

• https://github.com/vector-im/element-android/issues/3038: "[room] Administrators get to decide if the users of a room can individually enable/disable URL-Previews for their client. (defaulting to: disabled each)"
  • https://github.com/vector-im/element-android/issues/2555
  • https://github.com/vector-im/element-meta/issues/1138: receiver client side preview generation for e2ee
  • https://github.com/vector-im/element-meta/issues/1139: sender client side preview generation for e2ee

[whiterock]

Is anything being done about this still?

[ajkessel]

There are quite a few disparate issues on this topic. Is there one master issue? Any chance this will be worked on? Many of us really want url preview in e2ee rooms notwithstanding the security impact but there does not appear to be any way to configure that currently.

[exercismnow]

I'm wary of allowing Matrix homeservers to access URLs in e2ee rooms. If our ambition is to encourage the widespread/distributed use of Matrix, some homeservers will be in unfriendly jurisdictions.

Scenario where homeservers being able to view URLs can cause trouble:

• A girl lives in a state where abortion is illegal
• She registers on a matrix homeserver in that state
• She sends a link to https://www.plannedparenthood.org/ in what she believes is a private, e2ee room
• The server generates the URL preview, and thus knows that this girl has sent a link to https://www.plannedparenthood.org/
• The server administrator may be legally bound to report the girl to state police for suspected intent to commit abortion

I think ell1e's suggestion to generate URL previews on the sender client's side is best, at least for e2ee rooms.

When the sender sends a URL, they've most likely already viewed the URL to get an idea of what they're sending. So they've already exposed their IP to the website. Or, if the sender's using a VPN or Tor, the website will have neither the sender's nor the receiver's URL, unless the receiver clicks the link.

URL preview generation can aid phishing, but this can be mitigated. Also,if the sender controls the malicious website, they can already make the preview appear however they want, regardless of what Element does.

---

Reasonable compromise to respect privacy and mitigate phishing:

• URL previews are generated by the server for public / non-e2ee rooms
• URL previews are generated by the sender client for e2ee rooms (e2ee rooms are a less attractive target for phishers, since the largest/juiciest rooms are not e2ee)
• Room admins can disable URL previews for all room participants (e.g. if this is a high-security room that wants to mitigate phishing)
• Users can choose to disable viewing URL previews, regardless of who generated them (account-wide or room-specific setting)

This way, receivers are never forced to preview URLs, and the Matrix server never sees URLs in e2ee rooms.

---

Potential workflow to mitigate phishing from strangers who DM you randomly:

• Stranger invites you to DM
• You accept the stranger's invite to DM
• After you enter the DM room, Element can display a persistent warning above the message composer that says something like "Do you trust this person? If not, URL-previews are disabled by default to prevent phishing"
• If you believe you won't be phished, click yes, and the persistent warning above the message composer goes away. And then URL previews are enabled

This way, you can view the stranger's text messages to satisfy your curiosity, while also not being misled by potentially modified URL previews until you consciously turn them on.

Optionally: If you initiate the DM, then the warning message is not shown, and URL-previews are enabled by default, since you knew the risks going in.

---

Alternatively, another compromise is to handle URL-previews the way Signal current handles them: https://signal.org/blog/giphy-experiment/ https://signal.org/blog/i-link-therefore-i-am/

My understanding is that, when Signal generates the URL preview for the 1st link, it can see https://signal.org, but not the full URL https://signal.org/blog/giphy-experiment/.

This is still a privacy issue for websites where even accessing the website itself can generate suspicion (https://www.plannedparenthood.org/ or https://www.pornhub.com/)