I.e. you would "authenticate your use of the web/internet" with a unique token. This token will be bound to your browser/client/computer/user account uniquely. No matter how this is called, this is not (overall) privacy-preserving, and your use of the 'net will depend on if the attester will attest your client. i.e. using this protocol the attester will have all control over your access, and is much worse than a captcha system, since it adds a cryptographic layer and the potential of locking down based on your device characteristics/identification (i.e. hardware!). While your privacy may be better protected between you and the server you are trying to visit since the server will only verify a token and not request details from you directly, and rely on a third party (although in CF's case that's not a given!), your privacy is compromised to a greater extent by having to deal with an attester:RFC9578 wrote:The Privacy Pass protocol provides a privacy-preserving authorization
mechanism. In essence, the protocol allows Clients to provide
cryptographic tokens that prove nothing other than that they have
been created by a given server in the past
RFC9576 wrote:In Privacy Pass, attestation is the process by which an Attester bears witness to, confirms, or authenticates a Client so as to verify properties about the Client that are required for issuance. Issuers trust Attesters to perform attestation correctly, i.e., to implement attestation procedures in such a way that those procedures are not subverted or bypassed by malicious Clients.[RFC9334] describes an architecture for attestation procedures. Using that architecture as a conceptual basis, Clients are RATS Attesters that produce attestation evidence, and Attesters are RATS Verifiers that appraise the validity of attestation evidence.The type of attestation procedure is a deployment-specific option and outside the scope of the issuance protocol. Example attestation procedures are below.
* Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client.
* Presenting evidence of Client device validity. Some Clients run on trusted hardware that is capable of producing device-level attestation evidence.
* Proving properties about Client state. Clients can be associated with state, and the Attester can verify this state. Examples of state include the Client's geographic region and whether the Client has a valid application-layer account.
Important questions to ask: Who will be this attester? If the extension is ported to Pale Moon, will the attester accept it as a valid client when presenting itself? What criteria will the attester use? Who controls the attestation process?
This goes way beyond mere capabilities testing or presenting human/scripting challenges.
-bruce /* 
