I have some experience with zkp, so I’ll try to answer your question to the best off my ability. First on the terminology, the “attester” in this case I assume is whoever is anchoring the data or issued the credential you’re trying to prove. For the canonical example, let’s say you’re trying to prove age >= n via a government ID.

1. The site does not know who you are. This is the whole point. You generate a mathematical proof you possess a valid government ID that says “age >= n”

2. Yes. You are generating a zkp based on information anchored by the attester. In this case the ID issuing gov. That attester can be something other than a gov, but zkps are a bit useless if the site doesn’t know what exactly is being proved. In this case you are proving “I possess a government ID saying age >=n”. You must know about the government to care about this proof.

3. Not in this case. The attester only knows it has issued you an ID, but does not need to be further consulted. You could certainly construct a scheme such that you require a ZKP of recent written permission from some entity, but this is not inherent to ZKPs.

4. This is a UX question. If the ZK wallet and website are implemented in such a way that it’s always displayed when a credential is requested and what credential that is, then yes.

I'm not an expert either, but i've studied it a little and tried some of these stuffs.

First, the attestor is not google. Google here only provides the infra (to generate proof and verify them). Let's call the attestor the issuer, and it's the trusted authority that gives you a proof of identity.

A possible flow is:

1. (pre-req) Some issuer (a state, bank, mobile operator, etc.) issues a signed credential to my wallet (stored on my phone, for instance). This could be a full digital ID, or a narrower “proof of age” attestation.

2. Later, a site asks my browser for a proof that I satisfy some predicate, e.g. age >= 18. The site provides the "zk-program" (circuit) that needs to be executed, and awaits for proof (which are essentially proof of executions of the program on trusted yet undisclosed inputs).

3. My phone generates (ideally locally, but not ready today yet) a ZK proof that it knows a valid issuer-signed credential whose hidden attributes satisfy that predicate. Essentially, it is executing the circuit with some inputs (some are public, like public key of issuers, some of private, like the issued ID)

4. The site verifies the proof against public inputs: the issuer public key, the circuit being used, the predicate being requested, and a fresh nonce/challenge.

So to answer some of your questions.

> Does the site know who I am? Not from the ZK proof itself, it will know who has issued your ID.

> Does the site know my attestor? Yes, it knows their public key.

> Does the attestor know what site I am visiting? No.

> Does the attestor know who I am? Yes

> Do I know who the site and attestor are, and when proof happens? I guess there are multiple possible ways to do this, depends on the UX.

I tried to find something definitive, but it would take more time than I have right now. So to some degree this is assumptions, though generalized.

* Does the site know who the user is: No. That's the entire purpose here.

* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).

* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.

* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)

* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.

--Googler, though far removed from this project, so no internal knowledge.

Its not really possible to know.

the system is valid zkp but any of the services in practice can still collect personally identifiable information from their users.

There is also nothing stopping the attestor to collude with the site you want to access, to reveal information about you.

Computer Scientist Explains One Concept in 5 Levels of Difficult

https://www.youtube.com/watch?v=fOGdb1CTu5c

This video is very beautifully explains it

There is an important question you haven't asked: As presented, is this system secure for the implied use cases?

And the answer to that is a resounding no. As long as you can run software of your choosing, then it is trivial to proxy a zero knowledge proof such that a third party can provide proof of the given property for you to use. If the system is really zero-knowledge, then that third party will suffer no repercussions for defeating the purpose of the system. And we can easily imagine people willing to provide this service (for ideological reasons and/or simply payment).

To be secure, all of these schemes rely on an unstated assumption of remote attestation that will prevent users from running their own software. Locking down computing is Google's basic agenda, but saying this would make the systems less appealing to people, so they obviously downplay it.