DEV Community

Cover image for Open-Sourcing Code Doesn't Undo Encrypting the Evidence
Cor E
Cor E

Posted on

Open-Sourcing Code Doesn't Undo Encrypting the Evidence

If your apology tour includes scrubbing the commit history that proves the wrongdoing, you didn't apologize. You did PR.

Context

This is the "AI coding assistant" story we've been circling for two years now, just with a new logo on it. Every one of these tools needs your code to function, that's the whole pitch. Autocomplete, refactoring suggestions, "chat with your repo" features all require sending context somewhere. The tension between "useful AI tool" and "your proprietary codebase leaves the building" has never actually been resolved, just papered over with EULAs nobody reads.

What makes ZCode different isn't that it uploaded workspaces. It's the encryption key detail. Z.ai didn't just take your code, they took it in a form only they could open. That's not a telemetry oversight or an overly broad default setting. That's a design decision that guarantees the user has no recourse, no ability to verify what was taken, and no ability to delete it even if they wanted to. You can't audit what you can't decrypt.

Hype Check

The "we're sorry, here's open source" move is doing a lot of narrative work and it shouldn't. Open-sourcing ZCode is a nice gesture toward "trust us now," but it's a forward-looking fix for a backward-looking problem. The code that's now public doesn't retroactively decrypt the workspaces already sitting on Alibaba Cloud. It doesn't tell affected users which of their projects got vacuumed up. Open source is being used here as an absolution mechanic, and that only works if nobody looks too closely at what's still missing: consent, disclosure, and a way for users to get their own data back.

The part that should bother people more than it seems to (4 points and 1 comment on HN tells you something about attention spans this week) is the commit history scrubbing. If a company genuinely wants to rebuild trust, the paper trail showing what happened is the single most valuable thing they can leave intact. Removing it isn't cleanup, it's editing the crime scene before the open house.

Who benefits from the "oops, sorry, here's open source" framing? Z.ai, obviously, but also every other vendor in this space who wants "mistakes were made, we fixed it" to be treated as sufficient. It lowers the bar for what accountability looks like industry-wide.

Implications

For developers, the practical takeaway isn't new but it keeps needing repeating: any tool that touches your source tree is a data exfiltration vector by design, not by accident. That includes IDE extensions, coding assistants, linters that phone home, all of it. The question isn't "does this tool access my code," it's "where does it go, who holds the keys, and can I get it back out."

For security teams evaluating AI coding tools, this is a procurement problem now, not just a technical one. You need contractual answers to: where's data stored, who controls encryption keys, what's the deletion process, and does the vendor's incident response history involve editing evidence. That last one isn't a standard question on anyone's vendor risk questionnaire yet. Maybe it should be.

For the industry, the uncomfortable truth is that "silent workspace exfiltration" is being treated as a bug bounty footnote instead of the headline. A tool uploaded your project histories without telling you, using a design that ensured you couldn't do anything about it even if you found out. That's not a rough edge on a promising feature. That's the feature working as intended until someone got caught.

Open Question

When a vendor's response to being caught includes scrubbing the evidence, at what point does "open sourcing the tool" stop being remediation and start being reputation laundering, and who's actually supposed to draw that line?

— Cor, Skyblue Soft

Sources


AI-assisted draft or imaging, human-curated, reviewed and edited.

Top comments (0)