That is an intriguing feature request. Most disposable services avoid outgoing mail entirely to prevent being abused for spam, but a strict 'Reply-Only' policy (where you can only send to the address that just emailed you) is a clever middle ground.
Implementing this while maintaining the zero-persistence architecture would require a secure, ephemeral SMTP relay. It’s definitely a complex challenge, but the value it adds for verifying accounts that require a response is huge. I’m adding this to the experimental roadmap!
All of these domains are already widely known because Guerrilla Mail are the ones actually running the email service, his website is a wrapper with a CORS proxy.
He doesn't own or operate the cors proxies, mail infra, domains or the api
guilty of using ai studio for the fast prototype lol but the 145 users today caught me off guard... im working on a clean production build right now to move away from the google cdn stuff. just trying to build a better ui for these apis without all the bloat and tracking! thanks for the heads up
thanks for the links sixtyj. the cat and mouse game with these lists is never ending... i agree that the ethical use cases like whistleblowing are why these tools need to exist. its a tough balance to keep them accessible but not abused.
To be fair, in some Russian regions you cannot access even most Russian sites from mobile (we have whitelist mode). Also, not everyone, but some people started using VPN after Instagram ban, and even more after Youtube ban. Like drug addicts who cannot drop their habits.
In my country, you cannot legally get a phone number not linked to the identity, and the prices are relatively high on the black market. Also, the phone discloses your location with pretty good precision, especially in US where everyone is living in their own house.
> What’s going on in that user object? The pin field seems suspiciously related to the PIN we were asked to input after creating our account
This might be the fault of opt-out serialization library (by default it serializes the whole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.
Or they are just using plain JS dicts on the server and forgot to remove the key before using it in a response.
> The vulnerability they’re talking about was presented in a paper by researchers at the University of Vienna.
This vulnerability (mapping phone numbers to user id via rendevouz API) is old and was exploited in 2016 in Telegram [1] and allowed Iranian govt to build a phone book of 15M Telegram users. The paper also mentions that the vulnerability was known in 2012, still not fixed.
> This might be the fault of opt-out serialization library (by default it serializes the hole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.
In a previous job, on my first audit of the code, I spotted such vulnerabilities pretty much everywhere.
Developers simply need to stop using these libraries.
This is such a common issue I've seen in so many API backends, where sensitive fields on a record are getting sent to the client and no one notices because it's invisible in the UI.
The fact that the PIN is leaked is bad enough, but it also happens to be plaintext. This is a password. It should not be stored unhashed, and it should be hashed with strong algorithms.
There is never a need to store a pin in the database, store it in temporary storage like redis. Set the TTL to the expiration date. You can hash if needed, but I’m less concerned that someone hacks into your reds instance and steals your pins from the last 10 minutes, bc everything else is gone.
There should never be a need to return a pin to the client. You’ve already texted/emailed it to them. They are going to send it back to you. You will check against your temporary storage, verify/reject, and delete it immediately after.
Sure. But why are we blaming libraries. This is the development process. Are BE developers not looking at their output anymore? Are we just vibe coding everything? If the UI does not complain then go to prod? This can’t be the expectation. And then you claim that your app is secure. Based on what review. Does not look like you even did an internal review?
If you’re going to design a PIN feature, and don’t consider securing it, what part of design did you do?
I keep seeing people try to explain away incompetence by blaming unaccountable things aka the tool or system. Exposed password? Must be the library. People really should stop using it. No, the library is not wrong, ppl should be better developers.
Peer reviewed paper is full of AI slop, must not be the reviewer’s fault, the citations were there, they were just fake. What is going on?
The PIN can be longer than four digits. Signal also guards against this with safety numbers; if someone takes over an account, every contact will see that the safety number has changed and should consider that the account may be compromised until verifying out of band.
Google Voice doesn't look like a safe option, your number can be taken away if you forget to pay or you can be banned for arbitrary reason without a way to appeal.
Does Signal protect from the scheme when the government sends discovery requests for all existing phone numbers (< 1B) and gets a full mapping between user id and phone number?
While slightly unrelated, I thought, how we can fix this for truly secure and privacy-aware, non-commercial communication platforms like Matrix? Make it impossible to build such mapping. The core idea is that you should be able to find the user by number only if you are in their contact list - strangers not welcome. So every user, who wishes to be discovered, uploads hash(A, B) for every contact - a hash of user's phone number (A) and contact's phone number (B), swapped if B < A. Let's say user A uploaded hashes h(A,B) and h(A,C). Now, user B wishes to discover contacts and uploads hashes h(A, B) and h(B, D). The server sees matching hashes between A and B and lets them discover each other without knowing their numbers.
The advantages:
- as we hash a pair of 9-digit numbers, the hash function domain space is larger and it is more difficult to reverse the hashes (hash of a single phone number is reversed easily)
- each user can decide who may discover them
Disadvantages:
- a patient attacker can create hashes of A with all existing numbers and discover who are the contacts of A. Basically, extract anyone's phone book via discovery API. One way to protect against this would be to verify A's phone number before using discovery, but the government, probably, can intercept SMS codes and pass the verification anyway. However, the government can also see all the phone calls, so they know who is in whose phone book anyway.
- if the hash is reversed, you get pairs of phone numbers instead of just one number
Yeah you're doing a lot better job on the privacy side than signal is IMO.
Especially just being able to run my own service will be priceless when something like chatcontrol eventually makes it through. Signal can only comply or leave, but they'll never manage to kill all the matrix servers around.
Signal publicly shares government requests AND the data that they send them
The data Signal has is: 1) registration time for a given phone number, 2) knowledge of daily login (24hr resolution). That's it. That's the metadata.
They do not have information on who is communicating with who, when messages are sent, if messages are sent, how many, the size, or any of that. Importantly, they do not have an identity (your name) associated with the account nor does that show for contacts (not even the phone number needs be shared).
Signal is designed to be safe from Signal itself.
Yes, it sucks that there is the phone number connected to the account, but you can probably understand that there's a reason authorities don't frequently send Signal data requests; because the information isn't very useful. So even if you have a phone number associated with a government ID (not required in America) they really can only show that you have an account and potentially that the account is active.
Like the sibling comment says, there's always a trade-off. You can't have a system that has no metadata, but you can have one that minimizes it. Signal needs to balance usability and minimize bots while maximizing privacy and security. Phone numbers are a barrier to entry for bots, preventing unlimited or trivial account generation. It has downsides but upsides too. One big upside is that if Signal gets compromised then there's can be no reconstruction of the chat history or metadata. IMO, it's a good enough solution for 99.9% of people. If you need privacy and security from nation state actors who are directly targeting you then it's maybe not the best solution (at least not out of the box) but otherwise I can't see a situation where it is a problem.
FWIW, Signal does look to be moving away from phone numbers. They have usernames now. I'd expect it to take time to completely get away though considering they're a small team and need to move from the existing infrastructure to that new one. It's definitely not an easy task (and I think people frequently underestimate the difficulty of security, as quoted in the article lol. And as suggested by the op: it's all edge cases)
> Phone numbers are a barrier to entry for bots, preventing unlimited or trivial account generation.
What's wrong with account generation? Nothing. The problem is if they start sending spam to random people. So we can make registration or adding contacts paid (in cryptocurrency) and the problem is gone.
>So we can make registration or adding contacts paid (in cryptocurrency) and the problem is gone.
The majority of the user base would be gone, too.
I had a hard enough time convincing my friend group to use Signal as is. If they had to pay (especially if it had to be via cryptocurrency) none of them would have ever even considered it.
I would rather pay $1 than with my phone number which is much much much more valuable. Telegram did an experiment with paid anonymous registration, but the prices were ridiculous and targeted for the riches.
What's right with it? Accounts being generated (i.e. many inauthentic accounts controlled by few people) are always used to send spam, there are no exceptions. The perpetrators should be in prison.
Ah yes, and convincing friends/family/partners to use Signal instead of Whatsapp clearly what will convince them is that they need to setup, acquire, and use cryptocurrency to register or connect with me on the encrypted messaging service. "No thanks, I just use Whatsapp/iMessage. I heard they're actually e2e encrypted too, so what's the problem?"
> Does Signal protect from the scheme when the government sends discovery requests for all existing phone numbers (< 1B) and gets a full mapping between user id and phone number?
Signal does have the phone numbers, as you say. Can they connect a number to a username?
>>> Does Signal protect from the scheme when the government sends discovery requests for all existing phone numbers (< 1B) and gets a full mapping between user id and phone number?
Which yes, this does protect that. There is no mapping between a user id and phone number. Go look at the reports. They only show that the phone number has a registered account but they do not show what the user id is. Signal doesn't have that information to give.
> Can they connect a number to a username?
From Signal
Usernames in Signal are protected using a custom Ristretto 25519 hashing algorithm and zero-knowledge proofs. Signal can’t easily see or produce the username if given the phone number of a Signal account. Note that if provided with the plaintext of a username known to be in use, Signal can connect that username to the Signal account that the username is currently associated with. However, once a username has been changed or deleted, it can no longer be associated with a Signal account.
This is in the details on[0] right above the section "Set it, share it, change it"
So Signal cannot use phone numbers to identify usernames BUT Signal can use usernames to identify phone numbers IF AND ONLY IF that username is in active use. (Note that the usernames is not the Signal ID)
If you are worried about this issue I'd either disable usernames or continually rotate them. If the username is not connected with your account at the time the request is being made then no connection can be made by Signal. So this is pretty easy to thwart, though I wish Signal included a way to automate this (perhaps Molly has a way or someone can add it?) Either rotating after every use or on a timer would almost guarantee that this happens given that it takes time to get a search warrant and time for Signal to process them. You can see from the BigBrother link that Signal is not very quick to respond...
These services are a good because sometimes you need to access some information in social networks, which is available only after registration. So what other choices you have? And they often do not even allow registration from desktop:
- Google requires to scan QR code with a phone to create an account
- Facebook requires a 3D face scan
- VK requires to use mobile application
- Telegram requires to use mobile application
Desktop now feels like untrusted, shady device, used mostly by cybercriminals. Especially of you use Linux and enable "fingerprinting resistance" option.
> To register a new account, online platforms require SMS (Short Message Service) verification
Incorrect, see above.
> A fake Facebook account registered in Russia can post about the US elections
Facebook is blocked in Russia though.
As for spam problems, require payment to add new contacts above the limit, and disable messaging to non-contacts. Or restrict messaging based on country/city (so that messaging to a different country is paid).
> The average price of SMS verification for an online platform during the year-long study period running to July 2025 was ... just a fraction of that in the US ($0.26), UK ($0.10) and Russia ($0.08).
That's outdated. With new Russian legislation, most platforms removed support for Russian phone numbers, so now you cannot even find a service that allows to receive SMS to a Russian number. Futhermore, if you Google such services, it seems that they use the same provider because all of them do not have any working Russian numbers.
> As for spam problems, require payment to add new contacts above the limit, and disable messaging to non-contacts. Or restrict messaging based on country/city (so that messaging to a different country is paid).
This just a) increases the costs for attackers, which don't actually stop them; and b) means the poor amongst a population will be limited in who they can talk to. Very convenient, that. Don't want your peasants talking to citizens from other countries.
>And they often do not even allow registration from desktop:
You probably have a super suspicious browser fingerprint and/or IP reputation and they're using those measures as a mitigation without denying outright. Use a normie browser and a normal internet connection and account creation works fine.
That's a good reason for not carrying a phone, but getting a cheap SIM-connected device and leaving it at home next to their computer shouldn't reveal any more information than they already are by using their home internet and VOIP.
