Re: [Pearg] New Version Notification for draft-irtf-pearg-safe-internet-measurement-06.txt

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Mon, 17 October 2022 11:26 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789FC1524B5 for <pearg@ietfa.amsl.com>; Mon, 17 Oct 2022 04:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=ham autolearn_force=no
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 usyiRM9p8v4n for <pearg@ietfa.amsl.com>; Mon, 17 Oct 2022 04:25:56 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2B4C1522A9 for <pearg@irtf.org>; Mon, 17 Oct 2022 04:25:55 -0700 (PDT)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MrZQ31CbKz688Kc; Mon, 17 Oct 2022 19:24:11 +0800 (CST)
Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.31; Mon, 17 Oct 2022 13:25:52 +0200
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 17 Oct 2022 12:25:52 +0100
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2375.031; Mon, 17 Oct 2022 12:25:52 +0100
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: "bradchen@google.com" <bradchen@google.com>
CC: Mallory Knodel <mknodel@cdt.org>, "pearg@irtf.org" <pearg@irtf.org>
Thread-Topic: [Pearg] New Version Notification for draft-irtf-pearg-safe-internet-measurement-06.txt
Thread-Index: AQHYtjArsH3PxHwA/kShvm4NWJCF5a4N8HYwgABPGACABIfXcA==
Date: Mon, 17 Oct 2022 11:25:51 +0000
Message-ID: <b2728da582c547909a9124dd2f60c46c@huawei.com>
References: <166094489131.14532.16995503633780264379@ietfa.amsl.com> <626a3eaa-497b-644d-16d7-7cc8c07a4dde@cdt.org> <0983ae69e957424f810750211379ba89@huawei.com> <CAFzihuXF6dxuqPEEYxiVe3MEBJD2VsYyn+j+RS3EXk9z8N8ovw@mail.gmail.com>
In-Reply-To: <CAFzihuXF6dxuqPEEYxiVe3MEBJD2VsYyn+j+RS3EXk9z8N8ovw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.70.106]
Content-Type: multipart/alternative; boundary="_000_b2728da582c547909a9124dd2f60c46chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/ovFKv3qP60h45vWKoMFoZYKQ9U4>
Subject: Re: [Pearg] New Version Notification for draft-irtf-pearg-safe-internet-measurement-06.txt
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2022 11:26:00 -0000

Hello,

Thanks for adding an interesting viewpoint to the discussion, Please see some comments in line (prefixed by [AFT])

Best,

Antoine

----

> Would it be appropriate to also consult with safety advocates?

[AFT] Sure, it would be interesting in general for this group. Yet, I wonder how guidelines to enforce privacy on measurement data raise specific issues regarding safety.

> Should this group assume all regulations are well founded? Or does our role include providing feedback on regulations and recognizing better designs?

[AFT] In France, we say "Dura lex, sed lex". The law is hard / complex, but it is the law, and we should respect it. Maybe it has been voted by persons who are not expert in the matter it addresses, but then our role might be to educate elected officials so they raise the difficulties / impracticalities in the parliament. But this is certainly beyond the scope of this draft and this group.

> Consent is a difficult concept in this space. Too often, users are presented with decisions they aren't prepared or competent to make. The ubiquitous "do you accept cookies" prompts we see are a relatively benign example. I find it hard to argue they are helping users, or accomplishing much beyond providing cover for service providers and their use of cookies. Still lacking is a useful system of public auditing and auditing standards for responsible cookie disclosure and use.

[AFT] As for elected representatives who vote on topic they might not master, the key here is education. The cookie banner example is interesting, because it shows that the industry has little interest in educating users to understand the decisions they have to make on accepting cookies or not, while several publishers are using dark patterns to incline users to take decisions that don't harm their interest. While I agree the current situation is not perfect, it had the effect to raise the question in some users heads. For instance, my mom asked me what are cookies, why she would keep information on her computer etc. after seeing such banners on all the websites she visits. So maybe it is hard to argue banners are helping users, but at least they rose awareness.

> Moreover, consent utterly fails for accounts that are dormant, which over time tend to succumb to control by abuse operations. At the point an account is deployed for scaled abuse, the notion of consent becomes absurd. In some cases safety efforts, including relevant measurement efforts, are considered out-of-scope for consent. In other cases abuse is simply unmanaged, and the public is less safe.

[AFT] I would argue that accounts that are dormant don't consent because by default consent is not granted. Besides, if accounts are dormant, they are not trafficking either, so in the context of the present draft they don't raise any issue in my view. Then if those dormant accounts get involved in attacks or abusive behaviors, then their consent is not required in case security, safety or normal operation of the platform are endangered as per article 6 of the GDPR (in my interpretation).

> If we make the Internet even more private without planning for safety, we degrade the position both of governments and private operators to defend against state-sponsored abuse and scaled criminal syndicates. What accommodation should measurement standards make for public safety? Perhaps none. We could pursue privacy unilaterally. This assures the privacy of criminals, and leaves ordinary users in a precarious state, obviously not the outcome we intend.

[AFT] Safety and protection against criminals is often pushed in discussions surrounding privacy in the Internet. Of course, it has been taken into account in GDPR: protecting against criminals, enforcing public safety, preventing harm made to people are all cases in which consent by a user to collect its personal data is not required. It is explicitly stated in article 6 of the GDPR. So we can collectively be relieved that the European legislator has not sacrificed public safety to protect privacy. In general, I don't think that pursuing privacy should prevent us from placing safeguards to mitigate abuses or crimes, but I think that allowing anybody to track Internet users based on metadata that are not protected on the ground that public authorities might need to use them to track criminals and ensure public safety is wrong. I think that communication protocols on the Internet should be private by default for any parties, yet should include policy enforcement mechanisms that would only be used by authorized public authorities. In research projects on privacy-preserving network protocols, several projects have mixed privacy protection with path verification mechanisms, showing that you can have a level of traffic control while enforcing privacy.

