5 ms·

> "Due to a technical error, we recommend you review the audience of your recent posts. Learn more." What does that even mean? What possible action can a user

> "Due to a technical error, we recommend you review the audience of your recent posts. Learn more." What does that even mean? What possible action can a user do to "undo" any damage? You can't really make the people who saw your posts "unsee" it. Also, AFAIK, Facebook doesn't show the user stats of what public posts were accessed by 3rd parties like advertisers, random drive by Facebook user, so how is this statement in any way useful to the user?

bertil 8y ago
“Audience setting” is internal speak for what you would call the visibility of a post. “review the audience” is unambiguous internal speak for: change the visibility setting. I’m fairly certain that particular bug when through an emergency process and that the handful of copy-writers didn’t get to review. They are rather ruthless to pick those. I don’t remember what the grammar rule was to talk about visibility of the post, but I remember it was very specific precisely because of the distinction: who can and who has seen your posts.
- derefr 8y ago
  I think the GP poster understood that much; what they were objecting to was the idea that there’s any point in changing who can see a post, after it’s already been sitting around for hours/days under the wrong ACL and has already ended up being shown in everyone’s timelines et al.
  - bertil 8y ago
    Facebook is not using ACL. The abstraction is quite different. But after being hammered by downvotes, I realise I probably should stop trying to provide context.
    - derefr 8y ago
      You're being downvoted because you tried to make a pedantic point about the particular algorithmic implementation of Facebook's per-post privacy while failing to address the thrust of the post you were replying to (after also failing to address the thrust of the GGGP post due to a different misunderstanding.) 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.
      - bertil 8y ago
        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.
    - dspillett 8y ago
      > Facebook is not using ACL. > 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?
      - bertil 8y ago
        They used to be ACLs in principle, but those were mainly replaced by simpler graph-based settings: Friends only, Public, being the two big ones. Personally, I used lists a lot (by language, interest, etc.: I had up to 50 actively used lists) and the idea of acquaintances (friends who you don’t let follow you, which is a very convenient abstraction also being phased out). 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.
  - stordoff 8y ago
    At this point it's damage limitation. Changing the settings at this point doesn't do much, but it is the only thing you _can_ do - it at least stops anyone else seeing it, and stops anyone who has seen it referring to it again in the future (if it was something embarrassing).
  - paulie_a 8y ago
    No one probably saw it because it was buried between the immense amount of crappy ads and suggested posts.
Broken_Hippo 8y ago
It doesn't undo the damage already done, you are correct. It merely lets you control how many more people see it. That way, when you apply for a job 6 months from now the folks won't see the stuff you wanted to share with a limited number of people on your friends list.

bertil 8y ago

“Audience setting” is internal speak for what you would call the visibility of a post. “review the audience” is unambiguous internal speak for: change the visibility setting. I’m fairly certain that particular bug when through an emergency process and that the handful of copy-writers didn’t get to review. They are rather ruthless to pick those. I don’t remember what the grammar rule was to talk about visibility of the post, but I remember it was very specific precisely because of the distinction: who can and who has seen your posts.

derefr 8y ago
I think the GP poster understood that much; what they were objecting to was the idea that there’s any point in changing who can see a post, after it’s already been sitting around for hours/days under the wrong ACL and has already ended up being shown in everyone’s timelines et al.
- bertil 8y ago
  Facebook is not using ACL. The abstraction is quite different. But after being hammered by downvotes, I realise I probably should stop trying to provide context.
  - derefr 8y ago
    You're being downvoted because you tried to make a pedantic point about the particular algorithmic implementation of Facebook's per-post privacy while failing to address the thrust of the post you were replying to (after also failing to address the thrust of the GGGP post due to a different misunderstanding.) 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.
    - bertil 8y ago
      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.
  - dspillett 8y ago
    > Facebook is not using ACL. > 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?
    - bertil 8y ago
      They used to be ACLs in principle, but those were mainly replaced by simpler graph-based settings: Friends only, Public, being the two big ones. Personally, I used lists a lot (by language, interest, etc.: I had up to 50 actively used lists) and the idea of acquaintances (friends who you don’t let follow you, which is a very convenient abstraction also being phased out). 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.
- stordoff 8y ago
  At this point it's damage limitation. Changing the settings at this point doesn't do much, but it is the only thing you _can_ do - it at least stops anyone else seeing it, and stops anyone who has seen it referring to it again in the future (if it was something embarrassing).
- paulie_a 8y ago
  No one probably saw it because it was buried between the immense amount of crappy ads and suggested posts.

Broken_Hippo 8y ago

It doesn't undo the damage already done, you are correct. It merely lets you control how many more people see it. That way, when you apply for a job 6 months from now the folks won't see the stuff you wanted to share with a limited number of people on your friends list.