|
On Oct 7, 2019, at 7:01 PM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
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?
Is there a specific compliance issue you have in mind?
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.
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.
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.
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
Regards,
Roman
|
