-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
riot-web/desktop send requests to matrix.org on first launch, while logged in to another homeserver, etc. #11655
Comments
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. |
This gets critical status because it affects the vast majority of our users. |
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.) |
This issue is about that too: the config is validated on every startup. |
Sure, but if the default config is for |
That's why this is also |
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! |
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. |
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 |
Why are there any product requirements for network access before the user has instructed the client to do anything, sitting at the login screen? |
Well you can't show the login screen without knowing whether the default service as specified in the config.json is valid. |
For instance if the default HS as configured in the config.json is SSO-only then showing a username&password prompt is inappropriate. |
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. |
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. |
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?" |
You don't need to fork it at all, just specify your own config.json as I said earlier. |
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- They can't do so privately today. The client shouldn't do that out-of-the-box as downloaded. |
How would you propose it show a login screen without knowing what login flows the configured server uses? SSO? Username & Password? Email & Password? |
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 I assume (without any research) the In the other case where someone downloads a client and wishes to use it with an alternate homeserver, it should not automatically assume the 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.) |
Right but as soon as the user clicks 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
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.
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. |
Ok, then I've got my answer. Riot is an official client of the service offered by For me and my group of mostly nontechnical users, that makes the privacy leak serve as a nonstarter. I'm very sad about that. |
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
(where 2 is new) is very intrusive to the majority of users which make use of their config.json specified default servers. |
How can I configure linux installation of riot.im desktop client before first launch to avoid unnecessary requests? |
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.
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. |
@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. |
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. |
Phase 1 is tracked as #11154 |
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. |
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:
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. |
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.
The text was updated successfully, but these errors were encountered: