Re: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning

Vittorio Bertola <vittorio.bertola@open-xchange.com> Thu, 17 November 2022 16:09 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14BDC1524CC for <architecture-discuss@ietfa.amsl.com>; Thu, 17 Nov 2022 08:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 YvPiuLdhFBba for <architecture-discuss@ietfa.amsl.com>; Thu, 17 Nov 2022 08:09:04 -0800 (PST)
Received: from mx3.open-xchange.com (mx3.open-xchange.com [87.191.57.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA951C14CF10 for <architecture-discuss@ietf.org>; Thu, 17 Nov 2022 08:09:03 -0800 (PST)
Received: from imap.open-xchange.com (imap.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id B48D86A0F4 for <architecture-discuss@ietf.org>; Thu, 17 Nov 2022 17:08:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1668701339; bh=vukJfuTxWXp4+4ZEkB7Sn2/uyXrLO8WddPfnR3mXHao=; h=Date:From:To:In-Reply-To:References:Subject:From; b=KKkaqDuj7zAPDrHEuHOHJCctZBnyel5Via4RlROVQNYf0qU47yxDYso5dUBwUJUdB xsEUu4qMunUGX8QIMSOtKRpByZ/g2DrwUhIobZurV4TpXlLNXck+Sw8xMThcMpVIii WZohQYqXq666qMQJGYsH8lSTInrPzYPRof6q0RAsRTTrW6s+zdNZ0BTNGwjz8c6T8S 9PDPBQ4tlDJCzalR5ARupPipne/haln50I0Vjsljg/z5B5r3nK7yJxHhI27gytBG07 txxRi0DayP44H7jibNMVi4W6ZVUy+V85pPjphOCnvhMpDLBStmaaM5jESp5R9LXKml MSa2d4UdRX/0Q==
Received: from appsuite-gw1.open-xchange.com ([10.20.28.81]) by imap.open-xchange.com with ESMTPSA id P6yrKptcdmM5PB0A3c6Kzw (envelope-from <vittorio.bertola@open-xchange.com>) for <architecture-discuss@ietf.org>; Thu, 17 Nov 2022 17:08:59 +0100
Date: Thu, 17 Nov 2022 17:08:59 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: architecture-discuss@ietf.org
Message-ID: <797875861.71155.1668701339665@appsuite-gw1.open-xchange.com>
In-Reply-To: <166862348898.27211.16338265887689375983@ietfa.amsl.com>
References: <166862348898.27211.16338265887689375983@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev30
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/m3Kh4d0_7Dl3n7h-E3G93wpnC18>
Subject: Re: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2022 16:09:07 -0000

> Il 16/11/2022 19:31 CET IAB Executive Administrative Manager <execd@iab.org> ha scritto:
> 
> Feedback about this draft can be sent in response to this mail on architecture-discuss@ietf.org, or to the IAB directly at iab@iab.org.

I will repeat and detail what I said when this document was presented in London.

The statement that this model is "a means to improve the privacy by separating user identity from user data" only stands under some conditions.

One is the lack of collusion between intermediaries that should sit in independent contexts. The draft acknowledges this in section 5.1, yet the mitigations suggested seem actually counterproductive.

Contractual agreements make entities more interdependent, not more independent; if both companies live off user profiling and big data collection, they will always have a vested interest in sharing data and the fact that they have a (confidential and unverifiable) contract swearing that they will never do so is only as good as the trust you are willing to put in these companies. Moreover, it is unclear why any party would support a significant technical cost (how much does it cost to route all that traffic?) for no clear reason and, in the absence of user data monetization, no clear revenue stream, except maybe direct payment for this service, which is generally not a popular business model for consumer Internet services.

The other suggestion is to just add more and more intermediaries, and this is really baffling. First, privacy is about reducing the number of entities that have a chance to access your data, not increasing it. Second, I am lost at what is now the vision of the IETF's technical leadership on intermediaries; I've seen continuous bashing of the very idea of in-network intermediation for years, including drafts that propose principles to remove or at least reduce existing intermediaries as far as possible (e.g. https://datatracker.ietf.org/doc/draft-thomson-tmi/ ), and here is one that actually proposes to take traffic that was happily scattered throughout the Internet and make it all go through new intermediaries.

In the end, I think that collusion will always be a very significant risk, as the economic incentives will generally be aligned in favour of it, and this looks like a fundamental flaw of the idea.

But then, there is a second condition that could address all of this and make the model viable: that we would realistically have a very big number of intermediate proxy providers spread across the globe, and that users would be free to pick and to change the ones they want to use, or even distribute their traffic across many at the same time.

In this case, we could assume that users would make sure that the services they pick are actually independent and unlikely to collude, and could look for the ones that do not have user data monetization as a business model. This would also meet the requirements of most privacy legislations, which put the user in general control of who gets to see their personal data.

However, I really see no discussion of this problem anywhere, let alone the recognition that user control is the best antidote against misuses of this scheme. Also, the early implementations are often the exact opposite of this, as, while being opt-in, they do not seem to give any control to users, not even hidden under several layers of configuration menus.

So, if designed this way, this architecture seems like another big step forward for centralization, this time by routing the entire traffic of each user through a limited set of giant proxy platforms run by the only few companies that can afford to deploy them.

Actually, the document often seems to consider this expected consolidation as a given, for example when, in section 6 point 2, dismisses concerns about performance losses by assuming a likely "highly optimized nature of proxy-to-proxy paths", i.e. the proxies being in limited numbers and sitting at the core of the fastest global networks.

If we want to prevent this, then how to facilitate the easy deployment of a big number of independent proxies, and how to allow users to discover and choose among them, should be a main concern of the document; and also, how could the system be designed so that the economic incentives are against centralization and against collusion, and not in favour.

Hope this is useful; I'd recommend that the IAB clarifies the vision and the objectives before adopting the document.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy