In an age of malicious agentic AI, this level of access is negligent. A lack of engineering controls preventing this from happening at all means that a simple phishing or supply chain attack could easily have resulted in the same outcome or worse.
This sort of conversion gets coverage every once in a while and it's been neat to see old frames getting chopped onto new electric drivetrains. I spoke with one of the people interviewed in this article[1] a couple years back about converting an old truck I have sitting around into an EV.
The Model 3 approach takes their unified rear axle (motor,axle,wheels) and mounts it into an existing frame. Then you just need to find a place to stuff the batteries, retrofit some high-voltage electronics, and you're off to the races. One of the drawbacks of that approach is that it changes the stance of the vehicle, but for this Mustang that doesn't seem to matter much - it still looks classic.
Other converters either go for the high end with a model S and fit the motor into a traditional drivetrain for a sleeper build, or they go for the low end and take an old forklift motor and batteries and build what is effectively a street-legal golf cart. Prices range from $5-100k depending on your level of DIY and how dangerous of a classic car you want on the other side of the process.
sounds like a good opportunity to bring back "letters of marque." These were less about authorizing ships to fight back against pirates, and more about authorizing private to your army to find and capture pirate vessels with the expectation that they would be allowed to keep whatever loot they captured. sounds like we're taking a step in that direction as the Internet is being identified as Lawless as the sea.
It says something about modern Congress that when one of the powers explicitly granted to Congress became relevant for the first time in 100 years, their first instinct was to delegate it away to the President.
For the skeptics here, this is the exponent thats driving the development of datacenters in space. The data has utility but it will be stuck in orbit. Space-based storage and processing makes a lot more sense when you consider that getting all that data to ground is challenging now, and will soon be impossible.
Yes, the original film for moon explorer has been stuck in orbit around the moon for decades. The world had a large network of satellite communications, and there was Arciebeo, but if it's not done here ... A few microwave dishes on all the NSF buildings should easily take are of it. Oh we had those ... But... What about streaming tape? Just ask Uncle Vint.
We are missing accessible cryptographic infrastructure for human identity verification.
For age verification specifically, the only information that services need proof of is that the users age is above a certain threshold. i.e. that the user is 14 years or older. But in order to make this determination, we see services asking for government ID (which many 14-year-olds do not have), or for invasive face scans. These methods provide far more data than necessary.
What the service needs to "prove" in this case is three things:
1. that the user meets the age predicate
2. that the identity used to meet the age predicate is validated by some authority
3. that the identity is not being reused across many accounts
All the technologies exist for this, we just haven't put them together usefully. Zero knowledge proofs, like Groth16 or STARKs allow for statements about data to be validated externally without revealing the data itself. These are difficult for engineers to use, let alone consumers. Big opportunity for someone to build an authority here.
>We are missing accessible cryptographic infrastructure for human identity verification.
like most proposed solutions, this just seems overcomplicated. we don't need "accessible cryptographic infrastructure for human identity". society has had age-restricted products forever. just piggy-back on that infrastructure.
1) government makes a database of valid "over 18" unique identifiers (UUIDs)
2) government provides tokens with a unique identifier on it to various stores that already sell age-restricted products (e.g. gas stations, liquor stores)
3) people buy a token from the store, only having to show their ID to the store clerk that they already show their ID to for smokes (no peter thiel required)
4) website accepts the token and queries the government database and sees "yep, over 18"
easy. all the laws are in place already. all the infrastructure is in place. no need for fancy zero-knowledge proofs or on-device whatevers.
The government will want some way to uncover who bought the token. They'll probably require the store to record the ID and pretend like since it's a private entity doing it, that it isn't a 4A violation. Then as soon as the token is used for something illegal they'll follow the chain of custody of the token and find out who bought it.
No matter what the actual mechanism is, I guarantee they will insist on something like that.
if the goal is to "protect children", or just generally make parts of the internet age-gated, my proposal is 100% fine.
if the goal is "surveil everyone using the internet", yes, very obviously my proposal would not be selected, and you will have to upload your id to various 3rd-party id verifiers.
I think something like your proposal actually sounds the most logical. I just think they will bolt on chain of custody tracking to it, while promising it will only be used for finding "terrorists" or something.
Yes, while I was reading the article I couldn't help but think about notaries public. Seems like something like that would be government's go-to for this if they weren't quite so overfed on tech industry contributions that lead them down the path of AI solutions.
I'm not sure that's the right answer here, but I think it ticks a lot boxes for the state.
The nice thing about something bolted on like that is that it is not an essential feature of the core design and has no bearing on the original goal. It can be removed or reformed. The same isn't true of the approaches we are heading towards now.
What you’re describing is infrastructure that doesn’t necessarily exist right now for use online, and has all the privacy problems described. Why should I have to share more than required?
it has none of the privacy problems described, and 95% of the infrastructure exists right now (have you ever purchased smokes or alcohol?)
to go on tiktok, you enter a UUID once onto your account, and thats it. the only person that sees your id card is the store clerk that glances at the birth date and says "yep, over 18" when you are buying the "age token" or whatever you want to call it. no copies of your id are made, it cant be hacked, theres no electronics involved at all. its just like buying smokes. theres no tie between your id and the "age token" UUID you received.
theres no fanciness to it, either. itd be dead simple, low-tech, cheap to implement, quick to roll out. all of the enforcement laws already exist.
>Why should I have to share more than required?
you shouldnt. having to prove age to use the internet is super dumb. but thats the way the winds are blowing apparently. if im gonna have to prove my age to use the internet, id much rather show my id to the same guy i buy smokes from (and already show my id to) than upload my id to a bunch of random services.
The problem with this scheme is that it's exactly as protective as requiring someone to tick a "I'm of legal age" tickbox in the software they wish to access. Anyone who is of legal age can buy UUIDs and pass them around to folks who are not.
Having said that, I think having an "I'm of legal age" tickbox goes quite far enough.
For the ultra-controlling, setting up a "kid's account" using the tools already provided in mainstream OS's [0][1] is a fine option.
>The problem with this scheme is that it's exactly as protective as requiring someone to tick a "I'm of legal age" tickbox in the software they wish to access.
no, it is exactly as protective as the protections for purchasing alcohol or buying smokes or other controlled substances/products.
buying smokes/alcohol when underage is obviously harder than "click this box". (did you ever try to buy smokes/alcohol when underage? you cant just go up to the clerk at the store when you are 14 and say "trust me bro, im 18/19/21".)
>Anyone who is of legal age can buy UUIDs and pass them around to folks who are not.
same for smoking and alcohol. i could go to the store right now and buy smokes, then hand them to my 10 year old.
we have laws already in place to punish selling smokes/alcohol to underagers, and laws for consuming smokes/alcohol when underage. we can apply those laws to your internet-age-token.
most people seem fine with the current trade-off for smokes/alcohol. i see no reason why tiktok needs to be treated as more dangerous than either.
>Having said that, I think having an "I'm of legal age" tickbox goes quite far enough.
i agree with this and everything you said afterwards. id rather not have any of it.
> no, it is exactly as protective as the protections for purchasing alcohol or buying smokes...
Right. That's exactly as protective as that tickbox. [0] As I mentioned, any of-age person can distribute those UUIDs to people who are not of-age. Unlike with the proposed ID-collection-and-retention schemes (that are authoritarian's wet dreams) the vendor of the UUID is not responsible for ensuring that that UUID is not later used by someone who is not of-age.
If you were to -say- make alcohol vendors liable for the actions of of-age people who pass on alcohol to not-of-age people, then you'd see serious attempts to control distribution.
[0] Don't forget the existence of preexisting parental controls in every major OS. IME, this is a hurdle that's at least as difficult to surmount as the ID check done in non-chain convenience stores.
>Right. That's exactly as protective as that tickbox. [0]
no, it isn't, for reasons already mentioned but i will say it again for clarity:
- a 14 year old can click "im of age" on a checkbox.
- a 14 year old cannot go into a gas station and buy smokes. they will be declined.
>As I mentioned, any of-age person can distribute those UUIDs to people who are not of-age.
again... same with smokes and alcohol! but we are okay with how smokes and alcohol are regulated right now.
tiktok is not worse than a bottle of vodka. we are okay with how vodka is regulated. tiktok does not need even more strict age-verification than vodka.
it is not perfect, but it is absolutely more stringent than a checkbox. if you still doubt me, please send one of your 12-14 year old family members to buy a pack of smokes or a bottle of vodka at the nearest store. i will wait for your report.
Your hypothetical 14-year-old needs to first be able to bypass the parental controls that come with every modern OS. You keep ignoring that.
(Also, like, did you ever go to college? Live in a dorm or apartment with underage students? It was super common for of-age people to buy and distribute booze to substantially underage students. Everyone knew it was happening all the damn time.)
> they are obviously not liable if i buy something legitimately, go home, and feed it to my kid. in that case, i am liable...
And if you changed up the rules to make them liable, you'd see serious attempts at controlling distribution.
What has been the state of the art in parental controls for quite some time is like the current regulatory regime for booze and tobacco. The single thing that needs to change to make it exactly the same would be to make it substantially illegal for US-based publishers to not tag the porn/violence/etc that they publish with age-restriction tags. [0]
What's being proposed and is currently implemented by several big-name sites is even more invasive.
> we are okay with how smokes and alcohol works right now.
I'm not. Either booze and tobacco need to be made into Schedule I substances, or their regulation needs to become much more lax. But I recognize that my opinion on the topic is considered to be somewhat out-of-the-ordinary.
[0] This might already be the law of the land right now. I haven't bothered to check.
>Your hypothetical 14-year-old needs to first be able to bypass the parental controls that come with every modern OS. You keep ignoring that.
because they dont matter. parental controls exist today but have been deemed ineffective for the age verification conversation, for whatever stupid reason. so we are stuck trying to figure something else out. do i wish we could just use the existing basic parental controls instead of whatever the hell we are going to end up with? obviously!
the easiest "something else" is to piggy-back on existing age-restriction regulations (i.e. smokes, alcohol, gambling) because they have broad (obviously not ubiquitous, but broad) support. we have decades of experience with them.
and, to that end, you create a little token and you show your id to the store clerk to buy it. the "protect the children" people are satisfied (its the same process everything else age-restricted!), and i dont need to send my id to a peter thiel company. it preserves privacy, it re-uses existing laws, it re-uses existing infrastructure, etc.
> ...but have been deemed ineffective for the age verification conversation, for whatever stupid reason.
Consider that such arguments (just like the arguments of Prohibitionists that resulted in the rise to power of Organized Crime) are made in a varied combination of ignorance and bad faith, and that we should loudly reject them in the strongest possible terms.
To be clear, I'm asserting that the claim that preexisting parental controls are insufficient is an argument made in ignorance and bad faith, not your assertion that the argument is being made.
>Consider that such arguments [...] we should loudly reject them in the strongest possible terms.
me and you can yell into the void all we want. and i will continue to do so!
but, age verification is already here. so while i continue to yell about how stupid it is, i am also going to propose options that i feel like are less bad than what is being actively rolled out right now.
> ...i am also going to propose options that i feel like are less bad than what is being actively rolled out right now.
As I mentioned, what you propose is exactly as useful and protective as what we have now. What we have now has been roundly rejected by the authoritarians pushing this expansion of power and influence. Your time and energy are better spent resisting the expansion, rather than suggesting alternatives that those authoritarians will never accept (and tacitly accepting their premise in the process).
It's very rare to run into anyone under 18 living in a college dorm. There are a few 17 year olds, even fewer younger than that. Sure there are high schoolers taking classes, but as full-time residential students? Not many.
I mostly agree but unless these UUID age tokens are of limited life, it's more like buying the kid an unlimited amount of vodka and cigarettes with one action. If the tokens were good for one use, or a short time period, it would be more workable.
> or make them good for 1 month, but sold in 12-packs.
...if these tokens are as protective as you claim they are, why would it be important for them to expire?
Would you also advocate for the token issued by authoritarians' preferred "send a video of yourself [0] and/or your government-issued photo ID [1] to some random third-party for-profit company" check to frequently expire? If not, what's up with the discrepancy?
[0] Or of someone physically near you who is of-age
you seem really eager to catch me in some sort of "aha gotcha!" scenario so that you can... what? feel good about winning a hackernews argument? you are trying to argue with someone who largely shares the exact same views as you. the only difference between us is that im offering up alternatives and you are hoping that if you yell loud enough that everyone will forget about age verification.
age verification is already being rolled out. so we can either suck it up and try advocate for less shitty versions, or we can bicker amongst ourselves while id/video-based age verification continues to be implemented everywhere.
>...if these tokens are as protective as you claim they are, why would it be important for them to expire?
read above for the conversation that occurred.
>Would you also advocate for the token issued by authoritarians' preferred "send a video of yourself [0] and/or your government-issued photo ID [1] to some random third-party for-profit company" check to frequently expire? If not, what's up with the discrepancy?
a) no, obviously not, because i dont advocate for video or id-based age verification.
b) i know that you know this, and are just pretending to be ignorant for some weird ass reason: various age verification implementations have different risks and benefits.
for some implementations, users are forced to give up significant amounts of privacy in favor of increased accuracy. other implementations give up less privacy, at the risk of reduced accuracy. look at discords implementation for a recent example (it was easier to spoof the client-side verification than the server-side id-based one. more privacy, less accuracy). this type of balancing act is not new. we do the same balancing act with alcohol, smoking, gambling, healthcare, security, development, etc.
so, when looking at potential mitigations for less-accurate methods, while maintaining the same level of privacy, a sensible option is to make the UUIDs time-bound which will limit the time an illicit token is valid. this makes much less sense for id/video-based verification, because they have higher accuracy than my version (paid for by giving up your privacy).
---------
something you said earlier: "Your time and energy are better spent resisting the expansion,".
so, go do that. find the people that are really pushing for age verification, and argue with them. instead of replying to me, use that time to call your state representative or something. im not your opponent here. if it were up to me, we wouldnt have age verification in the first place. you already know that my stance is anti-age verification!
my proposal is not perfect. i dont like age verification. you can have the karma from this argument, its cool, you can "win". what more do you want me to say?
So was "REAL ID", and that took ~fifteen years to bring all the holdouts to heel. It wasn't till the start of the COVID disaster that FedGov could make compliance a condition of receiving enough essential Federal funds to force the remaining objectors to comply.
Compliance with bad plans is not automatically mandatory.
> what more do you want me to say?
It'd be great if you'd stop accepting the premise of authoritarians and reject the publicly-stated premise that motivates these systems. While it may not be clear to folks at the moment, they are no less bad than the systems that help -say- Texas law enforcement track down Texan women and doctors who are in violation of the Texas abortion ban.
I don't give a shit if you say that you do stop accepting the publicly-stated premise. [0] I just hope that one day in the not too distant future you do.
[0] I would -in fact- not believe you if you said you did in reply to this comment.
> Compliance with bad plans is not automatically mandatory.
To put a really fine point on this: every entity that rolls over and compiles with these "age verification" plans has put up less of a fight than 4chan.
When 4chan is one of the heroes, you know that something rotten is going on.
A significant obstacle to adoption is that cryptographic research aims for a perfect system that overshadows simpler, less private approaches. For instance, it does not seem that one should really need unlinkability across sessions. If that's the case, a simple range proof for a commitment encoding the birth year is sufficient to prove eligibility for age, where the commitment is static and signed by a trusted third party to actually encode the correct year.
I agree. I've been researching a lot of this tech lately as a part of a C2PA / content authenticity project and it's clear that the math are outrunning practicality in a lot of cases.
As it is we're seeing companies capture IDs and face scans and it's incredibly invasive relative to the need - "prove your birth year is in range". Getting hung up on unlinkable sessions is missing the forest for the trees.
At this point I think the challenge has less to do with the crypto primitives and more to do with building infrastructure that hides 100% of the complexity of identity validation from users. My state already has a gov't ID that can be added to an apple wallet. Extending that to support proofs about identity without requiring users to unmask huge amounts of personal information would be valuable in its own right.
Even if the problem is perfectly solved to anonymize the ID linked to the age, you still have the issue that you need an ID to exercise your first amendment right. 1A applies to all people, not just citizens, and it's considered racist in a large part of the US to force someone to possess an ID to prove you are a citizen (to vote) let alone a person (who is >= 18y/o) w/ 1A rights.
Your crypto nerd dream is vulnerable to the fact that someone under 18 can just ask someone over 18 to make an account for them. All age verification is broken in this way.
There is a similar problem for people using apps like Ubereats to work illegally by buying an account from someone else. However much verification you put in, you don't know who is pressing the buttons on the screen unless you make the process very invasive.
You seem to have missed requirement #3 -> tracking and identifying reuse.
An 18-year-old creating an account for a 12-year-old is a legal issue, not a service provider issue. How does a gas station keep a 21-year-old from buying beer for a bunch of high school students? Generally they don't, because that's the cops' job. But if they have knowledge that the 21-yo is buying booze for children, they deny custom to the 21-yo. This is simple.
> How does a gas station keep a 21-year-old from buying beer for a bunch of high school students?
They don't? Teenagers can easily get their hands on alcohol... you just need to know the right person at school who has a cool older brother. If their older brother is really cool they can get weed too!
The police absolutely do not have the time to investigate the crime of making a discord account for someone.
In general, any government already has your information, and it's naive to think that they don't; if you pay taxes, have ever had a passport, etc. they already have all identifying information that they could need. For services, or for the government knowing what you do (which services you visit), then a zero-knowledge proof would work in this case.
Maybe code is free, but code isn't all that goes into building software. Minimally, you have design, code, integrate, test, document, launch.
Claude is going to help mostly with code, much less with design. It might help to accelerate integration, if the application is simple enough and the environment is good enough. The fact is, going cross-platform native trebles effort in areas that Claude does not yet have a useful impact.
That's just a harness diff. A few more iterations of bootstrapping and the harness will be able to do the whole lifecycle.
The disturbing fact is that AI is simply smarter than us by a stupendous margin. Anything you do that involves thinking can be done better by the AI. We are obsolete when it comes to being smart.
I was in denial about this for a couple years, but I understand now.
At 16k tokens/s why bother routing? We're talking about multiple orders of magnitude faster and cheaper execution.
Abundance supports different strategies. One approach: Set a deadline for a response, send the turn to every AI that could possibly answer, and when the deadline arrives, cancel any request that hasn't yet completed. You know a priori which models have the highest quality in aggregate. Pick that one.
The best coding model won’t be the best roleplay one which won’t be the best at tool use. It depends what you want to do in order to pick the best model.
I’ll go ahead and say they’re wrong (source: building and maintaining llm client with llama.cpp integrated & 40+ 3p models via http)
I desperately want there to be differentiation. Reality has shown over and over again it doesn’t matter. Even if you do same query across X models and then some form of consensus, the improvements on benchmarks are marginal and UX is worse (more time, more expensive, final answer is muddied and bound by the quality of the best model)
There is the pre-training, where you passively read stuff from the web.
From there you go to RL training, where humans are grading model responses, or the AI is writing code to try to pass tests and learning how to get the tests to pass, etc. The RL phase is pretty important because it's not passive, and it can focus on the weaker areas of the model too, so you can actually train on a larger dataset than the sum of recorded human knowledge.
I agree completely. It's a mistake to anthropomorphize these models, and it is a mistake to permit training models that anthropomorphize themselves. It seriously bothers me when Claude expresses values like "honestly", or says "I understand." The machine is not capable of honesty or understanding. The machine is making incredibly good predictions.
One of the things I observed with models locally was that I could set a seed value and get identical responses for identical inputs. This is not something that people see when they're using commercial products, but it's the strongest evidence I've found for communicating the fact that these are simply deterministic algorithms.
I've made many business cases for internally-built SaaS tools, and they always rest on the idea that our probability of success is higher if we staff a team and build the _exact thing_ we need versus purchasing from a vendor and attempting an integration into our business.
It's far more challenging to win the 'build' argument on a cost savings approach, because even the least-savvy CIO/CTO understands that the the price of the vendor software is a proof point grounded in the difficulty for other firms to build these capabilities themselves. If there's merit to these claims, the first evidence we'll see is certain domains of enterprise software (like everything Atlassian does) getting more and more crowded, and less and less expensive, as the difficulty of competing with a tier-1 software provider drops and small shops spring up to challenge the incumbents.
Agreed. I was going to add (but didn't) that the first evidence of an 'AI unlock' on SaaS wouldn't be internal builds but many new, much cheaper competitors appearing for leading SaaS tools. Your point about the best arguments to internally build SaaS being 1) integration savings, and 2) better fit, is spot on. But senior management has to balance those potential benefits (and the risk an internal effort fully delivers on-time & budget) against sticking with 'the devil we know' which works (imperfectly) today.
In my experience, a bigger blocker to C-level approving internal SaaS development is it diverts capital and scarce attentional bandwidth to 'buying an upside' that's capped. Capped how? Because, by definition, any 'SaaS-able' function is not THE business - it's overhead. The fundamental limit on a SaaS tool's value to shareholders is to be a net savings on some cost of doing business (eg HR, legal, finance, sales, operations, support, etc). No matter how cheap going in-house makes a SaaS-able activity, the best case is improving margins on revenue. It doesn't create new revenue. You can't "save your way" to growth.
100% of my LLM projects are written in Rust - and I have never personally written a single line of Rust. Compilation alone eliminates a number of 'category errors' with software - syntax, variable declaration, types, etc. It's why I've used Go for the majority of projects I've started the past ten years. But with Rust there is a second layer of guarantees that come from its design, around things like concurrency, nil pointers, data races, memory safety, and more.
The fewer category errors a language or framework introduces, the more successful LLMs will be at interacting with it. Developers enjoy freedom and many ways to solve problems, but LLMs thrive in the presence of constraints. Frontiers here will be extensions of Rust or C-compatible languages that solve whole categories of issue through tedious language features, and especially build/deploy software that yields verifiable output and eliminates choice from the LLMs.
I've found it's terrible at digesting a few codebases I've needed to deal with (to wit, 2007-era C# which used lots of libraries which were popular then, and 1993-era Visual Basic which also used from third party library that no LLM seems to understand the first thing about).
> This appears to be a custom template system from the mid-2000s era, designed to separate presentation logic from PHP code while maintaining database connectivity for dynamic content generation.
That's great. Just yesterday I spoke with a developer who refutes Rector on old codebases, instead having an LLM simply refactor his PHP 5.6 to 8.(3 I think). He doesn't even check in Rector anymore. These are all bespoke business scripts that his team have been nursing for two decades. He even updated the Codeigniter framework it's all running on.
I suspect the problem with VB is that VB 4 and 5 (which I think was that era) were so closely tied to the IDE it is difficult to work out what is going on without it.
(I did Delphi back when VB6 was the other option so remember this problem well)
