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.