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

Tommy Pauly <> Thu, 21 March 2024 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7D06C180B50 for <>; Thu, 21 Mar 2024 13:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Status: No, score=-7.103 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_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2eJBJzHWZRtK for <>; Thu, 21 Mar 2024 13:51:09 -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 E2309C180B66 for <>; Thu, 21 Mar 2024 13:51:08 -0700 (PDT)
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <> for; Thu, 21 Mar 2024 20:51:07 +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-21_12,2024-03-21_02,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=SsblgHxJ4dFDptTR/D14/vLw/bNRvtvVuRE3oEAoQ0E=; b=FcDpWDhu7SXlzWLvQ+CZsax5EjWfd02T08QFeWQ7ZTdnXZ6d2Yxa6rT3UcXuqBjnYL4X ZXVlEtBAF+IuFGPB1n6c5waEDdSbADfxuvRX4L+vOZ8vmfAapxzfeBbRmPL2q+vW7iqa YnV/a/5/+M7p0JflZRKWUZUopcfS6cJ63T9oGK5CD6XCDiM3DLGTqZi6OoGIHPOe/xWz DY2z5LxE6Aov6E4TSFn9TPAUEoseDP2XGJT8IWGvBjUEXgtFOElZo2vNweTmktasBmRW dI2rUCs+WBBWQ7PKJKh+2AFGgS0yRyZqkCi9yENqQHjhgLg0qLKVckB9Xsx33G0fMjcb 7A==
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <>; Fri, 22 Mar 2024 04:51:02 +0800 (+08)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) id <>; Fri, 22 Mar 2024 04:51:01 +0800 (+08)
X-Va-T-CD: 5a79c165eae7bca3e214413a625caeec
X-Va-E-CD: c9ffe58cfb2e7540cac7826a0bde3a2e
X-Va-R-CD: aa96901a2922dab45381f6eea9cea460
X-Va-ID: 4e563540-dca4-4c5e-b1c8-c5473f8ec208
X-Va-CD: 0
X-V-T-CD: 5a79c165eae7bca3e214413a625caeec
X-V-E-CD: c9ffe58cfb2e7540cac7826a0bde3a2e
X-V-R-CD: aa96901a2922dab45381f6eea9cea460
X-V-ID: c11e241f-771c-4915-a261-918420ff151c
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-21_12,2024-03-21_02,2023-05-22_02
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPSA id <>; Fri, 22 Mar 2024 04:51:01 +0800 (+08)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_7D15F33C-5C9D-4B1A-82A8-7AEBEE523E5B"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Fri, 22 Mar 2024 06:50:37 +1000
In-reply-to: <>
Cc: Steven Valdez <>, Tommy Pauly <>,
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: Thu, 21 Mar 2024 20:51:10 -0000

> On Mar 22, 2024, at 5:34 AM, Watson Ladd <> wrote:
> On Wed, Mar 20, 2024, 9:31 PM Steven Valdez < <>> wrote:
>> I'm not sure that the unified vs split model makes a meaningful difference for this particular problem? In both cases, it's a question of whether the client trusts the attester on what it is using to make its attestation. Whether the issuer is the same server or split doesn't change what the issuer can see without collusion with the attester. The bigger difference is whether you do have a set of trusted attesters versus a wider set of less trustworthy attesters and then how you measure the impact of those differences.
> So the beautiful subtly of this is it doesn't matter what the attester does if the having of the attestation from that attester conveys more info that just the info the attester used.  It's not an anonymity set problem: lots of sensitive groups have many people in them.

If the client knows what its attestation is based on and can get some confidence in what it has in common with the rest of its anonymity set (which is a big assumption, I know), then I think the anonymity set does help. I.e., the case where the client gets a token because of having a particular device type, and the client doesn’t share other information (if it is sufficiently controlling the information flowing to the attester), and the identity of issuer of the token behind the attester is generic and used across many origins or else is unrelated to a specific user action, then the client isn’t going to be lumped into a set of users based on what they were doing on the origin, but instead based on what they expose to the attester explicitly (like the device type).

Totally agreed that if any of these controls aren’t met, then the set can be used to carry recognize more information.


>> On Thu, Mar 21, 2024 at 9:37 AM Tommy Pauly < <>> wrote:
>>> 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.
>>> Tommy
>>>> 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
>>>> <>
>>> -- 
>>> Privacy-pass mailing list
>>> <>
>> --
>>  Steven Valdez |	 Chrome Privacy Sandbox | <> |	 Cambridge, MA
> -- 
> Privacy-pass mailing list