See section 5.5 of the linked paper https://petsymposium.org/popets/2018/popets-2018-0026.php. I'm not sure if/how Kagi implemented this, but the idea is that Kagi's "public" component can be committed to publicly (e.g., in the browser extension itself).
And you can validate this, if you try to issue a Privacy Pass search without a private token, you'll get a `WWW-Authenticate` header that kicks off the handshake, and that should be the same for all users for a given epoch (month). E.g.
But how do I validate that I’m actually getting the same value as everyone else? Is the value I should get published somewhere (in a verifiable and not editable way) so I can see that I’m not being tracked?
Or does the extension validate this and the correct value is hardcoded in the extension like stebalien suggested?
There's no auth required at this stage of the handshake, so you can test from any number of devices/locations/networks/etc and confirm you get the same value. We could publish it, but it will change every epoch/month. Plus, if you don't trust the service to not issue special key pairs to track you, you probably won't trust us to not do the same when publishing the key material. There are schemes involving third-parties we could employ, but it's trust and turtles all the way down.
A malicious server could maintain separate key pairs for users it wanted to track, but you can't do it for every user because 1) it'd be clear from the WWW-Authenticate header changing, and 2) you'd have to validate tokens against every key, which would quickly get too slow to work.
Makes sense in general, but to make sure I understand it:
> Plus, if you don't trust the service to not issue special key pairs to track you, you probably won't trust us to not do the same publishing the key material.
You could publish it on some sort of blockchain to make sure it can’t be changed and is public for everyone, right?
> A malicious server could maintain separate key pairs for users it wanted to track, but you can't do it for every user because 1) it'd be clear from the WWW-Authenticate header changing, and 2) you'd have to validate tokens against every key, which would quickly get too slow to work.
Private companies != federal government. See https://en.wikipedia.org/wiki/Strict_scrutiny, there's no way the federal government will be able to argue that it has a legitimate interest in banning pronouns in signatures.
The privacy pass extension still requires you to pass a cloudlare turnstile which is impossible in some browser configurations. E.g., if you disable browser performance-debugging/timing features (these used to be a vector for Spectre timing attacks).
I'm not a professional analyst but the numbers look weird to me. Prediction was to sell 507,000 in Q4, they delivered 497,570, but only made 459,445. That means that they had almost 35.000 cars "laying around" from Q3 that they delivered in Q4. That seems a bit weird to me. But maybe someone that monitors the big 3 automakers in the USA can comment on how many cars waiting in the pipeline is a normal amount.
Also the total 2024 production shows something very interesting: Tesla is a one-trick pony. They sold 1,77 million cars, of which 1,70 million were model 3/Y. So the Model S, X, and cybertruck only make up 85,000 cars. That is not healthy for the long term. Because the Model 3 and Y compete in the middle class price wise, so nobody buys expensive Tesla's. And nobody can buy a cheap Tesla because there is no 25k Toyota Corolla equivalent.
It will be interesting to see in the next years if Tesla can make a dent in other price segments.
This attack doesn't allow anyone to, e.g., bypass any PINs you may have set on your yubikey. It allows an attacker to extract your keys if and only if they can already use your yubikey.
From what I can tell, the risk is:
1. Someone takes your yubikey without your knowledge.
2. They manage to disassemble it, extract your key, and put it back together.
3. They secretly return your yubikey.
4. You continue to use your yubikey, unaware of the fact that it has been compromised.