> Regarding the draft:

  *   The discussion of threat model is pretty clear on data privacy, but ambiguous regarding public safety problems such as fraud, disinformation, harassment, malware, scaled influence operations etc. which have little to do with data privacy.
  *   The discussion of consent might consider situations where consent should not apply
[AFT] We might refer to article 6 of the GDPR has a starting point for a discussion on this matter.

  *   The draft might consider measurement scenarios outside of the purely academic / research context. If public safety operations are out of scope, the draft might indicate that explicitly.
[AFT] I agree the draft should state it explicitly.
Brad

On Fri, Oct 14, 2022 at 2:24 AM Antoine FRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hello,

I have finally found time to carefully read the document. Its purpose is interesting but I wonder if it applicable worldwide in all legal contexts. As an European, I am obviously biased towards having to deal with GDPR when it comes to dealing with the draft's matter.
So here are a few remarks.

First, in the chapter about consent, I found some things odd when compared with GDPR [1]. In Article 6, the lawfulness of personal data processing is described. Explicit consent is the first condition that allows a data processor to process personal data. A few other conditions are given; but I fear that some of those reasons are not covered by proxy consent or implicit consent for use cases or purposes that are not vital to the data subject or necessary to operate a service to the data subject. Scientific research is mentioned in GDPR as a possible purpose for processing personal data beyond explicit consent, but the regulation specifies that it should not be possible to pseudonymize the data subject. For example, if we want the case study in paragraph 2.2 (TCP Options) or in paragraph 2.3 (maximum TLS version) to hold, if consent is not gathered, the data processor should prove that the collection of personal data associated with this measurement is necessary to operate the service provided to the customer (but measurements that don't gather personal data are fine). Note that the explicit consent is tied with a description of the processing purposes and a change in purposes requires that you ask for consent again. In the text, the practicality of the consent retrieval is mentioned, but I fear that even if the consent is difficult to gather, it needs to be retrieved if personal data is processed beyond exception cases listed.

In the threat model; I think the text should insist on de-anonymization risks associated with the correlation of data sets collected during different experiments. If an attacker has access to two different data sets on a similar population and that secondary data can be used to decrease the size of anonymity sets for each data set, then the risk for the data subject to be identified is higher, with associated threats as listed in the document.

In the 3rd chapter on the Safety considerations, I would add a specific paragraph on the need to anonymize data. Right now, the document insists on minimizing data, and anonymization techniques may fall in the techniques described in this paragraph. Still, focusing on operations to perform so that data subjects' privacy can be insured is a key point with regards to the GDPR. In particular, I think techniques that one could put in place to prevent identification by cross correlation from a variety of data sources should be presented. Besides, maybe we could work on a document to survey anonymization techniques and their merits in the context of data processed in the operation of networked systems to give practical examples of techniques that researchers or network administrator could use in their data collection.

I think that this document touches subjects that are beyond our background and experience (as engineers). Maybe we can try to involve privacy advocacy groups beyond the IETF / IRTF community to ask them about their remarks or inputs on the document ? I can try to find people in EU if you feel it could be a valuable input.

Best,

Antoine

--

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN


-----Original Message-----
From: Pearg <pearg-bounces@irtf.org<mailto:pearg-bounces@irtf.org>> On Behalf Of Mallory Knodel
Sent: lundi 22 août 2022 16:05
To: pearg@irtf.org<mailto:pearg@irtf.org>
Subject: Re: [Pearg] New Version Notification for draft-irtf-pearg-safe-internet-measurement-06.txt

Hi all,

I have the new version of this draft in the datatracker, which I briefly presented on at the PEARG session of the IETF 115 meeting. Mostly the changes were to the XML and the structure of the document.

As discussed, I also submitted the draft to the M-TEN IAB workshop on measurement and privacy. Hopefully we can get some volunteers to review and co-author.

-Mallory

On 8/19/22 5:34 PM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
> A new version of I-D,
> draft-irtf-pearg-safe-internet-measurement-06.txt
> has been successfully submitted by Mallory Knodel and posted to the
> IETF repository.
>
> Name:         draft-irtf-pearg-safe-internet-measurement
> Revision:     06
> Title:                Guidelines for Performing Safe Measurement on the Internet
> Document date:        2022-08-19
> Group:                pearg
> Pages:                11
> URL:            https://www.ietf.org/archive/id/draft-irtf-pearg-safe-internet-measurement-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-irtf-pearg-safe-internet-measurement/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-irtf-pearg-safe-internet-measurement
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-safe-internet-measurement-06
>
> Abstract:
>     Researchers from industry and academia often use Internet
>     measurements as part of their work.  While these measurements can
>     give insight into the functioning and usage of the Internet, they can
>     come at the cost of user privacy.  This document describes guidelines
>     for ensuring that such measurements can be carried out safely.
>
> Note
>
>     Comments are solicited and should be addressed to the research
>     group's mailing list at pearg@irtf.org<mailto:pearg@irtf.org> and/or the author(s).
>
>     The sources for this draft are at:
>
>     https://github.com/irl/draft-safe-internet-measurement
>
>
>
>
> The IETF Secretariat
>
>
--
Mallory Knodel
CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

--
Pearg mailing list
Pearg@irtf.org<mailto:Pearg@irtf.org>
https://www.irtf.org/mailman/listinfo/pearg

--
Pearg mailing list
Pearg@irtf.org<mailto:Pearg@irtf.org>
https://www.irtf.org/mailman/listinfo/pearg