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

Watson Ladd <watsonbladd@gmail.com> Thu, 21 March 2024 19:34 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E444FC14F6F0 for <privacy-pass@ietfa.amsl.com>; Thu, 21 Mar 2024 12:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94qHYculG6EM for <privacy-pass@ietfa.amsl.com>; Thu, 21 Mar 2024 12:34:29 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 1B5CAC14F6E9 for <privacy-pass@ietf.org>; Thu, 21 Mar 2024 12:34:29 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4146feb33e1so10486285e9.2 for <privacy-pass@ietf.org>; Thu, 21 Mar 2024 12:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711049667; x=1711654467; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6eSjE99EyjzrQSXVRJ0JeyXWUBcBCbUp47LStZFmxcg=; b=blzI0yxtM1+3RyGyIHhOQWunHvC8K+ZNW6ywCVl3Bhx4B+iZu0DbOdQoFhTrETp51S G0wQ8bIKe3sGklsMYlCM1Ptqrqkr+2Q55Cz/8SnpNyyBRRHcW6feIeWeuvA8zzmpqXUb 1Fqi0bWm+dO1dSjpgsj8T/Cv8hQTnwWJZ72vhOENIgbloV0w0/J4lK2u757mLkWkHvV9 i6MnjZfMfNRfVv+0JY9Ml1VV0gXLXkz0B4mE1T9q0oE+Pk8IYNmPiPjfbi19wON1fB/M AJlV9zF7EPWmM2qiscvTiZrjmXJ4boNTz2bX35HYbWMzxk905B9YXkUHaDO9X6tk9Rpe 9QXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711049667; x=1711654467; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6eSjE99EyjzrQSXVRJ0JeyXWUBcBCbUp47LStZFmxcg=; b=NshHfzRqm/lqGOe6g1yCwrMsjVvBLp/YS0QnTvk/wKZ+YPC/MMpj626zVBw5RldmGP 905XYeVVtXyogJ6daGjsEzyG+gd5jJUwgHR3Q5hjexpU0Jbc5lhUQNCMmy8hfo6KDggu tTZNiezjLRcd14XP+mynbsdLtqo20RUdE1/uXiprarbfpbldNRKDwko9KZZKFYGh+lj2 OkiBUtVp8ug/gDAb5hY88TgauKZanQ71QcG8etdOatfLWBw8MEZslygOC5M0WhjQp3co Sq6MZThcbpTmfj6zUZ604v7iK7zBGBAVeKEMXB+oHaMupxMatkIfdhJy+hhvL5/CwMJ6 xJCA==
X-Forwarded-Encrypted: i=1; AJvYcCXpeUbwFqU43Jazl+9E4HTEYRG8ifKsA4AOpdo6qpRgftgtGF+JFed0Fq2DZ19CnKSsYYTl7jyM7ofjlL5kOeNayMztTGo=
X-Gm-Message-State: AOJu0Yx66XuntN4y3WSk8aDKxhopljvw//nkMRBk4T2eFuN05gzwXHQ2 iLmHiivuJu5mLnxkKsL883vsreIADcAMIaP/ud4w1GbG1yzd4ncUt6P001dGu/ZH1+a9L7Zf/+u ZOAwnLZX47YPkT+3L5bHfIFSUqoI=
X-Google-Smtp-Source: AGHT+IHi+4uqsmNkmHoQIap0kWuXETigx0KfpBel/NxIYv6nlVP868PQe8h6sOSCVp3C0vvqTlT55m4vb6KvMCcUIaA=
X-Received: by 2002:a5d:6da7:0:b0:33e:c0eb:f227 with SMTP id u7-20020a5d6da7000000b0033ec0ebf227mr103653wrs.45.1711049666946; Thu, 21 Mar 2024 12:34:26 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0ck4whpCv+nnHDVOaa-kEW4a7OMx1PgCpFpfdQb=gX0_sw@mail.gmail.com> <85657569-B01B-4F2A-94F5-B171B36BCCF6@apple.com> <CANduzxDhy-nCYowvNaJNqcoxAhxA6yCbWStoZnNWFB4-keAe+g@mail.gmail.com>
In-Reply-To: <CANduzxDhy-nCYowvNaJNqcoxAhxA6yCbWStoZnNWFB4-keAe+g@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 21 Mar 2024 15:34:16 -0400
Message-ID: <CACsn0cnp=-GzKysjawp-ugCUEv8tRAU3k5rHGpSCRVi6UO8W_A@mail.gmail.com>
To: Steven Valdez <svaldez@google.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, privacy-pass@ietf.org
Content-Type: multipart/alternative; boundary="000000000000977817061430cbca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/mlWPqZdqVaAQ__P4IHWEEzZW6K0>
Subject: Re: [Privacy-pass] The harms of popular bits
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 19:34:33 -0000

On Wed, Mar 20, 2024, 9:31 PM Steven Valdez <svaldez@google.com> 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.


> On Thu, Mar 21, 2024 at 9:37 AM Tommy Pauly <tpauly=
> 40apple.com@dmarc.ietf.org> 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 <watsonbladd@gmail.com> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>>
>> --
>> Privacy-pass mailing list
>> Privacy-pass@ietf.org
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>
>
> --
>
>  Steven Valdez |  Chrome Privacy Sandbox |  svaldez@google.com |  Cambridge,
> MA
>