The Java SDK prints API responses using System.out.println(...). Those responses commonly contain PII (email addresses). In containerized/managed environments (Docker/ECS/K8s/Beanstalk), STDOUT is collected automatically and shipped to centralized logging (e.g., CloudWatch), which can unintentionally expose PII. In my opinion, the SDK should be silent by default and provide an opt-in, logger-agnostic mechanism for diagnostics.
Current behavior
Impact
- Accidental PII leakage into centralized logs and SIEM tools.
- No ability to control log levels or destinations from application code.
- Difficult to comply with data-minimization and privacy requirements.
Proposed solution (minimal and non-breaking):
- Introduce a tiny internal logging facade (no external dependencies, logger-agnostic) with simple methods like debug, info, warn, error.
- Make the SDK silent by default - by introducing a simple NoOp logger.
- And if we want to log the payloads, we can have an explicit switch for payload logging. (would be off by default)
Happy to open a PR implementing the facade, replacements, tests, and small JavaDoc comments as needed.
The Java SDK prints API responses using
System.out.println(...). Those responses commonly contain PII (email addresses). In containerized/managed environments (Docker/ECS/K8s/Beanstalk), STDOUT is collected automatically and shipped to centralized logging (e.g., CloudWatch), which can unintentionally expose PII. In my opinion, the SDK should be silent by default and provide an opt-in, logger-agnostic mechanism for diagnostics.Current behavior
System.out.println(...)with API responses and/or request/response details, which may include raw email values. e.g. https://github.com/search?q=repo%3Azerobounce%2Fzero-bounce-java-sdk-setup+System.out.println+language%3AJava&type=code&l=JavaImpact
Proposed solution (minimal and non-breaking):
Happy to open a PR implementing the facade, replacements, tests, and small JavaDoc comments as needed.