Increase transparency of rooms with shared history visibility

[nadonomy]

Your use case

What would you like to do?

Public rooms on Matrix, with history visibility set to 'anyone', are public the same way public web pages on the internet are public. They may be archived or made available online, and made discoverable by search engines, e.g. by view.matrix.org.

We should increase transparency on this, so people are aware of this when participating in public discussions.

Why would you like to it?

To increase transparency on this in all cases, even if we also extend support to disallow such things in future.

How would you like to achieve it?

Ideas/thoughts:

1. Don't add any cognitive load to creating a room.
2. Expose micro copy contextually in room settings, in history visibility / anyone selection.
3. Sense is that something persistent or perceived to be a warning would be needlessly alarmist. Is there something we could show ephemerally (e.g. when joining a public room, flash a message in place of room topic) or perhaps heavily deemphasised in the info architecture more generally.
4. Expand 'Public room' micro copy/tooltips when hovering on icons when history visibility is set to anyone.

While exploring, we should propose cross-platform designs which include iOS & Android.

Have you considered any alternatives?

No response

Additional context

More context. (Internal link only).

[t3chguy]

There's a bit of confusion here, Public does not mean World Readable.

and made discoverable by search engines, e.g. by view.matrix.org.

This is only possible if the room is set to History Visibility Anyone

Otherwise the room would need to be joined, and the spider/bot could be moderated.

[nadonomy]

@t3chguy thanks for expanding.

@niquewoodhouse I tweaked the original issue based on the latest comment.

[niquewoodhouse]

My suggestion is something like this:

When trying to add first message to the room since setting 'active'

It seems to me that this is important messaging to understand when you try to send something into the room, eg attach something, type something.

ele-public-rooms-first-msg-web-01.mp4

On iOS (as another example) this would be like:

ele-public-rooms-first-msg-ios-01.mp4

I explored the other things suggested in the OP below:

Don't add any cognitive load to creating a room.

(Tested on web) Creating a public room doesn't set History visibility to Anyone, so this probably isn't relevant here. I'm guessing each homeserver might configure this differently (so maybe for someone creating a public room does set History visibility to Anyone) but I'll wait for someone knowledgeable to confirm that.

Expose microcopy contextually in room settings, in history visibility / anyone selection.

We could use the pre-existing (brackets) styling on web to explain what Anyone means in practice:

ele-public-rooms-settings-web-01.mp4

Sense is that something persistent or perceived to be a warning would be needlessly alarmist. Is there something we could show ephemerally (e.g. when joining a public room, flash a message in place of room topic) or perhaps heavily deemphasised in the info architecture more generally.

+1. I think having someone just when joining isn't enough, as you could join any and someone later changes the settings to let anyone see history. But we could use the same thing when you next visit the room.

Modal that blocks progress:

• Would work for joining the room, and visiting the room if its been changed
• Would block user from interacting with room

ele-public-rooms-settings-change-web-01.mp4

When trying to add first message to the room since setting 'active'

It seems to me that this is important messaging to understand when you try to send something into the room, eg attach something, type something.

ele-public-rooms-first-msg-web-01.mp4

Expand 'Public room' micro copy/tooltips when hovering on icons when history visibility is set to anyone.

I think this might be confusing in practice. You'd have rooms with the same visuals meaning different things. A user might hover over the icon on one room, read the content, and then assume that's what it always means.

ele-public-rooms-tooltip-01.mp4

[nadonomy]

@niquewoodhouse thanks for exploring. Splitting up feedback by interaction:

Settings

• Like!

Modals

• My initial thoughts were that this is quite abrasive. But, I think actually if we iterate on the copy to be a bit more terse (we can pair on this together) I think this solution is really elegant, especially on the mobile comp (that motion really helps!)
• My main concern is technical feasibility. The clients would need some kind of heuristic (ideally server side) to/not to know when to display the modals. I'm not sure what this could be, and I assume it's disadvantageous for us to store this per room in users account data. We should chat more with @novocaine on feasibility.

Tooltips

• Personally find this implementation quite noisy. Needing to read a sentence of 10 words isn't terse enough for a tooltip imo. Difficult to glance.
• I'd advocate to briefly visually explore splitting up the content into 2 lines ('This room is public' 'Anyone can read') with appropriate iconography to see if that helps. If it doesn't, I'd advocate to just keep the tooltips to communicate Public only.

[SimonBrandner]

I'm not sure what this could be, and I assume it's disadvantageous for us to store this per room in users account data.

Tbh, showing this for every public room could get annoying quite quickly. I think showing it once per client would be okay (we could use localstorage, or whatever)

[novocaine]

I suggest we have something unobtrusive next to the room title expanding on the current e2e badge that pops open to show all the privacy implications of the current chat, like how browsers do this in a lock icon next to the left of the url.

