Facebook Sucks: Huge 500M-User Breach ‘Is Your Fault’

Last week’s revelation of a half-billion-user leak is still reverberating around the news cycle. Despite Facebook’s attempts to make it go away, new inconvenient truths keep appearing.

Such as the new timeline that means the leak is actually subject to GDPR’s reporting requirements (with a penalty that could run into billions). And also Facebook’s new, unbelievably tone-deaf PR statement—which translates as, “It’s not our fault for failing to secure your data—it’s your fault for giving it to us.”

This is bad. I can’t watch. But I can’t not watch. In today’s SB Blogwatch, we break out the jumbo bag of popcorn.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: SMPTE/BITC nonsense.

GDPR: Coming for Mark’s Money

What’s the craic? Hey, Lily Hay Newman—“What Really Caused Facebook’s 500M-User Data Leak?”:

 Since Saturday, a massive trove of Facebook data has circulated publicly, splashing information from roughly 533 million Facebook users across the internet. The data includes things like profile names, Facebook ID numbers, email addresses, and phone numbers.

Facebook’s initial response was simply … old news … that the data was previously reported on. [But] in fact, the data … came from a breach that Facebook did not disclose in any significant detail.

One source of the confusion was that Facebook has had any number of breaches and exposures from which this data could have originated. [But this] is an entirely different data set, [which] attackers created by abusing a flaw in a Facebook address book contacts import feature.

If all of this feels exhausting to sort through, it’s because Facebook went days without giving a substantive answer and has left open some degree of confusion. … The Irish Data Protection Commission said … it “received no proactive communication from Facebook” regarding the breach.

The one thing that’s certain … is that more than 500 million Facebook users are less safe online than they otherwise would be. [They’re] potentially vulnerable to a new wave of scams and phishing that Facebook could have alerted them to nearly two years ago.

Yikes. Natasha Lomas piles on—“Facebook’s tardy disclosure … raises GDPR compliance questions”:

 The question of whether Facebook will face any regulatory sanction over the latest massive historical platform privacy fail … remains unclear. But the timeline of the incident looks increasingly awkward.

While it initially sought to play down the data breach revelations … the tech giant finally revealed that the data in question had in fact been scraped from its platform by malicious actors “in 2019.” … Facebook followed up the Irish Data Protection Commission (DPC)’s statement by confirming … the data had been extracted from its platform in 2019.

That new detail … raises the issue of compliance with … GDPR — which came into application in May 2018. … In its PR response … Facebook quickly claimed it had fixed this vulnerability in August 2019. But [the] timing places the incident squarely in the period of GDPR being active. … Facebook made no disclosure at all of this incident to the DPC. … Data controllers can face fines of up to 2% of their global annual [gross revenue] for failures to notify.

Legal risk attached to the breach likely explains why Facebook has studiously avoided describing this … as a ‘breach’ … instead [referring] to data being “scraped.” … This is an argument as obviously absurd as it is viciously hostile to people’s rights and privacy. [But it] likely feels confident in keeping on with this tactic because it’s faced relatively little regulatory sanction for an endless parade of data scandals.

The company declined to comment [saying] it would not be commenting on its communications with regulators. … Facebook also said it does not have plans to notify users either. … Perhaps the company’s trademark ‘thumbs up’ symbol would be more aptly expressed as a middle finger.

Wheel in the sacrificial Facebook PR spokesbot. Step forward Mike Clark, who apparently drew the short straw—“The Facts on News Reports”:

 We have teams dedicated to addressing these kinds of issues. … Scraping is a common tactic [used by] fraudsters who intentionally break platform policies. … We can’t always prevent data sets like these from recirculating or new ones from appearing.

It’s always good for everyone to make sure that their settings align with what they want to be sharing publicly. In this case, [by] updating the “How People Find and Contact You” control. … We also recommend people do regular privacy checkups to make sure that their settings are in the right place.

tl;dr: It’s not our fault, it’s yours? Graham Cluley concludes, “Facebook isn’t sorry”:

 Facebook’s initial response to media queries was curt and dismissive. … It was also inaccurate.

The data isn’t old. … For most people the leaked data is current. It’s still data that could be exploited. … Data such as an individual’s phone number can be extremely dangerous … (imagine if it fell into the hands of a abusive ex-partner, a celebrity stalker, or a SIM swapper).

But here’s the thing: … Nowhere in Facebook’s post will you see an apology. So I can assume that Facebook isn’t sorry. [Yet] half a billion users … have had their details leaked onto the internet – not because of the users’ own fault, but because of Facebook’s incompetence.

And a slightly sarcastic anonymous boring coward is happy to hear it wasn’t a hack:

 That’s so much better! No need even to hack the system, as it was wide open! Really something to be proud of, and point out.

Going deeper, p49k spots the flaw in Facebook’s narrative:

 They claim “scraping” in contexts where it benefits them to use that term (requirement to notify users) and “breach” when it benefits them in other contexts (answering to why private personal info was found online). Sometimes they even claim both in the same sentence. … They absolutely can’t have this both ways.

But this Anonymous Coward kinda agrees with Facebook:

 They’re not wrong. Hear me out, it really isn’t [Facebook’s fault]:

1) It’s not Facebook’s fault you voluntarily signed up and created an account. …
2) It’s not Facebook’s fault you didn’t spend 5-10 minutes going over the privacy settings. …
3) It’s not Facebook’s fault the average user is an idiot that doesn’t bother to read the ToS, where they basically say, “Yah, this is free, but we can do whatever we want with what you share openly, unless you tell us not to.”

It’s honestly getting tiresome to read stories about ‘hackers,’ when what really happened is someone took the time to scrape the publicly available data freely given by the users. At what point do we stop coddling the average end-user stupidity and just plainly state, “Yah, it’s out there, but it’s your fault because you were a dumb***.”

So boublepop taxonomicates thuswise: [You’re fired—Ed.]

 It depends on how you draw the line between scraping and hacking. We can probably agree that if you publish a list of Marvel superheroes and I download it, that is scraping. If you put it behind password protection and I find an error and get it, then it’s hacking.

But if we want to claim this is “just scraping” then Facebook would also be claiming that the there was absolutely not issue in publishing a list of all user accounts and phone numbers in the first place.

Meanwhile, with a dusty cultural reference, it’s Geoffrey.landis:

 The good thing is that if Rikki does lose that number, but has a change of heart, she can find it there in the Facebook dump.

And Finally:

I bet you were wondering, too

Previously in And Finally


You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: DonkeyHotey (cc:by)

Featured eBook
The Dangers of Open Source Software and Best Practices for Securing Code

The Dangers of Open Source Software and Best Practices for Securing Code

More and more organizations are incorporating open source software into their development pipelines. After all, embracing open source products such as operating systems, code libraries, software and applications can reduce costs, introduce additional flexibility and help to accelerate delivery. Yet, open source software can introduce additional concerns into the development process—namely, security. Unlike commercial, or … Read More