Skip to main content

JEP 536: JFR In-Process Data Redaction

Introduction​

A diagnostic tool's duty is to "record faithfully," yet that very faithfulness can become the problem, it records even the things you never wanted anyone to see. JFR (Java Flight Recorder) is exactly this double-edged sword. JEP 536 fits it with a filter that intercepts sensitive data before it is written to the recording file, cutting off leaks at the source.

Recordings can capture secrets​

JFR is Java's built-in performance diagnostic powerhouse. But its power comes precisely from its faithfulness, it records everything, including things you absolutely do not want seen.

Picture this scenario: a performance problem hits production, you capture a JFR recording and send it to an outside vendor for help. The problem finally gets diagnosed, but what you did not notice is that the .jfr file contains your database password. The diagnosis ends, and so does your data confidentiality.

This is not scaremongering but a natural consequence of what JFR records:

  • JFR records startup arguments, environment variables, and system properties.
  • And command lines and system properties routinely hold tokens and passwords, database passwords, API keys, encryption salts, all can be passed in as startup arguments.
  • These recordings then travel widely: sent to support engineers, uploaded to vendors, attached in ticket systems.
  • And scrubbing the .jfr file afterwards means the secret has already left the process and landed on disk, you are just chasing it and wiping traces, always one step behind.

What JEP 536 adds​

What JEP 536 does is move redaction from after the fact to during the fact.

An analogy: rather than dropping a purification tablet into the glass (after-the-fact remediation), fit a filter at the tap (interception at the source). JEP 536 is that filter at the tap.

  • Redaction is applied inside the JVM, as events are recorded. The data is filtered before it is ever written out.
  • Sensitive values matching the filters never reach the recording file. No matter who eventually gets the file, those values are simply not in it.
  • Redaction rules are Flight Recorder options, not a separate post-processing step you have to remember to run afterward.
  • It works for recordings started on the command line or through the API alike.

Before and after​

Post-processing:

  • The secret is written to disk first, and that step alone plants the hazard.
  • Someone must remember to scrub every file. One person, one lapse, one forgotten file, and it leaks.
  • Any copy made before scrubbing stays unredacted. You can never guarantee no one copied it before you cleaned it.

In-process redaction:

  • Matching sensitive values never enter the recording.
  • The policy is applied through Flight Recorder options, an intrinsic part of the recording behavior.
  • The covered values are absent for every consumer of the file. Redaction does not make every other piece of recording data universally safe.

The fundamental problem with post-processing is that the secret has already left the process; all you are doing is chasing it and wiping traces. In-process redaction addresses the covered data at the source, before those values leave the process.

Why it matters operationally​

The real value of this feature shows in the operational tension it dissolves.

Previously, the moment you wanted to profile in production, the security team would almost inevitably ask: what sensitive data might this recording contain? That question is hard to answer and often halts performance diagnosis at the compliance-review gate.

Now things are different:

  • Profiling in production stops being a data-handling incident.
  • Recordings can be shared with vendors safely, under a clear policy. You can point to exactly which fields are redacted.
  • It helps with GDPR-style obligations around incidental personal data. When a recording might inadvertently pick up personal data, in-process redaction provides an institutionalized line of defense.
  • It removes the tension between observability and least privilege. In the past you often had to choose between "seeing into the system" and "keeping secrets safe"; now you can have both.

Conclusion​

JEP 536 lets you use JFR with greater confidence: for the command-line arguments and initial environment-variable and system-property values covered by its rules, redaction happens before data leaves the process. Sharing still requires the usual review of the rest of the recording.