Facebook bug set 14M users' sharing settings to public

I’m sorry if I came off as pedantic. I believe that the actual principle behind how Facebook represents privacy is relevant to how they could have implemented a solution (because it's not at the level you would expect it to be, unlike the default privacy selector) but I get that this is not what you care about.

I sincerely believe that attracting readers’ attention to the problem without letting the authors’ correct it first would make the problem worst. I expect current Facebook employees to think the same.

Another key aspect to answer your question: the list of people who saw a post (or paid significant attention to) is also probably not an information that Facebook can easily access: there are aggregates streamed for ads, but gathering that information for non-sponsored posts would be genuinely hard, if not impossible in some aspects.

Even though Facebook prides itself on allowing people to speak freely, and has encouraged more open communication by default in the past, there is a clear sense that letting posts have more visibility than they should can be individually very damaging. That’s why they restricted everything until authors could review it. It’s less “a sensible plan” than the only thing they can do now.

What I wonder (and the source is not clear) is whether Facebook didn’t correct the privacy settings of posts if the author edited them -- those were presumably not affected by the default setting. It’s a minor point as few people take care of that, but it could illustrate whether they were trying to fix it as fast as possible or had a more deliberate understanding of what can be done.

Posts are often viewed hours or days after they were posted. I can’t remember ratios, but it is far from negligible, especially if they are either public or have some activity to them. Public posts on profile where most posts are only visible to friends can be seen long after their were posted, by non-friends visiting your profile.

To answer your question: I do not think that this edit is a sufficient course of action. It’s very obvious to me that such an error revealed an issue in the code release process: that should have been caught earlier and given proper review. I suspect, from having seen another major bugs being addressed, that the most senior engineers have actually already defined test to detect and prevent similar issues. Facebook does not communicate very transparently about its post-mortem, but they are probably the best in the business.

This aspect of the company (the lack of blame of the individual, often junior developper who committed the code and the instant claim of responsibilities of senior developers responsible for code quality checks) is actually one of the least talked about but most important aspect of the company culture. You very rapidly get a sense of what “Move fast, break things“ actually means: it’s about trying, tracking and never letting a failure unused as a learning opportunity –– far more than it’s about not respecting SLAs. The idea is that you often learn about unexpected dimensions of issues by making mistakes, so you might as well learn before someone else figures it out. It sounds counter-intuitive, but has proven to be an effective way to be several steps before people who try to do harm.

I personally detail that post-mortem every time that I’m asked what the company is like: people expect perks & world-domination plot: the eagerness to find a scalable technical and cultural solution is actually far more important and welcoming. I failed to see this was what you were curious about, and I apologise for that.

I suspect that the oversight is along the lines of: security and privacy are paramount and actually embedded one abstraction level below what most coders see (hence: not ACL) but the default selector has been overlooked, because its related to post editing —— under the idea that post authors are conscious of picking the right one every time: that’s obviously unrealistic, and I suspect that all the attention given to privacy now includes changes to the default privacy selector. Given how those are different paradigm sounds to me like a potentially convoluted solution.

Let me know if that is closer to what you were curious to know.

Because they are a huge company with a great deal more experience handling PR gaffs than most people posting on HN. Whatever their shortcomings in other areas, this advice actually is pretty much gold standard.

First, it prevents more eyes on it. This mitigates the damage. A lot of traffic occurs well after the first few hours.

Second, it allows people to forget. People don't have perfect memories. Some people have quite poor memories. Removing it from public view denies them the ability to return to a written record and get all hot under the collar all over again, reread it until they have essentially memorized it, etc.

Third, posting some kind of apology or something to total strangers who don't know you tends to go super badly. It gets interpreted as an admission of guilt which just fuels the fire. Most people aren't that great at giving public apologies. Public faux apologies just put out the fire with gasoline.

Fourth, if you take the advice and do what FB told you to do, you have the defensible position that FB screwed up, go be mad at them, not me. You don't get that shield if you then add more public commentary on the issue. In fact, you are just making an ass of yourself and looking like you are taking advantage of the breach to piss on strangers who don't agree with your point of view.

(edit: also, why on earth would you apologize when it is, in fact, Facebook's error?)

I wish social stuff was as straightforward as you seem to think it is. It's not. And PR is absolutely one of the few things large companies typically know more about in spades than the average person. Their advice may not be what you want to hear, but it is the least worst thing to do in a situation like this.

The simplification had many justification (and some detractors, including me) but the key idea is that who has access to which posts is now more dependent on the graph structure than lists that too few people were maintaining. Typically, if you set a list and made friends who would fit in a list, you only add them later and there were some inconsistency around whether they should see your old posts.

Most of the changes that I’ve noticed happened after I left, but the main motivation is: users don’t understand edge cases of ACLs (or NTFS) and they really hate being surprised. Either way, actually: acquaintances hate realising they couldn’t see their “friend’s” posts; new friends hate seeing their old posts becoming visible.

The abstraction of a Group has clearly emerged as a much better way to give posts context: groups have moderators, rules, shared expectations. Those two are graph-based, rather than ACL, but the inconsistencies that you can imagine around changing membership make more sense to users.

Where it’s really different is that it’s enforced at the language level: Facebook uses Hack, a custom version of PhP where all those concepts are abstracted into the language, to be absolutely sure that junior developers can’t mess up and give access to a un-authorised resources involuntarily, or be attacked because they didn’t know about a unusual type of injection. That’s why ACLs, although still technically available through some old interfaces, are being phased out: they don’t scale well in that context, in addition to their unexpected behaviour.

I’d love someone to explain that better than I can, but I suspect it’s one of those tech that doesn’t make sense outside of the project, and that is possibly more secure if less people understand it well.

Companies that don't protect unsophisticated users from simple mistakes or inaccurate mental models will get a reputation for being insecure and lose sales. This is regardless of whether the user "should have known better."