Hacker News new | past | comments | ask | show | jobs | submit login

Before gathering up the mob and handing out the torches and pitchforks, you should probably establish what the facts actually are. I don't think the author of this post has really done that.

The way these systems should work, and appear to work in Facebook's case, is that the amount of information revealed depends on risk analysis.

For example, I just tried recovery from an IP I've used Facebook from, and from a fresh IP from a low reputation hosting provider located in a country unrelated to the account. The first case reveals the user's name, but that's pretty reasonable since the request has a decent amount of affinity for the account. The risky looking recovey does not reveal the name,

Both logins show the first letter of the local part of the email address, which is basically no information leakage at all. (Though honestly, if you show just one letter even for non-risky recovery attempts, why bother? It can't possibly be of any significant help to the users.)

I can't tell whether the profile picture changes based on the risk analysis outcome or not, since I don't have a test account with one.

(It's still possible that this is a bad implementation; e.g. if it were to be revealing my username for any recovery attempt from the correct country, that'd be unreasonable since it's trivial to figure out the country from the phone number. But even so one should still establish what the relevant parameters are, so that we can figure out whether the behavior is reasonable.)




It actually says right there on the screenshot "You can see your name and profile picture because you're using a computer network you've logged in on before." So this is only working because the author has used this computer (or one on the same subnet) to log in to his FB account before (private browsing mode does not obscure the IP address). It will not work in the general case.


Are large organization subnets sufficiently masked that this would not work? For example, a university network.


If not, you could possibly use the domain facebook displays for the recovery email (for example x@cornell.edu) to direct you to the network you need to retry from


Facebook does not reveal even a single letter of the recovery email's domain.


The author is a bit late to the party - this used to be a thing. IIRC you could just enter the phone in fb search and it would spit out the name + fb link even for private profiles.

Someone I knew scanned down a whole country's numbers in a couple of months (there was some rate limiting and that's about it) - and that guy just did it for fun. I'm sure there were plenty of shady companies doing the same thing.

After a while FB started cracking down on this. They even admitted they knew about it for years. Can't find a link but IIRC that was 4-5 years ago.


You're right. I just looked up the time frame: in 2017, I did the same thing. It was widely known about and FB took way too long to fix it.


> if you show just one letter even for non-risky recovery attempts, why bother? It can't possibly be of any significant help to the users.

It's of much help to me.

I use different email addresses for different services, and any help the service can give me to ensure I'm giving it the right email I use on it is helpful.


> if you show just one letter even for non-risky recovery attempts, why bother? It can't possibly be of any significant help to the users.

It can be, if you have just a handful of email accounts. Also if you don't recognize the first letter you know you definitely have messed up something.


> (Though honestly, if you show just one letter even for non-risky recovery attempts, why bother? It can't possibly be of any significant help to the users.)

Why? I use multiple email addresses and on these occasions seeing that single letter (at beginning or end) helps me know which account to check for recovery steps. This is significant to me.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: