Re: [Privacy-pass] The harms of popular bits

Tommy Pauly <> Wed, 20 March 2024 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E633C14F69C for <>; Wed, 20 Mar 2024 16:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id le6nScyMmJr8 for <>; Wed, 20 Mar 2024 16:36:52 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 82B3CC14F693 for <>; Wed, 20 Mar 2024 16:36:52 -0700 (PDT)
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <> for; Wed, 20 Mar 2024 23:36:51 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib: definitions=2024-03-20_12,2024-03-18_03,2023-05-22_02
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=crWJXK3qR9HECm6TnlsygECnyda/k61mq9jIxfAQpRA=; b=jJ95dGOp61wy8w7w7dS7RlvJ+YFdm+f/VgAIL3YcshouGcohtFpESQENyjfMx5+m2Xbn q3kc7YRj2U7gAUU+juwjukDNzWV9HL3XSYGhJlN5TshMnsJrY/nAl19+pn18z/h/1VtU 5QddxS2CUyHZK4lgIbEWH8K4+7vNZXytGVjqWuw8mShK/bMs65YD9ALrZyqnEhZ+GOcO uoLoRR6P8jTeOB0umqZgyc7jHtMWlsTrohrkXhGai57bVMIwH6fhulNNOlhYjdzzvbgL lGoUdF1UciKHc1z6GmBapwxPZYgjnXUzHcEnRLS44kbJzVrvpohfx/Jt+LKEU93b5V78 nA==
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <>; Thu, 21 Mar 2024 07:36:48 +0800 (+08)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) id <>; Thu, 21 Mar 2024 07:36:48 +0800 (+08)
X-Va-T-CD: 5a79c165eae7bca3e214413a625caeec
X-Va-E-CD: c9ffe58cfb2e7540cac7826a0bde3a2e
X-Va-R-CD: aa96901a2922dab45381f6eea9cea460
X-Va-ID: b55213ab-bb4f-4847-9d6f-a3b026167065
X-Va-CD: 0
X-V-T-CD: 5a79c165eae7bca3e214413a625caeec
X-V-E-CD: c9ffe58cfb2e7540cac7826a0bde3a2e
X-V-R-CD: aa96901a2922dab45381f6eea9cea460
X-V-ID: 8417d4d3-3d51-493a-b499-fe7645860248
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib: definitions=2024-03-20_12,2024-03-18_03,2023-05-22_02
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPSA id <>; Thu, 21 Mar 2024 07:36:48 +0800 (+08)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_D5D986FF-8E0A-4C28-880E-DF60C200DC41"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Thu, 21 Mar 2024 09:36:36 +1000
In-reply-to: <>
To: Watson Ladd <>
References: <>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <>
Subject: Re: [Privacy-pass] The harms of popular bits
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2024 23:36:56 -0000

I do think that the model (unified attester+issuer vs split attester/issuer) does make a difference here. If the client (via trust) has a better awareness of (a) what it discloses to the attester and (b) what the common properties and size of of the anonymity set through that attester are, then there is far less ability to have the bit be linked to unwanted characteristics. I.e., if I’m using an attester that is used by an Apple device, I know that the bit that I’m expressing from the Attester to the Issuer (if I trust it not to leak more) is that I’m on a particular device type, and then that the bit to the origins is the combination of that bit with the bits of all other Attesters the Issuer trusts.


> On Mar 20, 2024, at 11:26 PM, Watson Ladd <> wrote:
> Dear privacy pass WG,
> I think the discussion of harms in the web context missed the issue, which I'll admit was rather subtly presented. Issuers might not be issuing tokens based on attributes like bot or not but rather characteristics such as race or religion we'd prefer not to. This even happens innocently.
> Using private state tokens as an example social networks and dating sites have a lot of information about user interaction and humanity as a result. But I don't think we want sites to hunt for tokens from dating sites that may be oriented to particular demographics.
> This can even happen unintentionally. If you have some sort of model looking at how users interact based on the bits you have and then selecting offers to show based on it this can end up discriminating even though the bit officially means human. It's just who issued it reveals more than that, even if they issue often.
> I hope this clarifies the remarks I made at the mic.
> Sincerely,
> Watson
> -- 
> Privacy-pass mailing list