A forensic analysis of C2PA-signed photos from the Google Pixel 10 was recently published finding inconsistent timestamps and metadata that can be undetectably changed. When I filed a bug bounty report to Google based on these issues, their response was "We have logged this issue for potential remediation in a future version."
In other words, "What we have now is good enough, but we'll take a look later."
I've spent the last six months building dev tools for C2PA, and I've watched this pattern repeat across the ecosystem. The aphorism "perfect is the enemy of good" has become a conversational cheat code that morphed engineering rigor into obstructionism, framing the critic as an idealist and the defender as a pragmatist. But after seeing it used to dismiss security failures, I've come to a different conclusion: Perfect isn't the enemy of good. "Good enough" is the enemy of "actually good."
C2PA's Flawed Foundation
C2PA is an attempt to take on digital misinformation by cryptographically signing media metadata. The promise is compelling: any media file could carry an unforgeable chain of custody from camera shutter to social media feed ("glass to glass" security). In theory, you'd know the origin of content and how it was modified along the way.
The specification is admittedly complex: X.509 certificate chains, nested manifests embedded in file formats, and a federated trust registry. For most engineers who aren't security experts, this is a significant barrier (which is exactly why we're building Que).
As we would expect from a protocol still finding its footing, C2PA has flaws. The problem isn't the flaws themselves, it's how we respond to them. When someone points out that the foundation is cracked, the response shouldn't be "well, you can't always be perfect" as a shield against criticism. The response should be "let's fix the foundation."
The Spectrum of "Good"
"Perfect is the enemy of good" implies a false binary: either you're chasing perfection or you're being practical. But "good" exists on a spectrum with clear thresholds. When Voltaire coined the phrase, he was warning against letting the unattainable prevent the achievable. He wasn't arguing we should accept solutions that fail at their primary purpose.
A better framing: "The pursuit of perfect is the enemy of a sufficiently good-enough solution." The key word here is sufficiently.
In engineering, we make tradeoffs daily. A release that doesn't have all features is imperfect but good. A security protocol that fails under certain attack vectors is not "good enough." It's fundamentally broken.
The difference is whether the imperfection undermines the core value proposition. C2PA's value proposition is trust. When a system designed to establish trust is inconsistent or circumventable, it doesn't just fall short of perfect. It actively harms users by creating a false sense of security.
A Culture of Defensive Pragmatism
This pattern extends far beyond C2PA. Across engineering projects, "perfect is the enemy of good" has become a shield for shipping systems that fail at their core purpose. We see it when MVPs built as prototypes become permanent production systems. When security audits are skipped because "we'll add it in v2." When technical debt is framed as "iterative development" rather than deferred disaster.
This matters because "perfect is the enemy of good" has been weaponized to lower the bar to a floor where "exists" is now the new definition of "good." It has effectively shut down debate about quality and safety, and when we defend broken systems with aphorisms instead of fixes, we're not being pragmatic. We're being irresponsible. When a payment system occasionally loses transactions, that's not "good enough." When a medical device firmware has known race conditions, that's not "good enough." When an authentication library can be bypassed, that's not "good enough."
Instead of fearing perfectionism, we should aspire to it. Not by building flawless systems, but by refusing to accept ones that fail at their job. Pointing out that something is broken isn't perfectionism, it's the bare minimum requirement of engineering.
I don't need any software to be perfect. I need it to be better than nothing, and in many cases, it isn't. Instead of reaching for Voltaire, we should be reaching for our keyboards, opening an IDE, and actually fixing the problems. Because in engineering, "good enough" isn't good enough, and pretending otherwise helps no one.