riot-web/desktop send requests to matrix.org on first launch, while logged in to another homeserver, etc.

[aaronraimist]

riot.im/app and /develop send a GET request to https://matrix-client.matrix.org/_matrix/client/versions and https://matrix.org/.well-known/matrix/client even when you are logged in to another homeserver.

[turt2live]

This is to ensure the config is valid before you embark on a journey through Riot. It's possible your homeserver logs you out, or you log yourself out, in which case the auth pages should still work.

[turt2live]

This gets critical status because it affects the vast majority of our users.

[sneak]

Note that this bug's description is scoped too narrowly: it appears to send the requests on first launch, when you've never logged in anywhere. (These statements are based on @turt2live's assertion that #12712 is a dupe - that one is about first-launch, never-logged-in behavior.)

[turt2live]

This issue is about that too: the config is validated on every startup.

[sneak]

Sure, but if the default config is for matrix.org, then "config validation" is a form of accidental telemetry. Is it absolutely required that config validation hit the network?

[turt2live]

That's why this is also needs-product-decision. It is categorically not intended to be telemetry, it's just to make sure the app works with whatever build config is shipped with the app.

[sneak]

It is categorically not intended to be telemetry

I appreciate that. The military intelligence spies don't, and slurp it up anyway. :)

Thank you for prioritizing this! Lots of projects don't take these sorts of leaks seriously. On behalf of people who need privacy even more than I do, thank you!

[sneak]

Per #13942, it also connects to vector.im and riot.im, for a total of three unauthorized/unnecessary connections, even when just launched and sitting at the login/signup screen. I've filed this as a separate issue, because it seems that this one is scoped to contacting matrix.org, when in reality there are 3 different privacy leaks.

It should be connecting only to the homeserver to which it is configured, and then only on signup/login. Any other third party connections (such as vector.im, or an upgrade check if that's why it's contacting riot.im) should be opt in.

I don't want my privacy client talking to any services other than my self-hosted one, thank you. This has been keeping me from using or recommending Riot/Matrix, because this is a major privacy leak.

[t3chguy]

As a product requirement, riot first thing it does as part of boot ensures that its config.json is valid, which means confirming all the default services specified there.

For riot desktop you can change the config as per the docs. https://github.com/vector-im/riot-desktop#user-specified-configjson

[sneak]

Why are there any product requirements for network access before the user has instructed the client to do anything, sitting at the login screen?

[t3chguy]

Well you can't show the login screen without knowing whether the default service as specified in the config.json is valid.

[t3chguy]

For instance if the default HS as configured in the config.json is SSO-only then showing a username&password prompt is inappropriate.

[sneak]

If that's the policy, I think it's unreasonable in that case for the default config to assume that I want to use those three third-party services without asking me first.

[t3chguy]

Well that's up to you, depending on what Riot instance you use, if you download the official vector.im riot-desktop build then that ships with a config that specifies those services. Any instance/distribution is free to provide config pointing at their own services.

[sneak]

Is that a polite way of telling me "fork it if you don't like it to connect to servers you don't want to talk to automatically on startup without notice or consent?"

[t3chguy]

You don't need to fork it at all, just specify your own config.json as I said earlier.

[sneak]

I'm talking about the product being a de-facto client for matrix.org, not my usage. I can rip all of this telemetry out of the client and rebuild it if I wish; I'm talking about the potentially thousands or millions of people who download this client and expect to be able to use it to privately communicate with a non-matrix.org homeserver.

They can't do so privately today. The client shouldn't do that out-of-the-box as downloaded.

[t3chguy]

How would you propose it show a login screen without knowing what login flows the configured server uses? SSO? Username & Password? Email & Password?

[sneak]

Well, if the config is non-default, that seems like a reasonable approach, as the user or their distributor has explicitly configured things.

In the 99.9% case where a user has simply downloaded the app from the website and double-clicked it, it shouldn't need to do anything at that moment of launch. If the user takes an action, any action, to attempt to use (log in, sign up) on matrix.org, then it should talk to matrix.org, but not before. It should then prompt them to opt-in to using the vector.im lookup service at that time. Perhaps the correct answer is to launch with a default config that does not configure these, then sets the appropriate servers in the config if and only if a user attempts to use those default servers (which most will do).

I assume (without any research) the riot.im connection is an autoupdate check? That should also be opt in (perhaps with a modal, as annoying as they are, and perhaps after the client is open for a period of time as to not spam them on startup), as it serves as nonconsensual telemetry if the user doesn't want their ISP/government or the riot.im operators or hosting provider to know their IP is using matrix/riot.

In the other case where someone downloads a client and wishes to use it with an alternate homeserver, it should not automatically assume the matrix.org/vector.im configuration values on fresh/clean startup. A user action should happen before those values, and thus their network checks, occur. That way a user can download the app, launch it, configure their custom homeserver in the GUI, and nobody from matrix.org, vector.im, or riot.im ever knows it happened.

I want to be able to tell nontechnical people "hey, download Riot for your computer, type in my server address, and sign up" and have no network connections to any third party from their computer that might violate their privacy or broadcast the fact that they are using the Matrix protocol. I can't do that today because it rats them out as a Matrix user to at least their ISP and national government due to large-scale passive surveillance. (They can do that with an IRC client but, as we know, IRC sucks.)

[t3chguy]

Right but as soon as the user clicks Login the default server as per their config is matrix.org so without changing the flow to add yet another button click it'd have to already make a web request to know the flows to use there.

The update endpoint as per the default riot-desktop config is on packages.riot.im - https://github.com/vector-im/riot-desktop/blob/develop/riot.im/release/config.json#L2

That should also be opt in (perhaps with a modal, as annoying as they are, and perhaps after the client is open for a period of time as to not spam them on startup)

They are opt-in, you opted into it by choosing the official distribution which has it always enabled. Bugs with out of date versions cannot be resolved.

Using the custom config.json I shared document to earlier you can also disable update checking.

In the other case where someone downloads a client and wishes to use it with an alternate homeserver, it should not automatically assume the matrix.org/vector.im configuration values on fresh/clean startup. A user action should happen before those values, and thus their network checks, occur. That way a user can download the app, launch it, configure their custom homeserver in the GUI, and nobody from matrix.org, vector.im, or riot.im ever knows it happened.

Sadly a large number of users use matrix.org and adding an additional click to everyone to accept the defaults they chose by choosing the source they got their app from would be a really poor onboarding UX.

[sneak]

Ok, then I've got my answer. Riot is an official client of the service offered by matrix.org, and I cannot recommend use of Riot to people with which I want to communicate in the manner mentioned above, because it will immediately connect to matrix.org and other supporting services on startup by default regardless of whether or not the end user is taking advantage of federation (by using a different homeserver) or not.

For me and my group of mostly nontechnical users, that makes the privacy leak serve as a nonstarter. I'm very sad about that.

[t3chguy]

The current behaviour which came from product is to make sure the config.json is valid and nothing there is wrong, which means verifying all provided services and refusing to start the app if the config.json proves invalid. I will raise your concerns with the product team.

Overhauling the Login process to add another stage before the Login/Registration field e.g

1. Click Login
2. Click accept default homeserver
3. Enter credentials

(where 2 is new) is very intrusive to the majority of users which make use of their config.json specified default servers.

[sneak]

Auto-updating for default Riot distributions will continue as before to ensure security fixes are delivered quickly

This is not an acceptable default.

Autoupdates are telemetry (and also remote code execution, granting full access to the endpoint encryption keys to any party who can subvert the software distribution server) regardless of whether you think it's in a user's best interest to autoupdate or not.

You really need to get opt-in consent for telemetry such as an autoupdate check, otherwise you are leaking users' private usage data without their consent, which is unethical and dangerous. It means it's impossible for a normal, nontechnical user to use Riot on an alternate homeserver without you (and many others) knowing that they are a user of Matrix/Riot. You are not entitled to that information without consent.

[redmosaic]

How can I configure linux installation of riot.im desktop client before first launch to avoid unnecessary requests?

[sneak]

For this section, we have not yet found clear path to removing these requests without degrading the UX for most users.

Do I need to flowchart or pseudocode this for you to show you how to not make requests to a server a user does not ever want to use?

Tons of client software does this just fine; IRC and XMPP software, for example. It is plainly and simply possible to have clean and smooth UX with defaults in place and still let a user choose to change settings before you make network requests.

For now, you will need to use a custom configuration to avoid these requests

Privacy software that does not allow nonconsensual telemetry to be disabled by normal, everyday, nontechnical users via the UI is not privacy software, it is spyware.

Please do not build and ship spyware.

[auscompgeek]

@redmosaic https://github.com/vector-im/riot-web/blob/develop/docs/config.md

[t3chguy]

https://github.com/vector-im/riot-desktop#user-specified-configjson

[ara4n]

@sneak as should be pretty clear from #11655 (comment), we're going to fix this, and yes, imo, autoupdates need an opt-in. We're going to land the first-time user experience work we have in flight first though.

Thanks for bringing it up.

[sneak]

I didn't see anything in part 2 of the linked comment that suggests that the (inadvertent) telemetry events described in 2 are going to be fixed, which is why I expressed my disappointment in the "edit the config file" response, which is something that absolutely none of the users I wish to invite to my homeserver will be able to carry out. If anything, it makes it sound like it's not going to be fixed.

[t3chguy]

Phase 1 is tracked as #11154

[turt2live]

For clarity/to summarize, this requires a rework of our entire application startup. Currently it's considered a feature that the app validates the config, however if Product decides otherwise then we can take a look.

I think this requires a major refactoring of our understanding for the application lifecycle, however, and therefore requires a dedicated project.

Placing into the design/product queue for now.

[3nprob]

Just an observation: Validating config is great but connecting to validate if the configured endpoints are available is best seen as a separate step. That is:

Validation check = Config validation (offline) + services availability check (online)

As mentioned by @sneak and @ara4n , the offline check can (like today) be done immediately on startup. The latter needs explicit opt-in for both ethical and legal compliance reasons. Any logic necessary to validate config should be possible to perform offline.

Even with a valid config, the configured endpoints can be unavailable or misbehaving for a variety of reasons, which is orthogonal to validating configuration. I see no explicit mention here that the wish from Product to validate config is in conflict with the need for all server interactions to be explicit and opt-in, including auto-updates and prelogin validation.