aspensmonster

Isn't basically every package in Debian an upstream project?

>This article is about statistics and government policy. For Nazi analogies in internet discussions, see Godwin's law.

They still exist. Surprisingly, most folks aren't interested in letting every newsletter and promotion know that they were seen. So a surveillance arms race ensues instead.

>Very true, but again, the RFC describes a completely different threat model with much stronger guarantees. The Kagi threat model: > >- Does not provide Issuer-Client unlinkability > >- Does not provide Attester-Origin unlinkability

If the Client, Attester, and Origin are all a single party (Kagi), then it follows from that threat model that Kagi does not provide Kagi-Client unlinkability, no?

Further, this is not what Kagi has advertised in the blog post:

>What guarantees does Privacy Pass offer? > >As used by Kagi, Privacy Pass tokens offer various security properties (§ 3.3, of [2]).

Kagi are explicitly stating that they provide the guarantees of § 3.3. They even use more plain language:

>Generation-redemption unlinkability: Kagi cannot link the tokens presented during token redemption (i.e. during search) with any specific token generation phase. *This means that Kagi will not be able to tell who it is serving search results to*, only that it is someone who presented a valid Privacy Pass token. > >Redemption-redemption unlinkability: Kagi cannot link the tokens presented during two different token redemptions. This means that *Kagi will not be able to tell from tokens alone whether two searches are being performed by the same user*.

As it stands, Kagi cannot meaningfully guarantee those things, because the starting point is the client providing a unique identifier to Kagi.

>That said, I will point out that this Issuer-Client unlinkability issue can be solved by introducing a 3rd-party service or when Kagi starts accepting Monero payments.

Sure, but at that point, there is no need for any of the Privacy Pass infrastructure in the first place.

>Also completely valid, but also not something Kagi claims to guarantee.

I disagree. Their marketing here is "we can't link your searches to your identity, because cryptography."

>They believe the extension should be responsible for guarding attainer issuance partitioning. I don't think it's implemented currently but it shouldn't be too hard, especially since they currently use only 1 keypair.

If Kagi is going to insist on being the attester and on requiring uniquely identifiable information as the basis for issuing tokens, then yes, the only way to even try to confirm that they're not acting maliciously is to keep track not only of distinct keypairs, but also of public and private metadata blocks within the tokens, and to share all of that data (in a trustworthy manner, of course) with other confirmed Kagi users. And if a user doesn't understand all of the nuances that would entail, or all of the nuances just discussed here, and instead just trusts the Kagi-written client implicitly? Then it's all just privacy theater.

>3. CLIENT uses it's identity to request token from ISSUER/ATTESTER

The ISSUER and ATTESTER are different roles. As previously quoted, "Clients explicitly trust Attesters to perform attestation correctly and in a way that does not violate their privacy." The RFC is explicit that, when all of the roles are held by the same entity, the attestation should not rely on unique identifiers. But that's exactly what a session cookie is.

>You can see how the ISSUER/ATTESTER can identify the client as the source of the "anonymous request" to the ORIGIN because the ISSUER, ATTESTER and ORIGIN are the same entity, and therefore it can use a timing attack to correlate the request to the ORIGIN (1.) with the request to the ISSUER/ATTESTER (3.).

No timing or spacing attack is needed here. If I have to provide Kagi with a valid session cookie in order to get the tokens, then they already have a unique identifier for me. There is no guarantee that Kagi is not keeping a 1-to-1 mapping of session cookies to ISSUER keypairs, or that Kagi could not, if compelled, establish distinct ISSUER keypairs for specific session cookies.

>The signatures on the Actas are digital, not ink.

Yes, each acta has a digital signature, gathered ahead of time. It is there to compare against the inked signatures signed by the members of the mesa, after confirmation that the sampled ballots converge toward the computer's results. The ballots are the source of truth here, not what the computer receipt says. And the link between the ballots and the receipt are the inked signatures (or fingerprints) of the members of the mesa.

>What's more likely, that the opposition forged tens of thousands of receipts in less than a day, or a dictator reported fake results to remain in power?

The opposition need not have been the one to hack the machines. A third party could have done that. And again, the opposition haven't released "forged" receipts, merely receipts that have not actually been certified. How they have obtained those receipts is an open question at this point.

>Receipts, mind you, copies of which are given to each witness from the top-three political parties, at any point now could have been called into question but not a single counter example has been shown.

90% of their receipts lack any inked certification from the presidents, secretaries, members, witnesses, or operators of the mesas on the ground. That should be garnering an enormous amount of skepticism from a crowd that is normally adamant about not trusting computers during elections.

I turned it off as soon as it was debuted.

Impressed with SmashStash by iNSANE.

And it seems I'm still slowbanned/hellbanned :D I'm thinking that something like /r/undelete for HN could be really useful.