Subject: RE: Next steps on Web Analytics Project

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Oct 2019 19:51:25 +0000

Hello!

> -----Original Message-----
> From: S Moonesamy [mailto:[email-masked]]
> Sent: Friday, September 27, 2019 5:39 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: Next steps on Web Analytics Project
> 
> Hi Roman,
> At 04:59 AM 26-09-2019, Roman Danyliw wrote:
> >This note provides an update on the web analytics for www.ietf.org
> >project.  In response to the initial proposal [1], the community
> >provided a variety of helpful feedback [2].  The IESG and IETF Tools
> >Team reviewed this community feedback and revised the proposal.  The
> >more significant revisions included an explanation of the current
> >analytics systems and associated practices; clarifying the scope and
> >enumerating the explicit use cases; identifying the link between the
> >collected data and the uses cases; and more clearly stating the privacy
> >and security issues and their associated mitigations.
> 
> Thank you for the sharing the next steps.  I could not find any mitigation for
> the issue mentioned on Page 5 (geolocation of IP addresses).  

Section 4.1 proposes an approach to opt-out of the analytics -- "The planned configuration will only use client-side JavaScript to collect all metrics ... A visitor can prevent all web analytics functionality by disabling JavaScript for www.ietf.org in their browser. As noted in Section 1.2, a design goal of www.ietf.org is for the website to function without JavaScript enabled."

In contrast the current approach uses network-layer information which would require a Proxy/VPN to obfuscate (but not eliminate the logging of the) client origin.

> I unfortunately
> has to raise a concern about this IESG-endorsed tracking plan as I am not
> comfortable about having someone else within the IETF tracking what I read
> on the IETF web site.

I'd point out that the proposed collection is similar to the existing practices in production now, see Table 1.  As described above, there is a robust mitigation possible to ensure this tracking doesn't occur should there be concern. 

Regards,
Roman

> Regards,
> S. Moonesamy

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Oct 2019 20:37:06 +0000

Hi!

> Sent: Friday, September 27, 2019 7:29 PM
> To: Stephen Farrell <[email-masked]>; [email-masked]
> Cc: Roman Danyliw <[email-masked]>
> Hi Stephen,
> At 03:11 PM 27-09-2019, Stephen Farrell wrote:
> >Yes, tracking what and when becomes possible.
> >
> >I'm also unhappy with that. Is there no way to ensure that addresses
> >and geolocated regions are sufficiently aggregated so as to not
> >identify individuals?
> >
> >/16's and countries are not sufficient for all IETFers.
> >
> >I'm sure someone who reads this list would have a fair chance at
> >(re-)identifying various individuals based on time, /16 or /48, and
> >URL.
> 
> It is technically possible to identify a person or a small set of persons even if
> the IPv4 addresses are aggregated by /14.  I suggest stepping back a little.
> The technical solution is being used to drive the policy statement.  Would it
> be better to do the reverse to figure out what is feasible [1]?  That would
> entail flushing out the policy statement to get a sense of what information
> IESG members [2][3] would find useful.

I'm not entirely following how the technical solution is driving the policy statement (i.e., motivation for the project).  Section 1.1 identifies what information is useful -- the use cases and questions that would be helpful to answering for improving the web-site.  Section 2.2 describes a candidate solution based on needs dictated by the use cases.  Section 2.3 provides a mapping between the individual data elements that will be collected by the solution and these motivating use cases.  Section 3 and 4 acknowledges that there are security and privacy issues in implementing this policy and provides a series of mitigations.  

You're right, ultimately, the technology solution (Matamo) does drive some of the mitigations as it provides only certain types of anonymization and aggregation primitives.

Regards,
Roman

> The data processor could then use a
> "custom dimension" to decrease the probability of identification of that
> small set of persons.
>
> Regards,
> S. Moonesamy
> 
> 1. Please see the P.S. in your email
> 2. One of the issues is that web analytics usually use the IP addresses to
> aggregate by country.  Does an IESG member need to know whether Country
> X has expressed an interest in, for example, the IESG history of appeals?
> 3. Does an IETF LLC Director need to know who is reading the monthly
> financial statements?

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Oct 2019 15:16:29 -0700

Hi Roman,
At 12:51 PM 07-10-2019, Roman Danyliw wrote:
>Section 4.1 proposes an approach to opt-out of the analytics -- "The 
>planned configuration will only use client-side JavaScript to 
>collect all metrics ... A visitor can prevent all web analytics 
>functionality by disabling JavaScript for www.ietf.org in their 
>browser. As noted in Section 1.2, a design goal of www.ietf.org is 
>for the website to function without JavaScript enabled."

