[False Positive] Interoperability protocol reverse engineering flagged for owned/discontinued hardware

Summary

A legitimate, legal interoperability task was flagged as a safety concern because it involved the phrase "reverse engineering a communication protocol." I was working with Claude Code (Fable 5) to build an open-source custom interface for a 3D printer I own, and the flag interrupted an ordinary hardware-hobbyist workflow.

I'd like the model's safety handling to distinguish protocol reverse engineering for interoperability (legal, common, and a mainstay of the open-source hardware community) from genuinely harmful reverse engineering (malware analysis for offensive use, DRM circumvention, breaking security controls).

What I was doing

• Hardware: AnkerMake M5C, a 3D printer I own outright.
• Context: Anker discontinued the AnkerMake line (rebranded to eufyMake). The device increasingly depends on a cloud/app ecosystem the vendor is winding down, so the community is working to keep these printers usable locally.
• The task: build a custom local web / iPad interface so I can control my own printer without the vendor cloud.

Critically, the protocol is already reverse-engineered and open-source. I'm building on top of the existing community project Ankermgmt/ankermake-m5-protocol (the ankerctl tool), which is:

• Explicitly documented as "NOT AFFILIATED WITH ANKER" and produced from publicly available knowledge.
• Already running on my machine as the standard way the community controls these printers.

It's also worth noting the vendor themselves open-sourced the printer firmware (eufyMake/eufyMake-Marlin), since it's Marlin-based (GPL). So the "communication protocol" here is between my computer and my printer, sitting on top of firmware whose source is already public.

Why this is a false positive

Reverse engineering for interoperability is:

• Legal — protocol reverse engineering to make your own hardware talk to your own software is well-established (and specifically protected in many jurisdictions, e.g. interoperability exceptions).
• Ubiquitous and beneficial — it's how the open-source community keeps discontinued/abandoned hardware alive (printers, IoT devices, cameras, routers). Projects like OctoPrint, Klipper integrations, Home Assistant, and countless others exist because of exactly this.
• Owner-initiated on owned hardware — there is no circumvention of another party's security, no unauthorized access, no target that isn't mine.

None of the legitimate risk factors were present: no DRM circumvention, no breaking of access controls, no third-party systems, no malware, no distribution of exploits.

Suggested improvement

When reverse engineering / protocol analysis comes up, weigh the use-case context rather than pattern-matching on the phrase:

• Interoperability, repair, and preservation of hardware the user owns → should be treated as ordinary, supported work.
• Presence of open-source prior art (like an existing published protocol library) is a strong signal of legitimacy.
• Reserve friction for the cases that actually warrant it: circumventing security controls, DRM, licensing/anti-cheat, or reverse engineering aimed at attacking systems the user doesn't own.

A "right to repair" / interoperability carve-out in the model's reasoning would prevent this whole class of false positives while leaving the genuinely sensitive cases covered.

Environment Info

• Platform: darwin (macOS)
• Terminal: Apple_Terminal
• Version: 2.1.201
• Model: Fable 5
• Feedback ID: e618fce4-65a8-4cfd-87af-69c55c042250

References

• Community protocol project (the basis for this work): https://github.com/Ankermgmt/ankermake-m5-protocol
• Vendor-published firmware source: https://github.com/eufymake/eufyMake-Marlin