@davidgerard a friend of mine caused an incident at fb when he removed an incredible amount of duplicated vendored code ostensibly because they have an ML-based packaging tool that suddenly failed in response to a much smaller input. one issue with vendored code is that changes to it are not really detectable; the second issue is that you can't update it for security fixes.

i mention this because facebook has very frequently spoken of how security needs to be the default and tooling built to make it easier to write secure code; sure, it's facebook, perhaps best to ignore that. but there should be no way a single change makes this possible in the first place. twitter was under a 10-year FTC consent decree for failing to sufficiently protect user data (they lied about this to their engineers). accessing user data is not something a single code change can achieve unless user data is already visible to insufficiently permissioned services.

the point is this sounds like a great thing to leak to the press if you believe your sneaky code path is about to get burned by a whistleblower. it also serves as an explanation to their own employees. stochastic parrot can't generate a cryptographic key and any security engineer would know this. what this does say is that the regulatory environment is sufficiently dead in the water that they feel safe to leak criminal neglect to the press.