Ok.

>In contrast the current approach uses network-layer information 
>which would require a Proxy/VPN to obfuscate (but not eliminate the 
>logging of the) client origin.

Ok.

>I'd point out that the proposed collection is similar to the 
>existing practices in production now, see Table 1.  As described 
>above, there is a robust mitigation possible to ensure this tracking 
>doesn't occur should there be concern.

The proposed collection is likely similar to current practices (Table 
1).  I gather that those practices were followed well before the 2017 
privacy statement.  I read Section 4.3 of the document 
again.  Wouldn't there be a possible compliance issue as there has 
been some changes over the last two years?

At 01:37 PM 07-10-2019, Roman Danyliw wrote:
>I'm not entirely following how the technical solution is driving the 
>policy statement (i.e., motivation for the project).  Section 1.1 
>identifies what information is useful -- the use cases and questions 
>that would be helpful to answering for improving the 
>web-site.  Section 2.2 describes a candidate solution based on needs 
>dictated by the use cases.  Section 2.3 provides a mapping between 
>the individual data elements that will be collected by the solution 
>and these motivating use cases.  Section 3 and 4 acknowledges that 
>there are security and privacy issues in implementing this policy 
>and provides a series of mitigations.

If I take UC-1, for example, the objective would be to understanding 
who are the visitors and how did the visitors uses the site while 
dropping information which allows the identification of any 
particular visitor.  When the implementation (Section 4.1) does not 
comply with that, someone may have to figure out whether the 
assumptions used for the software design are correct for the business case.

>You're right, ultimately, the technology solution (Matamo) does 
>drive some of the mitigations as it provides only certain types of 
>anonymization and aggregation primitives.

Ok.

Regards,
S. Moonesamy

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Oct 2019 23:52:25 +0000

On Oct 7, 2019, at 7:01 PM, S Moonesamy <[email-masked]> wrote:

Hi Roman,

Ok.

Ok.

The proposed collection is likely similar to current practices (Table 1).  I gather that those practices were followed well before the 2017 privacy statement.  I read Section 4.3 of the document again.  Wouldn't there be a possible compliance issue as there has been some changes over the last two years?

Is there a specific compliance issue you have in mind?

I don’t follow the reference to the 2017 version of the privacy statement. The IETF privacy statement isn’t a static and is updated as new practices or compliance requirements arise. For example, it was updated in 2018 for GDPR, https://mailarchive.ietf.org/arch/msg/ietf-announce/8xclBpLxdn5y8oAZOB6l4QWLpCE

The currently published statement covers all existing practices in their current form.

You’re exactly right that a new practice, as being proposed here, might require review or update to the privacy statement. The text in Section 4.3 explicitly captures that after sufficient implementation details are known, its policy implications will be reviewed prior to deployment.

If I take UC-1, for example, the objective would be to understanding who are the visitors and how did the visitors uses the site while dropping information which allows the identification of any particular visitor.  When the implementation (Section 4.1) does not comply with that, someone may have to figure out whether the assumptions used for the software design are correct for the business case.

Thanks for clarifying. At this point, the proposed data collection is believed to answer the questions posed in each use (business) use.  Implementation experience is required. Per Section 5, the IESG and Tools Team plan to review the project in a year to ensure that the anticipated value is being realized.

Ok.

Regards,
S. Moonesamy

Regards,
Roman

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Oct 2019 23:20:18 -0700

Hi Roman,
At 04:52 PM 07-10-2019, Roman Danyliw wrote:
>I don't follow the reference to the 2017 version of the privacy 
>statement. The IETF privacy statement isn't a static and is updated 
>as new practices or compliance requirements arise. For example, it 
>was updated in 2018 for GDPR, 
><https://mailarchive.ietf.org/arch/msg/ietf-announce/8xclBpLxdn5y8oAZOB6l4QWLpCE>https://mailarchive.ietf.org/arch/msg/ietf-announce/8xclBpLxdn5y8oAZOB6l4QWLpCE
>

Thank you for providing a URL to the announcement.  I did not catch 
the change which was made in 2018.

The processing may end up identifying a person and track the behavior 
of that person.  That might probably happen in a limited number of 
cases.  However, it defeats the purpose mentioned in the statement, 
which is to protect the privacy of the parties' participants.  It 
could be argued that the implementation does not comply with the 
statement.  It could also  be argued that it cannot be described as 
"consent" if the participant is not able to disagree with the 
processing of his/her information.

Regards,
S. Moonesamy