It doesn't provide 100% privacy from everyone, but it does provide privacy from the web service: A worker at a physical store checks your ID, and if it says you are 18, they hand you a token with a unique key on it, which they have a stack of behind the counter. You put the unique key into the web service. It's not necessarily one time use, but if you don't want to risk correlation, you can use each one only once. It's just like alcohol sales, and has all the same failure modes as alcohol sales, but if it's good enough for alcohol sales it's good enough for web services.
Well it probably needs a bit more complexity to avoid being trivially broken. Codes are one time use; the service has them attested by the token provider behind the scenes, and the provider is in turn under contract with the government. Tokens are also activated at the point of purchase similar to gift cards in order to prevent bulk theft and resale. A law in the vein of HIPAA prevents collusion between the retail establishment and the token provider.
>> A law in the vein of HIPAA prevents collusion
>
> No need if you use cryptography.
True for age verification, but not true in general. If you have something that can be used illegally, it's very handy to allow firms to rent / hire it out anyway but make the hirer responsible for any illegal activity.
An example is hiring a car, and the car is used to ram-raid a shop. Today this is solved by handing over a government ID to the rental company. Commit a crime in the car and they hand that over to police, but it has the sad side effect of handing over information to the car rental they can use to track you, and worse sell to others.
Using a zero knowledge proof for a valid driver's licence fixes the privacy problem, but at the expense of the hire company not being able to transfer responsibility for illegal activity onto the hirer. I suspect if that happened no one would hire out cars any more.
You can easily design something that is Zero Knowledge to the car hire firm, but includes an opaque token they can hand over to the government on lawful demand. It contains all the details needed to pursue the law breaking hirer. Thus there is still a role for the law here - you can't always do everything with crypto.
This is a very minor quibble - I agree completely with what I think is your main point. This Google change is a privacy disaster. It's a step towards an enshittified internet with the gateways onto it controlled by a few big tech firms.
But I don't think just yelling "just use ZK" is helpful. It's much harder than that - ZK is only part of the puzzle. Passkeys are currently caught up in the same attestation trap, and there is no workable solution in the offing. Banks and other high trust applications need some assurance your FIDO private key is being handled securely. The solutions on the table are Apple not doing attestation, or Google who does at the low low price of selling your true name to Google. Both "solutions" suck, horribly.
ZK proofs of things like licences and age have to solve the attestation problem, and solve extra stuff as well. I'm not holding my breath.
> But I don't think just yelling "just use ZK" is helpful.
Agreed. I am just very frustrated, because I feel it is an important topic. And I wish I saw adult discussions about it. And instead, people who claim to be "tech-savvy" keep whining about the fact that it will fundamentally leak their ID everywhere. Like they somehow understood the point for E2EE, and repeat it here confidently. If tech-savvy people can't be bothered to understand how this works, why should politicians?
I have the same frustration with the anti-5G crowd yelling that it will boil your blood. There are many valid reasons to criticise 5G and have a constructive debate, but they choose to be wrong anyway.
> If tech-savvy people can't be bothered to understand how this works
You underestimate your own abilities. Tech savvy doesn't mean they think much about crypto.
To get a feel for this I asked Gemini "If you were to survey a group of people who would be called "Tech Savvy", what percentage of them would be aware you could construct a zero knowledge proof for a person's age that revealed nothing beyond they were older than a given threshold?". The answer was 5%..10%. That rises to a surprising low 20%..30% for Software Engineers. It's only once you get to Software Engineers who write security systems that you get above 50%.
Gemini didn't give any references so those figures could be complete rubbish, but in my experience they seem on the high side. Many very experienced engineers I interact with clearly have not thought very deeply about how crypto systems interact with human trust. Granted understanding the implications of crypto is yet another step beyond understanding the maths, but I'm amazed at how many technology curious people haven't bothered to take that step.
The good pollies on the other hand probably have a very good intuitive feel for human trust systems and how to navigate them. They rely on engineers to tell them what is possible of course, and they won't care about the details. But what they will care about is whether the engineers can deliver the system they promised, and there I have to admit our track record is appalling. How many government IT initiatives have you seen deliver what was promised on time and on budget? So when you tell them you can build a ZK system that delivers in all these privacy promises, expect a very sceptical reception.
The problem with insider trading in prediction markets isn't the "prediction" part, it's the "markets" part. Once there is real money changing hands, then the purpose of the prediction market stops being "surface information" and starts being "make money" (POSIWID sense of purpose). Since the money changing hands is a necessary incentive for the insiders to provide the information, the parts cannot be disentangled and the problem is fundamental.
Note also that prediction markets can't be too different from financial markets because prediction markets are in some sense a generalization of financial markets e.g. you can make a prediction market that predicts the price of some stock on some day.
If 20 people take advantage of your buffer, then you are delayed by a distance of 20 vehicle-lengths + 20 follow-distances. This is about 1000 meters, a distance which you can travel in about 45 seconds. So the net effect of all 20 people merging in front of you is less than a minute delay on your trip. Unless there is an almost constant stream of people merging in front of you, this isn't adding up to more than a percentage point of two of your whole trip.
Hackers deliberately create strange circumstances, it's the primary way to find exploits. Any code that relies on a lack of strange circumstances is a time-bomb.
There aren't too many strange circumstances for a properly written split/test routine. Described more precisely:—
1. Split on @
2. Get last string from array
3. Convert to lowercase
4. Perform exact string compare against target domain
It's possible that there's some window for obscure unicode hijinks, but I'd posit that a regexp parser or a "proper" email parsing library is just as at-risk. Possibly more so as those would be significantly more complicated and involve significantly more code.
0.1-1% hire rate based on applicants, or based on candidates interviewed? 0.1% hire rate of candidates interviewed doesn't seem compatible with your described growth rate, even if you very conservatively assumes you spend 1 hour interviewing each candidate, thats 25 weeks of straight interviewing per candidate hired. And thats 1 hour of time across the whole company, if you have 2 interviewers spend an hour each, thats now 50 employee-weeks, or an entire year. To double the company size in 5 years, you would have needed to spend 1/5th of your entire tenure interviewing. If you go up to 10 total hours spent per candidate (including all interviewers, recruiters, and time spend in discussion and negotiation) it becomes straight up impossible.
So to be clear for a given position you get 100 to 1000 resumes, then interview how many of those before deciding on 1 person? I am curious what the funnel looks like.
It depends entirely on the size and quality of the candidate pool, but I'd say very roughly:
* Initial candidate screening reduces the pool by 85–95% (leaving 5–15% of the initial pool)
* Interview #1 reduces the pool further by 50–66% (leaving ~3–4% of the initial pool)
* Interview #2 reduces the pool further by another 66–75% (leaving ~1–2% of the initial pool)
* Final chat usually doesn't reduce the pool, but it's one last pass for additional signal
* We choose a single candidate of whoever remains
For a position with 400 applicants, it could look like
* Initial screening leaves 40 candidates for interview #1
* Interview #1 leaves 15 candidates for interview #2
* Interview #2 leaves 4 candidates for final chat
* We pick from those final 4
Most people don't start shopping at grey/black markets in order to avoid paying sales tax. Most people don't pay their employees under the table to avoid paying income tax. Most people don't move or de-value their own homes in order to avoid paying income tax. Those taxes make up most tax revenue, and wouldn't get caught in that definition.
> I - and I get the impression that's true for many developers - learned early to minimize the custom config.
I get the exact opposite impression. My understanding is that as developers become more experienced, they tune their setup more, and have more and more persisted customizations. I consider sshrc[1] a critical part of my workflow for this reason.
> But why would one need that? Is your environment that random?
Most shells by default will occasionally spew out "garbage" text into the terminal like ^[[A. If you know why this happens it's possible to fix, but it's definitely a pain. Personally I consider it very important that all the places that I input text work consistently (e.g. move cursor by word, move cursor to end of line) and Warp providing that is a huge selling point to me.
