There are a finite number of log locations now. How do you intend to operate an integration test across the entirety of Facebook's stack to detect new log locations?

Change requests and a change review board staffed by professionals.

Subject: Change Request

Body: I would like to log the body of authentication requests in production.

Subject Re: Change Request

Body: How will you ensure personal data is not stored that shouldn't be?

Subject: Re: Re: Change Request

Body: I will add configuration Y to logging system X.

Change1: Enable logging of middleware traffic on 0.01% of requests for better profiling.

Reviewer: Does this have privacy implications?

Change1: No, Service X marks all PII before this point. Code X drops everything marked in this way.

Two years later.

Change N: Modify request structure for more optimal blah blah blah.

Now suddenly the changed request structure causes a regression in the PII detection which causes some logging of PII.

This shit is way more complex than "just stop people when they ask to log passwords".

Bureaucracy like this is what kills teams and products. There's no guarantee it works, and every change or commit should already have privacy and data protection in mind anyway. You also don't know what you don't know - you could for all your knowledge think that nothing is being logged, when in fact there's a subsystem outside your scope that's actually doing the logging.

You assert that it's trivial, yet you're adding more layers to protect against something like that from happening. It's the naivety that all problems are trivial is what gets people and companies into trouble in the first place

I promise you the productivity loss of sending a few emails is much less than 5 billion dollars.

The point is aptly demonstrated within this thread; sometimes things that look trivial at a glance aren't so trivial in reality.

You assume that all logging happens within an application. It doesn't.