Your logging middleware might be illegal in Utah.
That sounds like hyperbole, but it's the logical conclusion of poorly written tech legislation. As Hacker News reported, a court has agreed with the EFF that Utah's latest attempt to regulate online content demands a technical impossibility. The law requires services to perform "reasonable verification" of a user's age and location before they can access material potentially "harmful to minors". For privacy-centric services like VPNs, this is a non-starter by design. But the blast radius is much wider than just VPN providers. It extends to any API, any piece of infrastructure, and any developer tool that processes user requests.
This isn't just about what content you serve. It's about the fundamental architecture of the services we build. Lawmakers are trying to write compliance rules for a system they don't understand, and in doing so, they're turning standard engineering practices into sources of legal risk. Let's break down what this actually means for your team and your codebase.
The 'Reasonable Verification' Fallacy in Code
Forget the legalese for a moment and think like an engineer. How would you implement "reasonable verification" of age and location?
First, location. You'd probably start with IP geolocation. We've all used services like MaxMind. It's a common first step. But we also know it's deeply unreliable. Is the user on a mobile network, with their IP address originating from a cell tower 50 miles away? Are they using a coffee shop's WiFi, which routes through a corporate headquarters in another state? Are they, ironically, using a VPN to protect their privacy?
An IP address is not a person's physical location. At best, it's a weak heuristic. Relying on it for legal compliance is like using Math.random() for cryptography. It might feel like you're doing something, but you have no real guarantees.
Now for the harder part: age verification. This is a nightmare of privacy, liability, and user experience. The options are all bad:
- Self-reporting: A simple checkbox, "I am over 18." This is legally insufficient and functionally useless.
- Credit Card Verification: This excludes anyone without a credit card and links browsing activity to financial data, a huge privacy red flag.
- ID Scanning: This is the big one. Asking users to upload a government-issued ID means you are now in the business of storing some of the most sensitive Personally Identifiable Information (PII) imaginable. Your data breach liability just skyrocketed. You need to handle storage, encryption, access control, and eventual deletion with military-grade precision. Are you ready for that? Do you trust your third-party ID verification provider not to get breached?
This is the technical impossibility the court recognized. There is no method to reliably verify age and location that doesn't either destroy user privacy or create a massive security risk. The law demands a tradeoff that no responsible engineering team would make.
How Middleware Becomes a Legal Minefield
Most developers aren't building VPNs or hosting adult content. So why should you care? Because the law is written ambiguously. The compliance burden gets pushed down the stack, and it often lands on the parts of the system that are least equipped to handle it.
Consider a basic piece of logging middleware in an Express.js application. Something you might write in your first week on a new project.
// A typical (and now potentially risky) logging middleware
function requestLogger(req, res, next) {
const userIp = req.headers['x-forwarded-for'] || req.socket.remoteAddress;
const userAgent = req.headers['user-agent'];
const timestamp = new Date().toISOString();
console.log(`[${timestamp}] Request from ${userIp} for ${req.path} with agent: ${userAgent}`);
// What if the content served later is deemed "harmful to minors"?
// This log entry is now evidence of you processing a request from a Utah IP
// without performing "reasonable verification" first.
next();
}
app.use(requestLogger);
This code looks harmless. It's standard practice. We use logs like this for debugging, for security monitoring, for performance analysis. But under a law like Utah's, this log entry is a liability. It's a timestamped record that you received a request from a specific IP address (which could be geolocated to Utah) and served them something without first verifying their age.
Suddenly, your requestLogger isn't just a dev tool. It's part of a compliance chain. If another part of your application serves content that falls under the law's scope, this middleware is an accomplice. It's the component that failed to erect the gate. This is how infrastructure becomes culpable for application-level content.
The API as an Unwitting Accomplice
This problem gets even more complex when we talk about APIs. Your API is, by definition, decoupled from the presentation layer. It's a contract. It receives a request, processes it, and returns a response. Your MailStack API doesn't know if the email it's sending is a password reset or a marketing blast for a product deemed "adult". Your ESig API just knows it needs to get a document signed, not what's in the document.
Does every single API endpoint now need to perform its own age and location check? Imagine the chaos.
// The new reality for every API call?
POST /api/v1/send-email
{
"to": "customer@example.com",
"from": "noreply@your-app.com",
"subject": "Your order confirmation",
"body": "...",
"verification_token": "jwt_or_opaque_token_proving_age_and_location"
}
This would be a disaster. It would add crippling latency, complexity, and brittleness to every single API call. It forces stateful, context-heavy checks onto what should be stateless, independent services. It breaks the clean separation of concerns that makes modern architectures like microservices work.
More importantly, it creates a distributed compliance problem. If Service A calls Service B, which then calls your MailStack API, who is responsible for the check? The front-end? Service A? Service B? Or MailStack? When every component is responsible, no one is. Or worse, everyone is, and you have redundant, conflicting verification logic all over your system.
The Chilling Effect on Open Source and Dev Tools
This brings us to the most dangerous second-order effect. If laws like this spread, they create a chilling effect on the very tools we use to build software.
Will the maintainers of nginx or Express.js face pressure to build "compliance modes" into their software? These modes would likely be complex, poorly maintained, and introduce a host of new security vulnerabilities. It shifts the burden from the application developer, who knows the content and context, to the tool maintainer, who doesn't.
It poisons the open-source ecosystem. Maintainers of popular libraries could find themselves targeted by lawsuits for not preventing their software from being used in non-compliant ways. We already see this happening in other domains. This would be a massive blow to the collaborative spirit that powers so much of our industry.
At VooStack, we build dev tools with DevStack and consult on complex architectures with AgileStack. This kind of legal ambiguity is a direct threat to both. How can you build a reusable component or advise on a scalable architecture when the legal ground is constantly shifting beneath you, demanding things that are technically unsound?
What This Means for Your Team
This isn't just a problem for lawyers or people in Utah. It's a software architecture problem with legal consequences. Here are the key takeaways for technical leaders:
- Laws written by non-technologists create impossible standards. When legislators don't understand how the internet works, they create laws that are impossible to follow. This Utah law is a prime example.
- Your default practices may be your biggest liability. Standard logging, data handling, and API designs can become legal risks under ambiguous laws. What was once a best practice is now evidence of non-compliance.
- Compliance is an architectural concern. You can't bolt on compliance at the end. Decisions about data flow, service boundaries, and PII handling have direct legal implications. You need to be thinking about this at the design stage.
- The burden of proof is being pushed down the stack. The trend is to make infrastructure and tools responsible for application-level problems. This is a dangerous path that threatens the open-source tools and platforms we all rely on.
The court's decision to side with the EFF is a temporary win for technical sanity. But it's just one state and one law. The underlying trend of legislating technology without understanding it is not going away.
The right move isn't to start blocking all traffic from Utah. The right move is to treat legal compliance as a first-class feature of your system architecture. You need to audit your stack for implicit data collection and ask the hard questions. What assumptions are we making about our users? Where are we collecting data we don't strictly need? And how would our system hold up if a technically impossible law came to our state next?
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.