This shows an incredibly cavalier approach to security on the part of the team working on signal.
Moxie would be spinning in his grave if he weren’t still working there…
Moxie tried to put a crypto-coin into signal. He is not to be trusted in the slightest.
That applies to pretty much all desktop apps, your browser profile can be copied to get access to all your already logged in cookie sessions for example.
IIRC this is how those Elon musk crypto livestream hacks worked on YouTube back in the day, I think the bad actors got a hold of cached session tokens and gave themselves access to whatever account they were targeting. Linus Tech Tips had a good bit in a WAN show episode
And there are ways to mitigate this attack (essentially the same as a AiTM or pass-the-cookie attacks, so look those up). Thus rendering your argument invalid.
Just because “something else might be insecure”, doesn’t in any way imply “everything else should also be insecure as well”.
It is the same concept. Once your machine is pwded you are screwed
That’s all hinges on the assumption that your computer is pwned. Which is wrong
You don’t necessarily have to have privileged access to read files or exfiltrated information.
That point doesn’t matter anyways though because you’re completely ignoring the risk here. Please Google “Swiss cheese model”. Your comment is a classic example of non-security thinking… It’s the same comment made 100x in this thread with different words
Unless you can list out all possible risks and exploits which may affect this issue, then you are not capable of making judgement calls on the risk itself.
You act as though you somehow have more knowledge than everyone else. They problem is that you don’t understand encryption and permissions. You can’t just magically make something unreadable by programs with the same permission level. If you encrypt it there will need to be a key to decrypt it. That can could conceivably be encrypted with a password but that would require someone to enter a password. If they don’t enter a password they key will be stored plain text so anyone could easily decrypt your messages. Programs running as a user have the same permissions as that user. Does that make sense? You can’t just make something selectively unreadable with the current security model. I guess you could try to implement some sort or privileged daemon but that would open up more issues than it solved.
I would have a problem if Signal claimed that the desktop messages were encrypted at rest. However, they don’t make any such claim. If you are concerned about security I would recommend running everything in virtual machines and flatpaks. This way the chances of something misbehaving in a way that causes harm is minimized.
I’m not claiming some grand level of knowledge here. I also cannot enumerate all risks. The difference is that I know that I don’t know, and the danger that poses towards cognitive biases when it comes to false confidence, and a lack of effective risk management. I’m a professional an adjacent field, mid way into pivoting into cybersecurity, I used to think the same way, that’s why I’m so passionate here. It’s painful to see arguments and thought processes counter to the fundamentals of security & safety that I’ve been learning the past few years. So, yeah, I’m gonna call it out and try and inform.
All that crap said:
And you are right, the problem gets moved. However, that’s the point, that’s how standardization works, and how it’s supposed to work. It’s a force multiplier, it smooths out the implementation. Moving the problem to the OS level means that EVERYONE benefits from advanced in Windows/Macos/Linux. Automatically.
It’s not signal’s responsibility, it shouldn’t be unless that’s a problem they specifically aim to solve. They have the tools available to them already, electron has a standardized API for this,
secureStorage. Which handles the OS interop for them.I’m not arguing that signal needs to roll their own here. The expectation is that they, at least, utilize the OS provided features made available to their software.
How in the fuck are people actually defending signal for this, and with stupid arguments such as windows is compromised out of the box?
You. Don’t. Store. Secrets. In. Plaintext.
There is no circumstance where an app should store its secrets in plaintext, and there is no secret which should be stored in plaintext. Especially since this is not some random dudes random project, but a messenger claiming to be secure.
All your session cookies are stored in plaintext.
How in the fuck are people actually defending signal for this
Probably because Android (at least) already uses file-based encryption, and the files stored by apps are not readable by other apps anyways.
And if people had to type in a password every time they started the app, they just wouldn’t use it.
AFAIK Android encrypts entire fs with one key. And ACL is not encryption.
Popular encrypted messaging app Signal is facing criticism over a security issue in its desktop application.
Emphasis mine.
I think the point is the developers might have just migrated the code without adjustments since that is how it was implemented before. Similar to how PC game ports sometimes run like shit since they are a close 1-1 of the original which is not always the most optimized or ideal, but the quickest to output.
Been a few days since using electron, but AFAIK electron can’t be used as a wrapper for android apps, or can it? Or is their android app a web app wrapped into a “native” android app too?
Also, since this seems to be an issue since 2018, 6 years should be plenty to rewrite using a native secure storage…
You. Don’t. Store. Secrets. In. Plaintext.
SSH stores the secret keys in plaintext too. In a home dir accessible only by the owning user.
I won’t speak about Windows but on Linux and other Unix systems the presumption is that if your home dir is compromised you’re fucked anyway. Effort should be spent on actually protecting access to the home personal files not on security theater.
Kinda expected the SSH key argument. The difference is the average user group.
The average dude with a SSH key that’s used for more than their RPi knows a bit about security, encryption and opsec. They would have a passphrase and/or hardening mechanisms for their system and network in place. They know their risks and potential attack vectors.
The average dude who downloads a desktop app for a messenger that advertises to be secure and E2EE encrypted probably won’t assume that any process might just wire tap their whole “encrypted” communications.
Let’s not forget that the threat model has changed by a lot in the last years, and a lot of effort went into providing additional security measures and best practices. Using a secure credential store, additional encryption and not storing plaintext secrets are a few simple ones of those. And sure, on Linux the SSH key is still a plaintext file. But it’s a deliberate decision of you to keep it as plaintext. You can at least encrypt with a passphrase. You can use the actual working file permission model of Linux and SSH will refuse to use your key with loose permissions. You would do the same on Windows and Mac and use a credential store and an agent to securely store and use your keys.
Just because your SSH key is a plaintext file and the presumption of a secure home dir, you still wouldn’t do a ~/passwords.txt.
SSH has encrypted keys
Not true, SSH keys need their passphrase to be used. If you don’t set one, that’s on you.
Well yes, but also how would users react if they had to type in their passphrase every time they open the app? This is also exactly what we’re giving up everywhere else by clicking ‘remember this device’.
If someone gets access they can delete your keys, or set up something that can intercept your keys in other ways.
The security of data at rest is just one piece of the puzzle. In many systems the access to the data is considered much more important than whether the data itself is encrypted in one particular scenario.
Come on, 95% of users don’t set passwords on their ssh keys
Where are these stays from lmao.
Counting my friends
You can count me too
If someone has access to your machine you are screwed anyway. You need to store the encryption key somewhere
Yes, in your head, and in your second factor, if possible, keeping them always encrypted at rest, decrypting at the latest possible moment and not storing (decrypted) secrets in-memory for longer than absolutely necessary at use.
You. Don’t. Store. Secrets. In. Plaintext.
Ok. Enter password at every launch.
Does anyone know how iMessage handles this on desktop (on Macs) as they (as far as I know) upgraded their encryption recently?
Alternative headline: Someone has a feature request for Signal which would be of interest to a few people with very specific security needs.
You mean the types of people who would use signal to communicate with others?
It’s not a bad feature to ensure that eg if there’s a malicious process running on your computer it can’t send all your signal data to whomever
Needing to enter a secure passphrase each time you want to use signal in exchange for one more fragile layer of defence for that one part of your data in a scenario that would normally mean you’ve already lost unless you’re running a super-secure compartmentalized operating system like qubes or something is probably not worth it for most people.
I already enter a passphrase every time I want to use Signal; I use the Molly client on my phone. It’s really not a big deal. I also enter a passphrase every time I launch my password manager, every time I launch my two-factor authentication app on my phone, and every time I open my email client. I think it’s fairly standard to protect sensitive data on your computer with encryption at rest and to decrypt it upon launching the application that handles the data.
It’s really not a big deal
For most casual users, it is a deal-breaker. And it’s hard to get everyday people to use your software with roadblocks like that.
every time I open my email client.
You must not get email very often, this is absolutely a non-starter for me.
For most casual users, it is a deal-breaker. And it’s hard to get everyday people to use your software with roadblocks like that.
That’s fair enough, but the way the mobile app works is that you can opt in to having encryption at rest with a passphrase, so if you want to leave your signal database unencrypted you can.
You must not get email very often, this is absolutely a non-starter for me.
Once you open it you can leave it open if you need notifications. Sometimes I leave it open, sometimes I just want to check my emails and then close it. Idk, I really think typing in a password for authentication/decryption regularly is such a non-issue, like for instance do you not regularly type in a password when you run a command with sudo? Again, if it’s opt-in I also don’t see the issue, except for the issue of allowing people to not encrypt their Signal data thus potentially compromising the people they’re messaging, but obviously that issue is currently universal for Signal desktop.
This has nothing to do with the mobile app, which also has password/biometric unlocking, it’s about the desktop electron app.
I know. I never said it was about the mobile app?
You did but it says “desktop” right in the page title.
I’m now genuinely not sure what you’re saying. I did what? I said it was about the mobile app? I didn’t say it was about the mobile app?
Huh. I would’ve thought most desktop users just leave it running all day long like I do. Obviously there is the disk encryption passphrase at boot, adding another one for signal would in my case be redundant.
But the point is not only how easy it is to enter a passphrase, but also how much security that actually gains you. I don’t think it does much on the typical desktop, be it windows or linux, where there are so many ways to escalate or persist privilege for anyone that has user-level access.
I would’ve thought most desktop users just leave it running all day long like I do.
They do. OP is not a normal user.
Obviously there is the disk encryption passphrase at boot, adding another one for signal would in my case be redundant.
I also have full disk encryption, but I still have some databases on my disk encrypted because I decrypt my disk when I boot my computer. But yeah if you have Signal open (& its db decrypted) all the time it would probably be minimal. I don’t have Signal open all the time though, only when I want to check messages or am actively using it
I don’t think it does much on the typical desktop, be it windows or linux, where there are so many ways to escalate or persist privilege for anyone that has user-level access.
The point would be encryption, even the root user wouldn’t be able to read encrypted data if they don’t have the passphrase
If you have root, intercepting all the user’s keystrokes is trivial.
You are telling me this has been going on for almost a decade now, and no one ever noticed ?
So we trust open source apps under the premise that if malicious code gets added to the code, at least one person will notice ? Here it shows that years pass before anyone notices and millions of people’s communications could have been compromised by the world’s most trusted messaging app.
I don’t know which app to trust after this, if any?
Matrix. You can host any version you want, and when you have to update, just do a version diff between you current and latest versions and check yourself.
Everyone knew that already tbh
Why is this a shock? Someone would need to have already compromised your device. Even if it was encrypted with a password they still could install a key logger
It is easier to compromise a device than to try and compromise encrypted communications.
Sure, I was aware. You have the same problem with ssh keys, gpg keys and many other things
However, you can save encrypted ssh, gpg keys and save that encryption key in the OS keyring.
Yes, but you STILL need to enter password on every reboot.
Is it possible to seamlessly integrate, so when something requests those keys you’ll get a prompt?
With SSH at least you can password protect the key itself so that you always get a prompt.
Nice, didn’t know, I’ll look into it
I have three things to say:
- Everyone, please make sure you’ve set up sound disk encryption
- That’s not a suprise (for me at least)
- It’s not much different on mobile (db is unecrypted) - check out molly (signal fork) if you want to encrypt it. However encrypted db means no messages until you decrypt it.
Signal has so many red flags that I’m beginning to wonder if it is a honeypot.
Got some sources for that, chief?
What other red flags do you have in mind?
Back when the Signal org used to be called Open Whisper Systems it received grants and auditing from the Open Technology Fund which, at the time, was still a part of Radio Free Asia.
https://web.archive.org/web/20150521181458/https://www.opentechfund.org/project/open-whisper-systems
So tldr, since you didn’t finish your thought, is that they got a grant like 3+ layers down, from the US government.
I have some news for you, or perhaps I can offer you a bridge.
People are free to draw their own conclusions from it. Do you have anything material to contribute, or will you just be putting more smarmy words in my mouth from here on out?
Attack the argument, not the person.
You didn’t explain the implications of what radio free Asia is, I did. I don’t know what words I’m putting in your mouth.
Signal is actively hostile to alternative clients, or decoupling from Google.
They could just add a password
Why is Signal almost universally defended whenever another security flaw is discovered? They’re not secure, they don’t address security issues, and their business model is unsustainable in the long term.
But, but, if you have malware “you have bigger problems”. But, but, an attacker would have to have “physical access” to exploit this. Wow, such bullshit. Do some of you people really understand what you’re posting?
But, but, “windows is compromised right out of the box”. Yes…and?
But, but, “Signal doesn’t claim to be secure”. Fuck off, yes they do.
But, but, “just use disk encryption”. Just…no…WTF?
Anybody using Signal for secure messaging is misguided. Any on of your recipients could be using the desktop app and there’s no way to know unless they tell you. On top of that, all messages filter through Signal’s servers, adding a single-point-of-failure to everything. Take away the servers, no more Signal.
What app stops a pre install keylogger. I’m all for hearing criticism of Signal but it’s always about things they can’t control.
They can’t control if the encryption keys are stored in plaintext?
Whats the next best alternative?
I can find the desktop client, am I missing something?
You’re right, there isn’t one, my apologies; I edited the comment.
You could use some kind of encrypted container on the desktop though, or maybe run it as a separate user that has an encrypted home folder. The problem is you need to define a threat model first. Depending on what you’re afraid of, any particular “solution” could either be way overkill, or never enough.
Meeting in person.
I’ll organise a time and place to meet in person via … Carrier pigeon?
We’re citizens raging against phones Lazlow.
With a helicopter over you, loud music next to you, and a dude mowing next to you.
And no smartphone in your pocket, of course.
That depends on your threat model. What are you worried about?
Matrix or xmpp, bonus points with a personal server
Thanks to interest of late, the conversations and gajim apps have come a long way in recent years, and matrix has made good strides too with element-x
I would only ever suggest matrix if you’re running a private self-hosted instance that is NOT federated, which you can do even easier with Signal anyways.
That’s fine, but why?
It is a privacy and GDPR nightmare, basically all federated services right now are.
https://github.com/libremonde-org/paper-research-privacy-matrix.org/blob/master/part1/README.md
https://web.archive.org/web/20240611200030/https://hackea.org/notas/matrix.html
https://anarc.at/blog/2022-06-17-matrix-notes/
https://web.archive.org/web/20210804205638/https://serpentsec.1337.cx/matrix
I’d tried matix but without a high level of technical experience it was pretty difficult to setup. I got as far as docker, that needed ansible, that wouldn’t compile. I also recall there was services I could pay for, but then I’d rely on them to provide the security/servers.
Matrix doesn’t seem for the majority of people taking a first step away from big tech.
Snikket is meant to be super simple to self-host. Ejabberd has a web GUI that can make configuration easier.
98% of desktop apps (at least on Windows and Linux) are already broken by design anyways. Any one app can spy on and keylog all other apps, all your home folder data, everything. And anyone can write a desktop app, so only using solutions that (currently) don’t have a desktop app version, seems silly to me.
I don’t think apps can read keystrokes for other apps on Wayland.
Unless you have root
If you have root you could just update the kernel to one that lets you do whatever you want on the system, so there’s no way to stop the attacker from viewing the passwords if the app is capable of displaying them.
Wayland doesn’t magically make other kinds of keyloggers stop working altogether though.
https://old.reddit.com/r/linux/comments/23mj49/wayland_is_not_immune_to_keyloggers/
https://github.com/Aishou/wayland-keylogger
https://github.com/schauveau/sway-keylogger
https://old.reddit.com/r/kde/comments/11h5tvl/wayland_security_keyloggers_are_back/
Linux has a sandbox solution growing in popularity, flatpak.
And Wayland. Xorg is a complete and utter mess
But, but, “just use disk encryption”. Just…no…WTF?
So not encrypting keys is bad, but actually encrypting them is bad too? Ok.
Any on of your recipients could be using the desktop app and there’s no way to know unless they tell you.
Another applefan? How it THIS supposed to be in scope of E2EE? Moreover, how having a way to know if recepient is using desktop app is not opposite of privacy?
On top of that, all messages filter through Signal’s servers, adding a single-point-of-failure to everything. Take away the servers, no more Signal.
Indeed. This is why I use Matrix. Also, fuck showing phone numbers to everyone(I heard they did something about it) and registration with phone numbers.
Any “secure” so that relies on someone else for security is not secure.
Fuck the scope of E2EE. Signal makes a lot of claims on their website that are laughable. The desktop app is their main weakness. Attachments are stored unencrypted, keys in plaintext. If they were serious about security, they would depricate the windows app and block it from their servers.
WTF does Apple have to do with anything?
Any “secure” so that relies on someone else for security is not secure.
Fuck the scope of E2EE.
When someone has FSB/NSA agent behind them reading messages, no amount of encryption will help. Biggest cybersecurity vulnreability is located between monitor and chair. When you are texting someone else, that someone else’s chair-monitor space is also vulnreable.
Signal makes a lot of claims on their website that are laughable.
Well, maybe. I didn’t read their claims, nor I use signal.
Attachments are stored unencrypted, keys in plaintext.
Is OS-level encryption plaintext or not? If yes, then they are encrypted, provided user enables such feature in OS. If not - nothing if encrypted fundamentally.
If they were serious about security, they would depricate the windows app and block it from their servers.
WTF does Apple have to do with anything?
You just used applefans’ argument. Yeah, I wonder what.
Well, maybe. I didn’t read their claims, nor I use signal.
Your opinions are invalid.
Now replace “signal” in your comment with “ssh” and think it over.
It’s true, anyone using SSH for secure messaging is absolutely misguided.
Ah the old Lemmy SHHwitcharoo.
SSHwitcharoo
Thank you.
Basically for the same reason people often defend apple: the user interface is shiny, and they claim to be privacy oriented.
Signal is a centralized US hosted service, that alone should be enough to disqualify it, outside of our many other criticisms.
If someone can read my Signal keys on my desktop, they can also:
- Replace my Signal app with a maliciously modified version
- Install a program that sends the contents of my desktop notifications (likely including Signal messages) somewhere
- Install a keylogger
- Run a program that captures screenshots when certain conditions are met
- [a long list of other malware things]
Signal should change this because it would add a little friction to a certain type of attack, but a messaging app designed for ease of use and mainstream acceptance cannot provide a lot of protection against an attacker who has already gained the ability to run arbitrary code on your user account.
https://molly.im/ already restores the encryption to this file and adds other useful things
Those are outside Signal’s scope and depend entirely on your OS and your (or your sysadmin’s) security practices (eg. I’m almost sure in linux you need extra privileges for those things on top of just read access to the user’s home directory).
The point is, why didn’t the Signal devs code it the proper way and obtain the credentials every time (interactively from the user or automatically via the OS password manager) instead of just storing them in plain text?
Feel free to submit a pull request. We could use your help.
I don’t see the reasoning in your answer (I do see its passive-aggressiveness, but chose to ignore it).
I asked “why?”; does your reply mean “because lack of manpower”, “because lack of skill” or something else entirely?
In case you are new to the FOSS world, that being “open source” doesn’t mean that something cannot be criticized or that people without the skill (or time!) to submit PRs must shut the fu*k up.
It’s in the draft phase from what I can see.
You’d need write access to the user’s home directory, but doing something with desktop notifications on modern Linux is as simple as
dbus-monitor "interface='org.freedesktop.Notifications'" | grep --line-buffered "member=Notify\|string" | [insert command here]Replacing the Signal app for that user also doesn’t require elevated privileges unless the home directory is mounted
noexec.They’re arguing a red herring. They don’t understand security risk modeling, argument about signals scope let’s their broken premise dig deeper. It’s fundamentally flawed.
It’s a risk and should be mitigated using common tools already provided by every major operating system (ie. Keychain).
“Highways shouldn’t have guard rails because if you hit one you’ve already gone off the road anyway.”
Not necessarily.
https://en.m.wikipedia.org/wiki/Swiss_cheese_model
If you read anything, at least read this link to self correct.
This is a common area where non-security professionals out themselves as not actually being such: The broken/fallacy reasoning about security risk management. Generally the same “Dismissive security by way of ignorance” premises.
It’s fundamentally the same as “safety” (Think OSHA and CSB) The same thought processes, the same risk models, the same risk factors…etc
And similarly the same negligence towards filling in holes in your “swiss cheese model”.
“Oh that can’t happen because that would mean x,y,z would have to happen and those are even worse”
“Oh that’s not possible because A happening means C would have to happen first, so we don’t need to consider this is a risk”
…etc
The same logic you’re using is the same logic that the industry has decades of evidence showing how wrong it is.
Decades of evidence indicating that you are wrong, you know infinitely less than you think you do, and you most definitely are not capable of exhaustively enumerating all influencing factors. No one is. It’s beyond arrogant for anyone to think that they could 🤦🤦 🤦
Thus, most risks are considered valid risks (this doesn’t necessarily mean they are all mitigatable though). Each risk is a hole in your model. And each hole is in itself at a unique risk of lining up with other holes, and developing into an actual safety or security incident.
In this case
- signal was alerted to this over 6 years ago
- the framework they use for the desktop app already has built-in features for this problem.
- this is a common problem with common solutions that are industry-wide.
- someone has already made a pull request to enable the electron safe storage API. And signal has ignored it.
Thus this is just straight up negligence on their part.
There’s not really much in the way of good excuses here. We’re talking about a run of the mill problem that has baked in solutions in most major frameworks including the one signal uses.
I was just nodding along, reading your post thinking, yup, agreed. Until I saw there was a PR to fix it that signal ignored, that seems odd and there must be some mitigating circumstances on why they haven’t merged it.
Otherwise that’s just inexcusable.
The PR had some issues regarding files that were pushed that shouldn’t have been, adding refactors that should have been in separate PRs, etc…
Though the main reason is that Signal doesn’t consider this issue a part of their threat model.
Anybody using Signal for secure messaging is misguided. Any one of your recipients could be using the desktop app and there’s no way to know unless they tell you.
That’s why I only communicate face-to-face inside of a soundproofed faraday cage.
If the app manages the keys, then you can’t trust the app.
If the recipient manages their own keys, then you can’t trust the recipient.
Encryption is fundamentally insecure. Once I encrypt something, nobody should be able to decrypt it ever again.
I hope you are joking
The backlash is extremely idiotic. The only two options are to store it in plaintext or to have the user enter the decryption key every time they open it. They opted for the more user-friendly option, and that is perfectly okay.
If you are worried about an outsider extracting it from your computer, then just use full disk encryption. If you are worried about malware, they can just keylog you when you enter the decryption key anyways.
The third option is to use the native secret vault. MacOS has its Keychain, Windows has DPAPI, Linux has has non-standardized options available depending on your distro and setup.
Full disk encryption does not help you against data exfil, it only helps if an attacker gains physical access to your drive without your decryption key (e.g. stolen device or attempt to access it without your presence).
Even assuming that your device is compromised by an attacker, using safer storage mechanisms at least gives you time to react to the attack.
Linux has the secret service API that has been a freedesktop.org standard for 15 years.
Secret service API. Damn. That’s how FSB knows what it knows.
A better thing to be worried about IMO is that Signal contains proprietary code. Also to my knowledge nobody is publicly verifying the supposed “reproducible builds” if they even still exist.
The alternative is safeStorage, which uses the operating system’s credential management facility if available. On Mac OS and sometimes Linux, this means another process running in the user’s account is prevented from accessing it. Windows doesn’t have a protection against that, but all three systems do protect the credentials if someone copies data offline.
Signal should change this, but it isn’t a major security flaw. If an attacker can copy your home directory or run arbitrary code on your device, you’re already in big trouble.
This just in: threat actors compromising your devices is bad. More at 11.
Obviously the keys could be stored more securely, but if you’ve got malware on your machine that can exploit this you’ve already got bigger problems.
That’s not how this works.
This sort of “dismissive security through ignorance” is how we get so many damn security breaches these days.
I see this every day with software engineers, a group that you would think would be above the bar on security. Unfortunately a little bit of knowledge results in a mountain of confidence (see Dunning Kruger effect). They are just confident in bad choices instead.
“We don’t need to use encryption at rest because if the database is compromised we have bigger problems” really did a lot to protect the last few thousand companies from preventable data exfiltration that was in fact the largest problem they had.
Are you confident in your omnipotence in that you can enumerate all risks and attack factors that can result in data being exfiltrated from a device?
If not, then why comment as if you are?
Whatever its stores and however it stores it doesn’t matter to me: I moved its storage space to my ~/.Private encrypted directory. Same thing for my browser: I don’t use a master password or rely on its encryption because I set it up so it too saves my profile in the ~/.Private directory.
See here for more information. You can essentially secure any data saved by any app with eCryptfs - at least when you’re logged out.
Linux-only of course. In Windows… well, Windows.
Or ext4 encrytion. Which is overpowered. You can have different keys for different files and directories.
So many better standards like XMPP and IRC yet people use Signal and Telegram. I hate marketing.
Signal is an objectively better experience than xmpp, and has about identical security (same with matrix). Irc isn’t secure afaik. Telegram isn’t secure afaik.
A better wish would be that people in 2024 would stop being fuckign weird about their cell number. Some people don’t want to give it out despite white pages being the standard for years (and how the Terminator knows who to kill). Other people refuse to use a messaging app where they can’t use their phone to sign up. Some people want to sign up with their number but not give it out.
