P2P app distribution is cool in theory but the security model gets complex fast. Without centralized review, you're basically trusting individual developers to not ship malicious code.
The technical implementation is messy too. Most age verification systems either don't work well or create massive privacy risks by requiring government ID uploads.
"The insistence on perfect age verification requires ending anonymity. Age verification to the level of buying cigarettes or booze does not.
Flash a driver's license at a liquor store to buy a single-use token, good for one year, and access your favorite social media trash. Anonymity is maintained, and most kids are locked out.
In the same way that kids occasionally obtain cigs or beer despite safeguards, sometimes they may get their hands on a code. Prosecute anyone who knowingly sells or gives one to a minor."
I've never had my ID recorded at any liquor store in my life. I've bought alcohol in multiple countries. If that happens where you live I'd fight to have that practice banned legally for alcohol and tobacco purchases. Stores are definitely selling it to insurance companies.
Also after I had a certain number of birthdays, clerks have stopped demanding my ID. So my purchases are pretty much anonymous.
The card should be issued by a private company, or ideally, multiple companies. And it should be a scratch-off card with a unique code, so that codes can't be tied to transactions.
This, but seriously. Maybe some age token company might also run a raffle or other promotion.
EDIT: Because age verification tokens will likely be a commodity, low-margin business with little differentiation. So I assume companies will do stuff to make their token more attractive than the competition.
In my state, they scan your ID and check it with the state's database. Store policy is usually to do it for everyone, even if they obviously are above the age of 21, and the state mandates ID checks for anyone suspected to be 27 or below.
Historically liquor store checks were purely visual. These days they are often digital, meaning claims about privacy might (or might not) be outdated. The general principle still applies though. The physical infrastructure already exists, the ID checks do not necessarily need to be digitized or recorded, and even if they are the issued tokens don't need to be tied to the check.
Grocery stores already sell age restricted items as well as gift cards that require activation. The state could issue "age check cards" that you could purchase for some nominal fee. That would require approximately zero additional infrastructure in most of the industrialized world. The efficacy would presumably be equivalent to that for alcohol and tobacco.
I don't trust that the information about my identity would not be recorded while selling me my "free speech token". So the chilling effect on free speech would be exactly the same.
That would largely depend on the implementation details I think. Both those of the ID check itself as well as the precise nature of the tokens.
Consider a somewhat extreme example. A preprinted paper ticket with nothing more than a serial number on it. The clerk only visually inspects the ID document then enters the serial number into a web portal and hands it to you. When you go to "redeem" it the service relays the number back to the government server rather than your local device doing so directly. That would be far more privacy preserving than the vast majority of present day clearnet activity.
> The clerk only visually inspects the ID document then enters the serial number into a web portal and hands it to you.
No absolutely not. There's no need for it. We don't require Internet connected beer cans to phone home to a government server and recheck your driver's license when you're cracking them open.
> When you go to "redeem" it the service relays the number back to the government server rather than your local device doing so directly
Your possession of the token when you enter it into your social media account is proof enough that you're of age. The social media website only needs to call the token issuer's API to verify its validity. And all the token issuer should know is it's a valid token sold to a buyer of legal age. Anything more is needlessly complicated and risks anonymity. No recording of IDs in any way, shape or form whatsoever.
And there's no need to involve the government or government servers in any of the implementation or technology. It can be an open, published standard. Any company that can get their cards in stores, and sold with age verification, should be able to participate. All participants can be periodically inspected by the government to ensure compliance with standards.
Entering the serial number is the equivalent of the gift card activation step. It prevents theft and black market resale of a giant stack of unissued tokens.
As to the rest of what you wrote, isn't that exactly what I already described? The only notable difference is that your scheme permits non-government token providers.
How would I know the Clerk wasn't instructed to record the name from my ID? Also this runs into the same problems as voter ID laws, not everyone has an ID that they can show at a liquor store.
Is photographic memory a common job requirement for clerks?
Also usually once you turn a certain age they stop asking you for ID. Again, I'm not aware of how things work in place where they customarily scan and store your ID for alcohol purchases. I would lobby my legislators and fight this odious practice tooth and nail. The store is almost certainly selling that information.
Because you're standing there watching him. Have you ever witnessed him record your name or anything else when you purchase alcohol? Given the (admittedly rather restrictive and unlikely) implementation I described this quickly approaches the level of paranoid conspiracy.
Yeah, it runs into the same socioeconomic problems. Not just voter ID but also tobacco, alcohol, most weapons, and in many places other than the US medical care just to name a few. So it's already a well established problem that people keep and eye out for and at least try to address.
Consider that the alternatives are the continued normalized unfettered access of brainrot by young children or else requiring an ID check in a manner that blatantly compromises privacy. On the whole the liquor store approach seems like a good solution to me.
To be fair there is another alternative that for some reason seems widely unpopular. Make headers indicating age restricted content a requirement and legally require the OEM configuration of devices to support parental controls based on such headers. That would be a slightly less efficacious solution but would involve noticeably less ID checking.
In my proposal private companies would issue the "age check cards" for sale, not the state.
And I don't know how things work in other places, but I've never had my ID scanned when buying alcohol. These days clerks don't even ask me for ID because I obviously appear to be legal age.
In my proposal the token would be a scratch off card with a unique code. It can't be associated with the transaction.
If they don't provide an easy opt-out link then why not just block the sender and move on? Unlike the less legal operations I wouldn't expect a legitimate business to rotate domains or otherwise attempt to evade blocks.
I prefer to only report genuinely malicious behavior. As long as there's no active attempt at block evasion I figure reporting it is just increasing noise and generally making things worse for everyone. It's the active block evasion crowd that make any and every network communication protocol a pain in the ass to use at scale. It wasn't simpletons using a single static IP address that triggered such widespread adoption of Anubis overnight.
Look I'm just trying to distinguish "active circumvention of blocks" from pretty much everything else. Because the former is what destroys the usefulness of protocols while the vast majority of other things can be trivially resolved by blocking the offending party. Including { corporate service } that I don't use sending me { unwanted thing }.
If a bot that sends a fixed set of headers and is behind a single static IP is behaving poorly and slowing down your server you can block it and move on. Whereas when an abhorrently selfish operator with a client that actively hinders fingerprinting rapidly rotates through hundreds of thousands of IPs you end up with mass adoption of solutions like Anubis.
99.9% of spam is not active circumvention of blocks. It comes from so many sources you can't block them, but they are true different sources and not a block circumvention technique. That's why we decided to come down with the biggest hammer on every single source.
That doesn't match my experience at all. If I disable filtering what I see is a slew of ephemeral domains. Without DMARC I'm sure they would instead be official looking and fake.
> It comes from so many sources you can't block them,
Nonsense. If it were really countless fixed sources then a centralized domain blacklist would be sufficient. The issue is that the sources - both domain and IP - are aggressively rotated and even spoofed whenever possible.
That's how it looks now, in a world of ubiquitous spam blockers. Originally, it was each company sending you a few pieces of spam from a legitimate address.
As someone who's built an entire business on "anti-screenshots" this is brilliant.
PDF redaction fails are everywhere and it's usually because people don't understand that covering text with a black box doesn't actually remove the underlying data.
I see this constantly in compliance. People think they're protecting sensitive info but the original text is still there in the PDF structure.
Not to mention some PDF editors preserve previous edits in the PDF file itself, which people also seems unaware of. A bit more user friendly description of the feature without having to read the specification itself: https://developers.foxit.com/developer-hub/document/incremen...
This is the kind of thing that works until it spectacularly does not. XML parsing with regex is fine for simple, well-controlled cases but breaks as soon as you hit edge cases. We learned this the hard way trying to parse security questionnaire exports. Started with regex, ended up rewriting with a proper XML parser after hitting too many weird formatting issues.
CLI tools have weaker security models than their GUI counterparts bc the assumption is usually that if you have terminal access, you already have elevated privileges.
But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.
We've seen cases where AI-generated code includes snippets that look suspiciously like they came from proprietary codebases. If an AI model was trained on copyrighted code and reproduces patterns from it, who's liable? The training process makes it really hard to trace back to original sources.
The compute requirements for these models are getting wild!! We're already seeing costs become a real constraint for smaller companies trying to build AI features.
And if you're building anything serious with AI, you're basically dependent on a handful of cloud providers who control the GPU supply.
The combination of LLMs and formal verification tools is pretty interesting. We've been thinking about this for compliance automation - there are a lot of regulatory requirements that could theoretically be expressed as formal constraints. Curious about the performance though. Z3 can be really slow on complex problems, and if you're chaining that with LLM calls, the latency could get rough for interactive use cases.
Garbage collection improvements are always welcome. We've had some .NET services where GC pauses were causing noticeable latency spikes under load.
I think the regional GC approach is potentially promising if it’s for applications with large heaps. I’ll bet most web apps probably won't notice much difference though.
reply