This is especially galling (to everyone, apparently) when the particular algorithmic implementation is irrelevant to the thrust of the post you replied to, and so the "context" you're attempting to provide is not only unnecessary to provide, but is actually distracting from the point. It's reminiscent of a politician attempting to perform an act of rhetorical judo to avoid actually answering a question.

Let me restate, because obviously those people who downvoted you actually want an answer to this question: why would Facebook attempt to portray changing the privacy settings on a post hours/days after it goes out with the wrong privacy settings, as a sensible plan of action to suggest for fixing the problem they created? Everyone's already seen what you posted. Changing the privacy setting isn't a time-machine that'll make them un-see it.

Why didn't Facebook instead suggest, say, making a post reaching out to anyone who your not-so-private-after-all posts may have inadvertently hurt? That's something that actually has a chance of ameliorating the problem.

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.

Because you're not apologizing that they saw your post; you're apologizing for the content of your posts.

Like, imagine that you're a [race A] guy with [race B] friends, who is also secretly super-racist against [race B], making [race B]-disparaging posts that are only visible to your [race A] friends.

One of those posts ends up visible to your [race B] friends.

Is the sensible suggestion "hide it and hope they didn't see it/hope they forget"?

Or is the sensible suggestion "hide it or delete it; and then—now that the fact that you're a racist is out in the open—start doing damage control, e.g. by profusely apologizing for your comments and trying to skew things in such a way that it makes it seem that this was a one-off thing rather than your usual secret behaviour"?

(Or, for another obvious one: what if a private post to your secret lover is made public to your spouse?)

IMHO these are the kinds of problems that are important to suggest a response for—the ones where Facebook could make a suggestion of a response that would create the most net utility, since a lack of any intervention in these cases has the potential to create the most net disutility.

Compared to these cases, the ones where someone's parents saw their pictures of them partying or what-have-you are effectively irrelevant, and shouldn't be brought into Facebook's moral calculus re: appropriate responses.

To be perfectly clear, I had an illicit affair in my youth and I am often quite sympathetic to the person cheating. I'm a woman, so I sometimes get women dumping on me about their cheating husband. They inevitably expect me to automatically side with them and agree that everything wrong in the marriage is his fault and to generally hate on men by default. Those conversations don't go like those women expect.

But I can't imagine using Facebook for such covert activities and if you have such a scenario on your hands, there are going to be very serious consequences for being outed. That goes well beyond PR gaff and is far outside the scope of what Facebook should be expected to try to manage on your behalf.

There are very serious matters that I think Facebook should take more responsibility for, such as their role in fueling longstanding feuds in some countries. They should take measures to stop being a means to pour gasoline on those fires.

But your specific concerns are not anything I feel Facebook needs to take responsibility for.

I will add that even in the scenarios you posit, the gold standard is to hide the post and hope they didn't see it. If they did, PR measures will not help you.

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.

Seeing most Facebook content required a login and most Facebook groups are private and required an application or an invite, and still does, facebook today plays very little role if any concerning free information flow, which is ideally indexed by search engines and accessible openly by following a link.

> I probably should stop trying to provide context.

I think the downvotes are far more simple than other respondents have suggested: the context you have provided here is not correct.

Facebooks post visibility management supports lists of people that are used to control access to the information. The usual defaults are "everyone" or "all friends" but you can setup others such as "friends except those wankers".

It isn't a more complex ACL arrangement (as seen for instance in NTFS file permissions) but there are lists that are used to control who gets access.

> The abstraction is quite different.

Unless of course I'm the one being incorrect... Care to state which pattern/abstraction that are using and why it is best not to be described as ACLs?

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.