Quick lock function to let folks lock the app with a PIN or something when they step away #3777
Comments
|
I think locking the screen would be a more usual way of achieving this - I can't think of any other webapps that let you lock them independently of the computer. Of course, with Riot there is the sign-out/export-keys dance, so if there are users on shared computers, dipping into/securing Riot could be more of a pain and this feature could be useful for them. |
|
krombel points out in https://matrix.to/#/!DgvjtOljKujDBrxyHk:matrix.org/$149783085295QIKSn:msgs.tk that Chrome allows you to lock your profile. In theory, people can also create multiple accounts on their computer if other people are using it, but that may be too much for some people. |
lampholder
added
P4
It would be extremely useful for the Desktop versions of Riot. For example: I'm allowed to use Matrix/Riot at work but the profile folders of the work account is not encrypted so any admin can access my Riot profile as long as I don't logout everytime leaving work (which I try to avoid because I prefer encrypted channels so daily login/logout will cause key chaos). |
|
Same for me. I use the Desktop version of Riot and some message channels should not be read by someone else. I usually do not lock my workstation. Would be nice to see that on the Riot Dektop as well! |
SimonBrandner
added
O-Occasional
|
Any update on this? I see people requesting this regularly. |
|
Any news? |
|
News is posted to the github issues as we have it. |
|
@SimonBrandner It is sad that Signal App requires a cellular device to use it, and for those in the know on the real reasons for some "country-specific" chips, know why Signal App is not as secure as it's made to believe. So, Element was a breath of fresh air with its "no requirements" for a cellular modem enabled device or even a phone number. But having supposedly secure chats unlocked/decrypted for anyone to access or even control rooms, if they got a hold of your device/tablet/laptop etc, makes quite a dent in its overall "security". My own request for such a feature for the DESKTOP client that I posted recently: But why are all the Non-Web requests for this feature forwarded to this web issue? I now discovered that many people had the same exact request since 2017 or earlier and yet it's almost 2023 but it's nowhere to be found. Now perhaps this is a difficult task? Is that why it hasn't been done, not enough resources for it yet? Will you please give confirmation here if you will accept and incorporate a Pull-Request for such as feature, especially as I've described in my ticket? Because perhaps some of us would be willing to code this feature or hire someone to do it, but only if we actually have confirmation that you will incorporate it, that you will merge such a Pull Request. (A similar clarification from you might be helpful on many other tickets as well, since sometimes we are not sure if you are simply against incorporating a proposed feature, or if you lack the resources etc.) |
Element Desktop is simply Element Web wrapped up in Electron, with a handful of desktop-specific features. To ensure issues are tracked, triaged, and noticed, we move Desktop feature-related issues to this repository.
There have been other priorities. More resources wouldn't necessarily mean this feature request gets any higher on the list, unfortunately.
We can't speak for the Product team, which has final say on features going in or staying out, but from experience I do believe that it would be accepted. The technical challenge will be immense though, as we'd somehow have to protect the JS console from being used to extract messages (a visual PIN entry pad isn't safe enough: we also have to unload all the events from working memory, for example). This ticket is already flagged as needing Product input, which means when it gets to the top of their list they will be able to confirm if it is a feature they'd like to see in the app. The Design team's input will help make the feature be presentable to users. I should also mention that normally features like this will require a small team of people and involve our Product and Design teams extensively: it might not be the easiest thing to contribute in this respect. I would highly suggest picking up a different, less complicated, issue to fix instead. |
|
also that still implies that desktop notifications are prevented, which is starting to blur the line between a feature and just closing the app. If someone had the forethought to lock/blank their chat client, surely they'd just close it instead for the same effect? The usecase which appears to be most prevalent is encryption at rest, where the PIN is actually a passphrase of sorts for the data. Full-disk encryption is usually how this would be handled, but that's not entirely possible here. Since this issue was opened, plenty more data is stored encrypted at rest, including the user's access token (when possible). Not to say it's a solved problem, but we've made strides in the underlying concern at least. |
Oh yes, an app without a PIN is much much much much more secure rather with a PIN. Maybe it's better to remove the PIN feature in the phone apps as well? This person can also lock the phone, following your logic. Why do you think the phone app should be more protected than the desktop app?! This function is literally a few lines of code! Can't you add such a simple app lock screen for an app? Excuse me, but the PIN should be the basis feature for the messengers. And it is, but only in phone apps. WhatsApp, Signal, Viber, they all have a PIN. |
It's hundreds, if not thousands. You're more than welcome to write a PR to try it out yourself. |
|
Seriously? P.S. I don't know Element programming language so I can't modify your codes. |
|
The "extra" features are ones which make it a proper feature though, as without them the functionality instills a false sense of security. Other messengers with the same lockscreen functionality ensure the user's data is handled safely behind the scenes: it's not a simple privacy screen. For reference, the composer in Element (which "just" sends messages) is about 500 lines itself at a minimum - it's probably more in actuality when you start to consider the added features like mentions, autocomplete, slash commands, attachments, encryption, polls, location sharing, voice messages, voice broadcast, stickers, and emoji: these are all "table stakes" features (things we need to ensure our app is competitive), and we'd consider user safety the same for a lockscreen. The issue also isn't really the number of lines itself. The lines are inevitable. It's the technical design and data handling within the app that becomes the issue. Adding a screen with some buttons on it is indeed easy, but wiring that up to any amount of functionality involves Design and Product teams and consideration for the codebase: do we need a keyboard shortcut? should it have a timer? can the user change their PIN? where does the PIN get set? is the feature mandatory? how many attempts does someone have to get it right? what happens if the wrong PIN is entered too many times? etc. These questions might seem easy to answer on the surface (we could probably answer them here fairly quickly), but each adds time to the implementation. For example, "add a section in settings to set/change a PIN" means a developer needs to go find out how the settings screens work, add their section, hook it up to some code which actually does something, and test it - this is about an hour on average. To answer the followup question of why developers might need time to understand the settings system: not everyone is an expert in the whole codebase - it's massive. It takes time and experience to learn how the whole app works, and even then it's so large of a codebase that people tend to forget how it works by the time they get back around to that area. |
Yes, these things require attention. And I, as a developer, perfectly understand that developers develop much more necessary things than PIN. I've been using Element ever since it was called Riot. And I'm grateful to the developers for such a secure messenger. But this issue has been open since 2017. It's been 5 years already. You must understand that the PIN is a really necessary feature. It doesn't matter how simple (or not) this function is. You implement this function in mobile apps. Why is this feature missing from the desktop app?! Just imagine the scenario. You leave your workplace for something. You say, "You must lock your computer". May I ask you a question? Why are you embedding a PIN in the mobile app? The phone can also be locked and it can be locked automatically. I think the PIN is less required in the mobile app than in the desktop. Or imagine another scenario. The workday is over. You are going home. Over the weekend, the sysadmin decided to update the computer programs at your workplace. He starts your computer and sees the messenger, and then opens it and starts reading all your messages. If the app has a pin, he just sees the pin and closes the messenger. That's all. This is safety. I really don't understand how the Matrix team, that developed such a secure messenger, can't understand the need for a PIN for security reasons. |
Yes, I also find the value of a PIN in the mobile apps to be somewhat questionable. But there is one use case that I can think of: a device might be shared between multiple people. Desktop operating systems nowadays have good multi-user support (sometimes even supporting home directory encryption so that admins can't read your files), but multi-user support in mobile devices is rarer. So if you have a shared tablet, but you don't want anyone else to read your Element messages, a PIN would be useful in that case. On a desktop, you would simply use your own account, so that would not apply. Also, it is easier to implement securely in the mobile apps, since it is harder for someone to access the application's data in other ways. In the web/desktop app, someone could use the JavaScript console and read your messages, bypassing the lock screen. One of the issues with implementing a lock screen is that, unless the application truly is locked, which is harder to do, it would give a false sense of security.
If you log out of your computer, the admin should not be able to access your account. With the desktop app, we store critical data encrypted using a key stored in the operating system's native keychain. On Linux, this cannot be unlocked without using a password (it's often unlocked by the user's system password, so it automatically unlocks when you log in). I believe it's the same or similar with macOS and Windows. This is, unfortunately, not possible to do in the webapp without a browser extension. One thing that we have considered (though I don't remember if we have an issue open for it) is to prompt for a password when the webapp starts up, to take the place of the key that we store for the desktop app. Prompting for a password at the time that the app starts is easier to implement than a lock screen, since we don't need to worry about such things as clearing out events from memory, as we don't have any events in memory yet. However, we recommend that serious Element users use the desktop app rather than the web app.
Firstly, this is an issue in the Element repository, not Matrix. There are other Matrix clients, which may make different decisions. Matrix itself does not make any recommendations one way or another. Secondly, I should note that we are not necessarily opposed to implementing such a feature, per se. However, we need to consider the tradeoffs involved in implementing it. Part of implementing a secure app is defining what your threat model is. What are you protecting against? Do the features that you implement actually protect against that threat? Can the threat already be mitigated by other things? Could the feature make things worse by giving the user a false sense of security, making them think that it it more secure than it actually is, possibly even to the point that they do not employ better security measures? |
AGAIN. It's just a simple, primitive protection. You cannot completely protect an app from being hacked.
A person who unauthorizedly opens your messenger to spy on your messages, in the vast majority of cases, leaves spying attempts when he sees PIN protection. Not everyone is a hacker. And colleagues won't bother hack your messages when they see the PIN.
You live in some wonderful fantasy world. Sysadmins usually have full access to any computer and any computer account. Maybe in companies like Google or something, personal safety is a big deal, but not in most companies.
Excuse me, but how did we move the conversation from the desktop app to the web app? I have never seen a PIN-lock in any messenger web-app.
Sorry, of course I meant the Element team, not the Matrix. It's just a typo.
I haven't seen really stable clients other than the Element. And most other clients require difficult installation.
Do you really think so? So you think that an app that doesn't even have primitive PIN protection (such as I described) is more secure than one with primitive pin protection? Am I correct?!
Okay. If that's the point, maybe you can ask users for their opinion? You are obviously developing a messenger for the people, but I see that the opinion of the people doesn't bother you. I'm sorry, but 5 years is too long for such a simple function. |
|
To reiterate, the web app is the same as the desktop app, just pacakged differently. It is the same codebase. Also to reiterate, we are not going to implement the easiest path because it is easiest: we will implement the path that makes the most sense for our users. Your comments are bordering code of conduct concerns now - please consider stepping away from the conversation. Repeating your same arguments over and over is not going to convince us that they are correct. I will respond to your general themes here, though: please tone down your language if you'd like to further discuss this feature. The people you are talking to are from the development teams which work on various projects within Element, including Element Web and Desktop themselves. We are also aware of what the Product team, a seperate team at Element, generally requires for any new feature being added to the app. We have mentioned the requirements based on what the Product team would require from an implementation of a lockscreen, further reinforced by conversations we've had with the Product team in the last 5 years about the feature. The mobile apps are completely different codebases with completely different teams managing them. The lockscreen feature on mobile is questionable, but as @uhoreg mentions there are valid usecases which mean the Product team has considered how that feature works in that application already. This is independent of our team, and our technical challenges. As for this issue being open for 5 years: we've been busy working on other features, and of course fixing bugs. There are nearly a dozen different teams which contribute to the Element apps, on any platform, and they all have different priorities: some are focused purely on value-add features like this, others focused on making the developer experience of writing features easier/more enjoyable. Specifically, there are 4 teams which would implement this sort of feature, and 2 of them would drop this from their roadmap if it had any chance of landing on another team's medium-term roadmap. That leaves 2 actual teams which would implement this feature. Those two teams have roadmaps which list this feature, and always have, but do not have the feature scheduled for development because there is higher priority work above it. That higher priority work doesn't neccesarily mean that it's higher priority work in your eyes though, so it's important to consider what types of users are using Element. Personal messaging is only a portion of Element's userbase, with Enterprise and Enterprise-like messaging taking the larger share. A lockscreen feature tends to have more of a personal messaging usecase, though there are of course applications in the Enterprise world too. In fact, a few customers of Element have asked for a lockscreen feature, which is how it ends up being on the radar for 4 teams instead of 1. This does not neccessarily mean it'll be implemented soon, though. We do not have an estimate for when a lockscreen will be available in Element Web/Desktop, but will share details if or when needed. Finally, on security of a PIN versus no PIN, there is negligible security benefit of having a lockscreen that simply hides the content that's behind it. It's no different than turning off your monitor: the content isn't visible, but is trivially accessed. This is why we are so focused on a solution that takes into account security of the user's data (messages, access token, etc): if the data is trivially accessed or the lockscreen can be bypassed with a few mouse clicks then it provides negative value to our users, not positive. For clarity, this means the development team (the people you're speaking to) would reject a change which only puts up a visual blocker to the content. The Product team likely wouldn't even be consulted because the application's security overrides the Product opinion of a feature. I do not expect you to agree with any of this, however I do expect that you understand why we are taking this position on the feature. As a reminder, please tone down your language if you plan to continue engaging with this conversation. |
You mentioned this twice, but what's wrong with my tone? I'm completely correct and polite. However, sorry if I offended anyone.
I disagree, but I understand your way of thinking. In this case, I think it makes no sense to continue the conversation. Have a nice day. |
@turt2live Oh boy, how many extra jobs will I have to get hired for so I can afford to talk with "contact-sales"? :) But yea, one day I look forward to carry such clout. The reason I was looking to a possible "crowd" type bounty-source funding was so "all of us" interested in a specific feature could pitch in together to get it "funded". |
|
I can't believe that some sort of basic app blanking w/pin isn't implemented yet. I mean, I literally cannot believe it. I understand all the crankery about "doing it right"; but it's not needed; just like me and literally 90% of the other element users I know; we JUST want a way to keep the casual passers-by from nosing at a computer that NORMAL USERS may have forgotten to screen lock, or are on a shared machine, aka your coworker/roomie/friend/partner wants to "check something quick" or multiple family members on the same machine login (and that happens a LOT) We're not looking for enterprise grade security from a 4 digit pin... we're looking to keep little timmy or Nosey M. Parker from casually plopping down and opening the app. And NO, logging out every time is impractical and a pain in the arse, especially if it's something like a bathroom break. Cover the app window, blank out the notifications to a count or "you have a [x] new messages" and put a pin there. In the settings to set this up EXPLICITLY warn the user of the pin locks limitations and wipe your hands of it. |
|
Me:
They
That is all what we need to know about the security of this messenger. Personally, I've already switched to another messenger. |
|
That's the issue indeed... They don't get it. We, as in the common, normal, every day Joe and Jane users want a way to, adding emphasis here, simply hide from casual view the contents of the element app from casual passers-by/non-account users. You even showed where they actually understand WHAT we want, but have their heads so far up their butts they can't understand where their users are coming from: "It's no different than turning off your monitor: the content isn't visible," YES! THIS! EXACTLY! But imagine that the monitor MUST be on and someone else, with exactly ZERO technical knowledge, is sitting at your computer... but you don't want them casually seeing your discussions. I personally know 3+ dozen users that want this, which is the majority of them mind you. If the dev types want me to bend some arms and make normal users with less than zero interest in programming or development and just want something that works, to join this site full of devs that obviously don't CARE what they think and want to make themselves heard, I'll start twisting some arms. But I really don't see why this is necessary for something so literally trivial. |
|
As a reminder, this repository is under a code of conduct. We use the same one as matrix.org: https://matrix.org/legal/code-of-conduct Implementing this feature as a simple screen lock gives a false sense of security for our users who actually need that security. Not everyone needs that level of security, however a large portion of our user base does. |
|
And a large portion of your userbase doesn't... Again, since no one read my original comment, in the set up section for it; make it abundantly clear that it's not securing the app, it's a blanking function ONLY, it's NOT protecting the app or your session in any meaningful way aside from visually. That's all we're asking for. We're not looking for miracles, we just want something to stop someone from casually, trivially LOOKING at it from an unlocked/unsecured computer. That's it. |
|
A vocal part of the user base is looking for something simpler, but that doesn't necessarily mean a large part, unfortunately. Asking for the design and product teams to find a way to manage the user's expectation would end up taking the same amount of time as doing it properly: the concession saves no time or effort, only adds problems and concerns. We also aren't looking for miracles or perfect solutions, but do hold ourselves to a deliberately high standard for features that affect large parts of our user base, particularly when that feature is seen as a security feature. |
|
@turt2live Fair point about false sense of security, but this is easily solved: IMPLEMENT this feature as a CHILD LOCK with optional 'password/phrase". Some of us have kids who use our devices... Other uses: maybe you're at work and you have the chat running and need to do remote control sharing and don't want messages popping up or maybe at work your boss needs to use your PC to show you something for a second and you don't want to signout and yet don't want him to see your chats by accident etc. So, I propose this be implemented with "very little real security" and just as a "CHILD LOCK" feature with optional "pass-phrase" to unlock. (with javascript console gimmick to even unlock it if you forget your passphrase, that's ok.) Because I can see that the maintainers are worried about false security and it is true that the electron nature of the Desktop app and inherent Javascript console etc can make security difficult. Perhaps more secure versions can be left to native or flutter apps and not the main electron browser based one. But basic CHILD-LOCK version that blocks notifications and ability to view chats or type into them, how about it? |
|
@turt2live @ara4n Would my above proposal for implementation as a basic Child-Lock be acceptable and make easy/quick merging of a PR into master? Or would you prefer to just do it yourselves since less hassle communicating on UI placements etc when the actual code itself could be more trivial than UI decisions? Interestingly I found this about chrome browser 'locking' of tabs: Seems not too niche to ask for Lock screens when chrome itself added similar. |
|
A child lock implies other features that aren't entirely in scope in this discussion, and still would have roughly the same caveats as not implementing a proper lock screen in the app. |
|
@turt2live What other features could a very simple Child-Lock require that the OPs initial request didn't require and so it's not in scope? My whole point is that the Child-Lock would be the "simplest" and "most basic" implementation of a "lock". And it "specifically" addresses the "caveats" of not implementing a "proper" lock screen, since it is "normal" that NO ONE should expect a Child-Lock to be "secure". |
|
There's no other competing messenger I'm aware of which has a child lock - the closest description is parental controls. As mentioned though, such discussion would be better suited for a different ticket. Worth noting that the original request is for a significantly more secure lockscreen than the one you're asking for as well. |
|
@turt2live As others have mentioned, other competing messenger apps have more secure LOCK screen methods which would make my basic simple CHILD-LOCK type lock-screen proposal "un-necessary". Those apps like WhatsApp, Signal, Viber etc that others already mentioned having such "Lock" screen, would have no need for a Child-Lock when their more secure Lock Screen would suffice for that purpose just as well. My recommendation for basic simple "Lock" Screen of low "Child-Lock" type security was a compromise, which seems to me to very well SUFFICE for most of the use-cases mentioned in this thread, and it would be quite trivial to implement compared to the more complex secure methods discussed. As I said Child-Lock style (or call it Parental Control if you wish) could (and maybe should) be easily circumvented via Electron's Javascript Console (I even see that as a good 'feature'). So because the low security solution I proposed seemed to meet all requirements of previous commenters judging by their use cases, I thought it's in scope here. Nevertheless, I've taken your advice and opened a ticket for my proposal, here: |
Yes, this is my point: if we're going to implement a lock screen, we had might as well do it properly considering it's the same amount of effort. |
|
@turt2live It's not the same amount of effort, how could it be same effort code-wise? Unless you were referring to 'non-coding' effort? Is that what you meant? I thought the answer was "no", that this issue will not be done, at least not in any "near future" at all, because it's too complicated to do it properly on JS/Electron. That's the reason I proposed the simpler very basic (CIRCUMVENTABLE) child-lock type solution, because it would be "trivial to implement code-wise by comparison". And it seemed that it would still meet/suffice all of the usual use-cases for myself and everyone else who actually wanted this feature in the first place. Make sense? That's why I took your advice when you said: But, if project leaders changed their mind, and now you do plan to tackle this issue and create as you say, a more "proper" and secure implementation, then "Great!" :) |
|
I am referring to non-code time. The difference between a circumventable and secure implementation is which team spends time working on the feature: for a circumventable one, it goes through rounds of Product and Design review to ensure expectations are managed, whereas with a secure implementation the most amount of time spent goes into technical feasibility. This ticket is still not on an immediate roadmap, nor is the issue you opened as a possible workaround. I expect that the Product team will end up deciding that the more secure option is worth it, however I cannot speak for them. If this can be achieved in a secure way, I'm sure the team would appreciate a PR to speed the process along.
The issue was opened with the secure implementation in mind. A less secure implementation is what recent comments have been about, but not representative of the whole user base, sorry. |
|
@turt2live Ok what you say is fair enough then: In this case, please leave my 'basic' alternative open at #24698 and those who are ok with that easier/faster to implement one can comment there and those who need a more proper secure version can make their voices heard here in this ticket. thanks |
|
The issue you opened is still open, and I have no plan on closing it. |
|
Any news on this? |
see element-hq/riot-android#746. it's debatable how useful this is on the web though; surely you should just lock the screen
The text was updated successfully, but these errors were encountered: