The whole point of their architecture is that they don’t have to look up your account — but that does nothing to guarantee that they don’t decide to look up your account.
Since you have to auth in order to generate the anonymized tokens, Kagi could (in principle) track which account generated the tokens and query that relationship when you go to use a token.
Ultimately, if you’re not fabricating your own silicon and hand-writing your own assemblers and compilers, you gotta trust someone, so it’s good enough for my risk profile, but I can understand if that’s not good enough for some people.
No, what they said is technically accurate.
The whole point of their architecture is that they don’t have to look up your account — but that does nothing to guarantee that they don’t decide to look up your account.
Since you have to auth in order to generate the anonymized tokens, Kagi could (in principle) track which account generated the tokens and query that relationship when you go to use a token.
Ultimately, if you’re not fabricating your own silicon and hand-writing your own assemblers and compilers, you gotta trust someone, so it’s good enough for my risk profile, but I can understand if that’s not good enough for some people.
That is factually incorrect.
Help page from Kagi (I’d understand if you don’t trust it), fit for non-techie consumption. https://help.kagi.com/kagi/privacy/how-does-privacy-pass-work.html
So here’s the RFC, which defined the protocol in the first place (Kagi didn’t invent it, just implements it) https://www.rfc-editor.org/info/rfc9576/
As such they have absolutely no way of ‘deciding’ to look up a searchers account based on the token used.
That ofcourse does not reduce other ways anyone can track you like fingerprinting.