EFF argues AB 3024 demands a model-geometry classifier that can reliably distinguish regulated gun parts from millions of legitimate brackets, jigs, and prototypes — a capability that doesn't exist today. They point out the bill defines neither what counts as a 'firearm component' with engineering precision nor an acceptable false-positive rate, making compliance effectively impossible.
By submitting the EFF piece to HN, hn_acker amplifies the position that the bill is technically unworkable and worth organized opposition. The framing 'we can still stop' signals this is a fight the technical community should join before the Appropriations gate closes.
The editorial frames AB 3024 as the latest instance of a pattern that has already collapsed elsewhere: client-side CSAM scanning fell to hash-collision attacks, and Apple shelved its on-device photo scanner after adversarial demonstrations. The mechanism — manufacturer-side, on-device classification of user-generated content with mandated firmware lockdown — has lost every prior technical fight and is unlikely to succeed for 3D geometry either.
The 408-point, ~600-comment thread is described as unusually unified for a political post, with even commenters who otherwise support firearms regulation flagging the scheme as unworkable. Their objection isn't to the policy goal but to the mechanism: forcing manufacturers to ship and attest to a classifier that can't reliably tell a lower receiver from a hobbyist bracket.
The Electronic Frontier Foundation published a fresh call to action against California AB 3024, a bill that would require any 3D printer sold in the state to ship with software that scans every uploaded model for parts that *could* be used to assemble a firearm — and refuse to print if it finds one. The bill has already cleared the Assembly Public Safety Committee and now sits in Appropriations, which is the last serious gate before a floor vote.
The text is broader than the headline suggests. Manufacturers wouldn't just need a classifier — they'd need to attest to the state that the classifier works, keep it updated, and (per EFF's reading) effectively lock down firmware so end users can't disable it. The bill defines neither what counts as a "firearm component" with engineering precision nor what false-positive rate is acceptable. There's no safe harbor for hobbyist printers, no exemption for industrial CAM software, and no specified appeals process for a user whose bracket gets flagged as a lower receiver.
EFF's core argument is that the bill mandates a technical capability that does not currently exist and may not be buildable: a model-geometry classifier that can reliably distinguish a regulated gun part from the millions of legitimate brackets, jigs, and prototypes a printer sees. The HN thread (408 points, ~600 comments at time of writing) is unusually unified for a political post — even commenters who otherwise support firearms regulation are flagging the scheme as unworkable.
This is a developer story, not a Second Amendment story. The mechanism the bill demands — mandatory, manufacturer-side, on-device content classification of user-generated geometry — is the same architectural pattern that's been quietly losing every other technical fight it's been in. Client-side CSAM scanning collapsed under hash-collision attacks. Apple shelved its on-device photo scanner after researchers demonstrated trivial adversarial inputs. YouTube's Content ID, which has roughly a decade of training data and a billion-dollar budget, still mis-flags birdsong as Universal Music. Asking a printer-firmware blob to do better, on a smaller model, on a Raspberry Pi-class SoC, against geometry that can be trivially rotated, scaled, or split across multiple files, is not a regulatory ask — it's a wish.
The second-order effects are where the developer pain lives. If the bill passes, every 3D printer sold in California has to ship with a signed slicer pipeline. That almost certainly means locked bootloaders, signed firmware updates, and an end to the current convention where a Prusa or Bambu user can swap in PrusaSlicer, OrcaSlicer, or a custom Klipper config. The bill doesn't say "lock the firmware" — it just makes locking the firmware the only legally defensible compliance posture. We've seen this movie before with HP printer-cartridge DRM and John Deere tractor ECUs, and the ending is always the same: a hostile community fork, a cat-and-mouse jailbreak cycle, and a chilling effect on the legitimate maker economy in the regulated jurisdiction.
The third problem is jurisdictional spillover. California is large enough that manufacturers won't ship a separate SKU for the rest of the country — they'll ship the locked-down firmware everywhere and quietly disable the geometry check outside CA. That means a Texas hobbyist's printer is also running an unauditable ML classifier on every model they slice, "just in case." The telemetry implications alone should give any practitioner pause: a model-scanning pipeline is, by construction, a model-exfiltration pipeline waiting for a vendor pivot or a subpoena.
And then there's the open-source angle. Klipper, Marlin, RepRapFirmware, Mainsail, Fluidd, OctoPrint — the entire open firmware and host-software stack that powers most prosumer printing — would have no compliant path to the California market. There is no maintainer of Marlin who is going to ship a ML gun-part classifier. The practical effect is that compliance becomes a moat: only Bambu, Prusa, Creality, and the other vertically integrated vendors with closed software can sell in CA. Indie firmware dies in the state by accident.
If you ship hardware with a host-side slicer, CAM tool, or any G-code generator, treat AB 3024 as a leading indicator. The same legislative logic — "the device must classify user content before acting on it" — is already being floated for laser cutters (knife blanks), CNC mills (suppressors), and desktop bioprinters (controlled compounds). A vendor that wins one of these mandates will use the resulting moat to lobby for the next. Now is the time to design your firmware update story, your signed-binary posture, and your jurisdictional kill-switch architecture — not after a bill lands in your category.
If you work in ML infra, the bill is also a useful forcing function. A geometry-classification model that runs on-device, against adversarial inputs, with a legally-meaningful false-positive budget, is a real benchmark nobody has built. Whoever writes the open-source eval harness for "is this STL a regulated part" — even just to prove the bill is technically incoherent — owns the citation in the next round of legislative testimony. EFF explicitly calls for technically-credible voices to file public comment before the Appropriations hearing.
For everyone else: if you live in California and you own a printer, the EFF page has a one-click form to your assemblymember. This is the rare policy fight where ~5,000 technically-literate letters in a two-week window have historically been enough to kill a bill at Appropriations. The 2019 California right-to-repair bill died at this same committee for almost identical reasons — manufacturer cost objections plus a sustained constituent push.
The bigger pattern is that content moderation is metastasizing from platforms to devices. We spent a decade arguing about what Facebook should scan; we're about to spend the next decade arguing about what your printer, your camera, your sewing machine, and your CNC router should scan. AB 3024 is the first one of these that targets a developer-adjacent tool with an organized open-source community behind it, which means it's the first one where the technical counter-argument might actually land. If it doesn't, the precedent will be cited in every subsequent bill — and the next one won't be about guns.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.