Thank you for your feedback.

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.