-
Notifications
You must be signed in to change notification settings - Fork 12
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Rather than infer device names we should prompt users explicitly to name their devices when they log in #382
Comments
This is causing much drama for people who don't want their useragents leaked. |
This obviously doesn't play well with the "just let me start using it" onboarding flow :/. Possibly we could prompt when you first join an e2e room, or at first sync (before we send out the oh hai) if you're already in an e2e room? (And use an opaque id until then) |
What if we used hash of user agent? Or is it human readable for identification purposes? |
yes, the idea was to make it useful for humans. We already have an opaque identifier - the device id. |
To me, default Riot-Web device names seem sufficiently generic, but Android devices leak very specific device/model info. |
We could probably prompt on first login but default to Web, Desktop, or Phone. |
Is there a reason we share device names with other users at all? Why not just list them by device-id? I feel like there was a reason, but it's shrouded in the mists of time |
appears from the mists of time the reason we include device names is in theory to help with the verification process. it lets bob phone up alice and say "oh hi, it looks like you just added an iPhone; can we check the keys?" rather than "oh hi, it looks like you added device ZBHJXCGUY". the device ID then acts as a disambiguator, a bit like mxids act as disambiguators for user display names. However, agreed that it may be causing more problems than it solves. As a first cut, let's dumb it down as per @Stebalien's suggestion to saying "Web", "Desktop" or "Mobile". Then perhaps in future we could prompt users to set their device's name, if it doesn't already have one, the first time they join an E2E room from that device. |
bumping priority as this is starting to get embarrassing from a privacy perspective - e.g. https://mail.gnome.org/archives/desktop-devel-list/2017-March/msg00045.html |
(more details device names also help users keep track of their own devices. but we could potentially do that anyway, without leaking the names to other users) |
Can't we just number them? Or give them random, pronounceable names ("Charlie", "Cat", etc.)?
We can just have local aliases for that (not public). |
Is it easy to simply disable or obfuscate device names in Riot? A pointer to where in the code would be lovely. Conclusion: Yes, it's easy. Almost.
Can I apply this modification to a compiled Riot? |
Are there UX issues with just prompting the user upon login? Some services like Steam do this. Until this is resolved, I think device name detection should be disabled entirely (or fall back to the random ID). This info leak has been going on over two years now. |
This really is something that should get mainlined. Plus, if you factory reset a wipe, perhaps present the option to replace a previous device signature with a new one? So you don't have 6x entities for the same actual phone, or something of that ilk. |
There is no reason to prompt users. use a word list out of which a random word is assigned as the device id. This is very important for user privacy, users don't know the defaults of a platform. when someone changes devices, they may not want others to know the platform they're moving to (even if the device specific id is not revealed). this acts like a "user-agent" where you'd know what OS,browser,matrix client,etc...someone is using. this can be used as a datapoint to specifically identify users. |
Nobody is going to associate random words with a device list, that makes it worse from a UX. It's already a random string of letters and numbers, changing that to random words most certainly does not improve the memorability of each device. People don't need to name the device in a way that's suggestive of what it is, just something they remember. |
@BloodyIron My suggestion was to pick one random word for the device,not multiple words per device. There are precisely two requirements:
|
I don't see that improving the situation from a UX perspective whatsoever vs current. |
@BloodyIron from a UX perspective, other users trying to see the verified/unverified device list of someone else can view a memorable name for the devices. Mind you,this is a default value we're talking about, users can change the device names to something more specific and obvious if they so choose. I might see for example:
The last entry would be edited by you, the rest are default values that preserve default privacy. That said, so long as there is no default association of device name and any property of the device, I'm happy with whatever is chosen. |
I just wanted to note that now you've shipped device cross-signing, the UX situation has changed significantly. Instead of showing session IDs to other users for verification, Riot only shows them to their owner (yes?). Which means that the more specific they are, the better. Also, any new session you open already prompts you to verify it from an existing (verified) session, so including an option to name the new session isn't a major imposition on users' attention. |
Is there a way to manually set the Element web session ID for a deployment globally? From config or via sed over the Docker container. So instead of showing " |
FWIW, this is not true. The human-readable session names are visible to other uses, you can simply bring up a user's info panel and list their sessions. This exposes info like whether they're using the element desktop or browser client and which OS they're on. |
|
True, my mistake, I misread. I guess I was confused since the comment discussed session ids being as specific as possible, and this is issue is about "leaking" information about devices to other users due to the human readable name, which is still the case. At any rate, I agree that asking a user to name a session doesn't seem like a big imposition. Or possibly presenting a default value and letting the user override it. |
Then please give a preference option at least. Those who want element to set session public name automatically (current behavior) will have no extra step after log in. And those who do not want Element to set session public name leaking user agent can set the custom name after login. Or better, give a preference option to automatically use ID as session public name instead of user agent as I don't care whether the session public name is human readable or not. This way there will be no extra step after login for privacy conscious folks too. If somebody wants their session public name to be human readable then they can always edit and set it in Settings > Security & Privacy later. |
Looking at my current list of sessions, with at least one Element Web and one Element Android, this doesn’t seem to be an issue anymore. |
I'm not sure on what basis you're saying that, but AFAIK the Element clients still default to device names which give a lot of information. (Here is the element-web implementation, for example). That said: I strongly disagree with the solution proposed in this issue "we should prompt users explicitly to name their devices when they log in". We could update the subject, but then most of the discussion will be confusing. So I'm going to go ahead and replace this issue with another that describes the symptoms, rather than proposing a solution nobody likes: #2288 |
Actually a number of people do like the proposal in the issue name. Not as a solution to the problem of leaking device info, but to help people avoid confusion about which session their own session names point to. See my comment here #382 (comment) Do I need to open a fresh issue about this? Or can we reopen this issue, given that the name is fine, and it actually had no specific problem stated in the initial description. |
Issues should describe problems, rather than specific solutions to an unspecified problem. Feel free to open a new issue describing the problem you are having. (Screenshots are always handy, to make sure we're all talking about the same thing.) We can then discuss the best way to solve it. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
No description provided.
The text was updated successfully, but these errors were encountered: