I find it extremely hard to believe that this was a bug. Obviously without knowing FBs internals we'll never know, but why you'd write software that would have everything wired up together, your SMS notification service has the ability to post notifications on your behalf? I'm not buying it.
This was either poor engineers, or they're lying. With the quality stuff FB put out (React, Jester, etc), I find the former to be hard to accept.
I'd find it more believable if this wasn't a bug, but something behind a feature toggle that they didn't intend to push live just yet.
> I find it extremely hard to believe that this was a bug.
It reminds me of this comment:
"Whoops, I accidentally inserted 350 lines of code across some .java and .xml files and linked a vendor's library and when my hand slipped I accidentally registered API keys and inserted them into the metadata of the program, and when it went to code review and production release, they accidentally accepted it and uploaded it to their distribution server."
Which is a bit of an exaggeration, when you also include the reply:
"To be fair, HTC has apparently partnered with the 3rd party keyboard TouchPal for their device keyboard, who also do an ad supported version. I can imagine a situation where TouchPal/HTC accidentally released an ad supported build instead of the HTC specific build."
If this is really a bug, I can see this as a human bug or communication issue. They have their standard sms notification system on one place. The creator(s) of the 2FA system saw a phone field on the profile and just pushed the number there when saving the phone as a 2FA without checking that this would be used for notifications as well. The person checking the code sees a phone number coming in, and it being saved into the phone field, so no issue from this point of view.
That's a widespread class of bug (deserving of a short, memorable handle like off-by-one, semantic collision perhaps?), but could it apply here? I'd sure hope that the world's most prominent authentication provider would keep their 2FA more isolated than that from their ad pipes.
The phone number is too important to them for tracking purposes.
It allows them to tie your instagram usage to your facebook account to your whatsapp conversations even if none of them are linked together, and then create a big map of all of the people you interact with on the different platforms.
The more phone number information they have, the more powerful their map.
Fb is big, but you could imagine 2FA involving maybe 3 pairs of eyeballs to get deployed. That, if combined with less of a sensitivity to the distinction between "profile number" and "auth-related number" , would make this bug almost certain to happen.
It seems to be consistent with the explanation that the SMS messaging system has been re-purposed.
Old system: send updates via SMS, post replies onto the wall.
New system: send 2-factor authentication codes.
Now mix both and you get what was happening here.
I bet the engineer who thought of doing that was feeling very smart. Not having to setup a whole new secure SMS delivery infrastructure. It might not be true but I like the irony of it :)
Facebook uses low-priority bugfixes as training tasks for junior developers. It's entirely possible this was somebody 6 weeks out of university who sent the notification to the first phone record they came across. Not many people have different 2fac and SMS numbers set up, so this could easily get through testing.
As for the SMS reply posting back to Facebook, that's been a live feature for about a decade. It was long defunct when 2fac was introduced, so I'm not surprised there are odd interactions there.
Of course. But do you really not know anybody who has fucked up a canary rollout or had a rollback system with a flaw that prevented an automatic rollback?
Why is it easier to believe that Facebook would want to ask for a user’s phone number twice: one for 2 factor verification purposes and one for notification purposes, rather than storing it just once?
Given it was obvious they would get crucified by folks for spamming a 2FA number, why do you believe Alex Stamos and Facebook (a public company with React, Jester, etc.) are now lying to the public rather than this being an actual bug?
I believe that it was a bug, because SMS notifications have been a feature on FB for a very long time. They just haven't been relevant for half a decade due to the introduction of smart phones.
I remember using Facebook via SMS back when I was in high school c. 2010 on a flip phone.
I can't see this as FB trying to push a feature on people, because this feature is so old, almost antiquated. I was surprised to discover that it even existed any more.
It actually could be a bug. And for many other companies I'd be happy to believe them. But just like for bitcoin exchanges 'we've been hacked' is no longer believable FB has a problem when they wish to attribute to accident what could also be attributed to malice. Remember the time when they started messing with the emotional state of their users in the name of an undisclosed scientific experiment? That's roughly when they lost the benefit of the doubt about 'accidents'.
The point is, in case I'm not making it clear enough, that 'accident' is just another convenient excuse to trot out when caught doing something unsavory, tasteless, creepy or downright illegal.
FB has plenty of examples along those lines so I will no longer give them the benefit of the doubt on any claims like these. For that to work you have to have a documented track record of building trust rather than a documented track record of transgressions.
Doing something shitty and doing something shitty then lying about the cause are two different things. I think you're smart enough to know the difference. This is sloppy logic.
It's not about logic, not everything is about logic. It's about breaking trust. FB broke that trust in many ways time and again so now when they trot out the 'bug' cause to me that is just as believable as 'hacker' when a coin exchange claims they lost a few 100 million worth of bitcoins.
It is a common mistake in the tech scene to look at everything through the lens of logic as if life is one giant computer program or a court case. Proof is nice but in some cases it can be optional.
Multi-national with 100's of QA engineers rolls out un-feature that backfires -> 'bug'. I don't buy it. If it's good enough for you then that's fine by me but Facebook has a very long and uphill battle until they reach the benefit of the doubt stage again.
I'm automatically suspicious of headlines that use "admit". It almost always indicates a judgmental pre-conception of the activity rather than unbiased reporting.
If "confirms" or "acknowledges" had been used instead it would be a much more neutral report.
Same company that bought the privacy-oriented communication startup WhatsApp, changed the terms with default opt-in and started feeding data back to themselves.
Bug this time? Maybe. Maybe not.
To me it seems some parts of that company are constantly lying and pushing the boundaries of creepy (while other parts are doing somewhat useful stuff).
It's not just the notifications. I don't like how they require a number for SMS fallback when TOTP is set up.
SMS for 2FA is insecure and I specifically do not want to use it, I only want TOTP. And yet, every single code I generate on my authenticator also gets sent to my SMS number.
It's incredibly annoying. Anyone from Facebook who worked on/with this care to comment?
Reminds me of a seller on Amazon I bought from who misused the customer's phone numbers to ask for reviews (as a seller myself I honestly don't know why Amazon would display them publicly at all). One day I get a 500 character SMS: „Do you want 20 coffee-tabs FOR FREE? Just leave us a 5 star review on XYZ and email xyz@evil.com blablablabalbla“.
Turned out to be the quickest 1 star review I had ever given.
Is "we decided to do this then later decided it was a bad idea" a "bug"? I thought bug implies unintended behavior. Not intended behavior that wasn't fully thought through and may have conflicted with other silos in the org.
You're absolutely right, but the vast majority of facebook's target audience has come to understand that "bug" is synonymous with "oops, we messed up (pay no attention to whether this was intentional or not)"
If a feature is a success, boast about how you created it from the scratch and take all the credit (ofc giving brownie points upwards in the hierarchy).
If a feature is a disaster, claim it's a bug and scorn a developer scapegoat!
Not this excuse again. Everything Facebook has ever been caught doing maliciously was classified as bug - at least until they turned it back on later and called it a "super important security feature the world couldn't live without -
so, you're welcome?!", like they did/are doing with the datr cookies.
They're also going to get caught using people's supposed "face authentication" biometrics (another recent "security feature", which btw is a stupidly reckless feature even when taken at face-value, because biometrics should be stored client-side not in a centralized database where millions of profiles can get hacked at once) for 100% advertising purposes, and they'll probably call it a bug again if there's strong backlash against it, at least until they make sure they can't get caught the next time they do it.
They are probably not lying. If they get sued in a class action lawsuit and this public statement is found to be a fabrication then they will be in way more trouble than this entire issue is causing them in the first place.
"Bug" is a nice wide term covering a lot of things. This could have been a feature that wasn't intended to go live yet. It got exposed early, so that's a bug. Another option: It was supposed to go live everywhere, but only went live in a small area. Still a bug.
> Facebook uses the automated number 362-65, or “FBOOK,”
Without even looking at a phone keypad, how can this make sense? The 3rd and 4th characters can't both be O if they come from different keys. Perhaps they mean 32665?
Why do people keep misusing the word “deprecate”? Everyone I know seems to think deprecate means “to desupport” or to “end functionality” but it means “to discourage its use”. When someone says “we plan to deprecate it soon” they really mean “we plan to remove the feature soon”, since it’s already likely deprecated.
Way back when FB rolled out 2FA, I weighed the additional security of that over a strong random password, versus the obvious downside of them having my phone number. Basically, it was a small chance of some weirdo hijacking an account containing nothing sensitive (FB doesn't have my credit card, either), versus a large chance of a giant ad/surveillance company using my phone number to make money. I ultimately chose not to set up 2FA, and now I think that was a good decision for exactly the reasons I predicted.
I'm also very skeptical of the "bug" explanation, given how persistently they have been asking for my phone number lately.
Yeah I'm sure it's a "bug" that they spam you with irrelevant push notifications ("did you see X commented on Y's photo?") even when you have push notifications turned off in account settings.
I'm sure it's also a bug that the screen on the app that let you select a recent notification and say "don't show me notifications like this" also disappeared
This was either poor engineers, or they're lying. With the quality stuff FB put out (React, Jester, etc), I find the former to be hard to accept.
I'd find it more believable if this wasn't a bug, but something behind a feature toggle that they didn't intend to push live just yet.