We can have message bubbles pop out from this that are similar to the proposed modals; but also draw attention to this button as the place to go to check for information in the future.

I'm not sure what this could be, and I assume it's disadvantageous for us to store this per room in users account data.

Tbh, showing this for every public room could get annoying quite quickly. I think showing it once per client would be okay (we could use localstorage, or whatever)

Agree with this; for me the heuristic would ideally be something that's practical to implement client side. I don't think it's a huge deal breaker to repeat the prompt across sessions if its not super annoying.

[nadonomy]

@novocaine that's a super interesting thought. We don't display shields in unencrypted rooms though. @niquewoodhouse wonder if we should look at evolving the public room tooltip to something closer to that reference? It's what I was alluding to in my 'tooltips' feedback.

[novocaine]

@novocaine that's a super interesting thought. We don't display shields in unencrypted rooms though. @niquewoodhouse wonder if we should look at evolving the public room tooltip to something closer to that reference? It's what I was alluding to in my 'tooltips' feedback.

Probably we should have something more prominent in unencrypted rooms than in encrypted ones..! and when they click on it, have something which explains the implications

[niquewoodhouse]

I suggest we have something unobtrusive next to the room title expanding on the current e2e badge that pops open to show all the privacy implications of the current chat, like how browsers do this in a lock icon next to the left of the url.

I don't see how that would work for mobile, where you can't hover over something to gain more information, and there's no space for an additional tappable icon in the room header.

Do we have a sense of how important is it to inform people of the side effect of inputting something into such a room (public + history set to anyone), and when they would be most interested in knowing that?

wonder if we should look at evolving the public room tooltip to something closer to that reference? It's what I was alluding to in my 'tooltips' feedback.

Think it's an interesting idea. My only criticism of this suggestion is that the icon would be the same, so in one room tile I have a globe icon that says "this room is public" and then I have another which says "this room is public. messages are public". I think it reduces confidence in the product to have an icon possibly represent different things. If you got stung by this in the future (my messages are findable by search engines), I think you'd then feel the need to hover over everything twice in the future.

Using the chrome example, they don't use a lock when they're communicating a warning.

[novocaine]

I don't see how that would work for mobile, where you can't hover over something to gain more information

Hrm, I must not have explained myself clearly, because I'm not suggesting anything is hoverable - the bubble suggestion is for them to appear in the same cases we're considering a popup

and there's no space for an additional tappable icon in the room header.

I'd just say that every mobile browser makes room for it, and it's a nice prominent way to advertise the care we take with privacy and safety

[niquewoodhouse]

I'd just say that every mobile browser makes room for it, and it's a nice prominent way to advertise the care we take with privacy and safety

I'd say mobile browsers have less functionality in their headers than a messaging app. We can have voice call icon, video call icon, join ongoing call button, widgets icon, avatar, back chevron, notifications, room name. @nadonomy redesigning these will take a bit longer than a quick fix (as was originally suggested) but I do agree it feels like a good way to promote the privacy and safety position that's integral to our proposition.

[niquewoodhouse]

Based on the above idea, this suggestion is intended to require little work:

01 Expand use and location of verification iconography in room headers on web to include warning/info icon

ele-public-rooms-header-hint-web-01.mp4

For the web, we'd need to potentially also amend the iconography in the composer, so it matches and makes sense. This would require more changes on mobile to include information in the room header and room info, e.g:

ele-public-rooms-header-hint-and-01.mp4

ele-public-rooms-header-hint-ios-01.mp4

---

We could finesse the header a bit to better accommodate the change/more information

[SimonBrandner]

Look awesome to me! Would it make sense to make the warning grey once the user has seen it?

[ell1e]

I juat wanted to leave a minor remark:

Sense is that something persistent or perceived to be a warning would be needlessly alarmist.

I disagree. Given the gravity of every word fully publicly indexed with no anonymization in the world's biggest search engine, I think a visible warning would be appropriate. A toolbar style warning at the top that fades away on its own which really spells it out might be a useful way to do it which is hard to miss (shown for people joining).

I also think that new rooms shouldn't have the visibility set to "please index it all publicly by default" in the creation dialog, (edit: seems like they don't, my bad) and that the room creation dialog should show a visible warning when that setting is chosen.

Edit: I still don't get why this is all required anyway. IMHO the indexing on view.matrix.org should just be a separate opt-in with some form that encourages room owners opting in to put a visible notice for all room visitors. (With that I mean an opt-in beyond just setting history to "anyone" inside a matrix client, e.g. on some sub page like view.matrix.org/opt-in.) That would solve most of these issues in an easier way. As I have explained at length, that someone else could in theory build such an alternate indexer anyway is not really practically that relevant until it happens - and you could also disallow that via some matrix.org homeserver ToS even if technically it is feasible.

[t3chguy]

Creating a public room does not make it indexable by view.matrix.org/similar

The admin has to go into Room Settings and select Who can read history? Anyone

and you could also disallow that via some matrix.org homeserver ToS even if technically it is feasible.

Nope, given they could run their own homeserver, given rooms don't belong to any one server, they then would only need abide by their own ToS.

[ell1e]

It wouldn't be hard to block abusive homeservers. (Which I kind of consider matrix.org to be with its google-indexed text contents. Why can't you use the noindex robots tag at least?) I still think this defeatist argument of "someone else might do it" isn't working, with that argument we might all just become criminals.

It seems a bit weird to me that Element may now need a flashy warning for History > Anyone just because view.matrix.org is set up the way it is, with no real need for it to be set up that way.

[ell1e]

Public rooms on Matrix, with history visibility set to 'anyone', are public the same way public web pages on the internet are public.

I also find this as a generic statement to be pretty odd. Because they may be archived or made available online also applies even to encrypted rooms with "Members only (since the point in time of selecting this option)", since it'd be pretty doable to make a bot that joins all rooms and scrapes the history and makes a public index of the contents all the same. What makes that so different? I just find this pretense that "History > Anyone" naturally implies it has to be public like a web page on the internet with full indexing strange - I don't find it very natural, and to me it just seems to be that way because someone arbitrarily decided they like it that way.

(My apologies if I am annoying people. I just want to point out that maybe there are other ways to see this, and that the way it's handled right now wouldn't need to be the only way. And IMHO all the talk about warnings/visibility is maybe just a symptom of the actual problem being that other people also don't find the current state that obvious and natural.)

[t3chguy]

Why can't you use the noindex robots tag at least?

Off-topic for this repository, but the primary intent of view.matrix.org was to be search engine indexed, to act as another gateway into Matrix for outsiders by finding content relevant to them.

[dkasak]

It seems a bit weird to me that Element may now need a flashy warning for History > Anyone just because view.matrix.org is set up the way it is, with no real need for it to be set up that way.

The warning needs to be there to inform users of the technical capabilities. This is a separate question from whether it is permissible to access such a history legally/socially/morally. This is analogous to the way we always display a crossed out padlock when there is no HTTPS on the web, regardless of whether it is permissible to intercept someone else's HTTP traffic.

---

As for the design, please let's not use danger-style iconography for room configuration like these. This includes red exclamation marks and wording such as "not secure" or "unsecure" (the latter is also not recognised as a word by most dictionaries).

Such use will lead to warning fatigue and prevent users from noticing warnings when we really need them to, like when there is an active attack being performed on their end-to-end encryption. This is especially important given that room configurations like this are perfectly normal and common in certain situations, such as large IRC-style public rooms. We don't want our UX to signal that these rooms are somehow dangerous.

We also cannot directly take a page out of the web browsers' playbook since their "Not secure" badge is actually talking about encryption and not access control. By using the same phrasing, we fall into the trap of confusing users about whether we are talking about encryption or access control.

I suggest we separate this out into two scenarios:

1. Public room, world readable history: grey i icon saying "Public message history" or "Public conversation", which upon hover/click displays a more detailed explanation.
2. Private or encrypted room, world readable history: This is an invalid state and current Element Web doesn't allow setting it. In this case, a red exclamation mark becomes appropriate, with the same message as chosen for 1.

[ell1e]

The warning needs to be there to inform users of the technical capabilities. This is a separate question from whether it is permissible to access such a history legally/socially/morally.

I heavily disagree on this one. Almost all history settings allow a targeted attack leaking your history, so are arguably not very different in security. (If the room just allows member access, it is trivial to join most rooms with a scraping bot if you really want.) The main difference however is that for the "Anyone" setting, things right now will guaranteed get dumped into the Google index and not just theoretically could be. The risk level of a merely possible publication into an index to facilitate stalking if someone really wants to mess with you, vs. to a guaranteed index dump in full is incredibly different, and I think dismissing that really misses the point.

[dkasak]

If the room just allows member access, it is trivial to join most rooms with a scraping bot if you really want.

Yes, and the user is informed of this fact via a globe icon and a "This room is public" tooltip. We need a similar way of informing the user regarding the technical capabilities relating to the world_readable history setting. The client should never hide the technical capabilities from the user.

Your complaint is about disagreement with matrix.org policy and is therefore an entirely different issue from this one. It's also off-topic for the Element Web repository. I suggest you raise your concerns by contacting the matrix.org foundation directly.

[bkil]

Somewhat related:

• what is a "public room" matrix-org/matrix-spec#633
• Consider replacing the public rooms list with a server-wide space matrix-org/matrix-spec#830
• Publicly advertise bridged accounts and rooms matrix-org/matrix-spec#620