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

[Brad Chen <[e-mail]>]

Would it be appropriate to also consult with safety advocates?

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

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.

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.

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.

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
   - 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.

Brad

On Fri, Oct 14, 2022 at 2:24 AM Antoine FRESSANCOURT <antoine.fressancourt=
[e-mail]> 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 <[e-mail]> On Behalf Of Mallory Knodel
> Sent: lundi 22 août 2022 16:05
> To: [e-mail]
> 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, [e-mail] 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 [e-mail] 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/pearg
>
> --
> Pearg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/pearg
>