<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2024, at 9:40 PM, Michael Puckett <<a href="mailto:michael.puckett@icann.org" class="">michael.puckett@icann.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;" class=""><span style="font-size: 11pt;" class="">I’m starting a thread for topics from public comments that need to be discussed by the DG.</span></div></div></div></blockquote><blockquote type="cite" class="">...<br class=""></blockquote><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><ol start="1" type="1" style="margin-bottom: 0in; margin-top: 0in;" class=""><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">Legal/privacy concerns for VI/VIN (<a href="https://itp.cdn.icann.org/public-comment/proceeding/Draft%20NCAP%20Study%202%20Report%20and%20Responses%20to%20Questions%20Regarding%20Name%20Collisions-19-01-2024/submissions/ICANN%20org/Visible%20Interruption%20(VI)%20and%20Visible%20Interruption%20and%20Notification%20(VIN)%20-%20Privacy%20and%20data%20protection%20review-26-02-2024.pdf" style="color: rgb(70, 120, 134); text-decoration: underline;" class="">Brief</a><span class="Apple-converted-space"> </span>from ICANN Legal):</li></ol></div></div></blockquote><div><br class=""></div><div>I have re-read the legal brief from ICANN. Here are a few thoughts (note: I am not a lawyer).</div><div><br class=""></div><div></div></div></div></div><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><div>"While VI/VIN can be useful tools for preventing conflicts, they also pose privacy and data protection</div>related risks that should be considered....</div></div></div></blockquote><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>"ICANN’s or the third parties’ interests might be outweighed considering the significant risks and negative impacts on privacy and data protection"</div></div></div></blockquote><div class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><br class=""></div></div></div></div><div class=""><br class=""></div>I mentioned on the call last week -- and I reiterate -- that the document does very little to weigh utility or benefit against risks and harm. Much of that is documented in the Study 2 documents, but let me do a quick summary.<div class=""><br class=""></div><div class="">I will try to be very objective about this, but I would like to try to reiterate what I feel are the benefits of this as well, as the risks of not doing this.</div><div class=""><br class=""></div><div class="">The risk of DNS queries expecting a negative response from public DNS servers when they are inadvertently leaked is that they are answered by a third party that does not respect their privacy and might even have malicious intent. That third party could be any entity in control of a DNS server to which those queries are directed, which might be a TLD operator or any entity to which namespace has been delegated -- directly or indirectly.</div><div class=""><br class=""></div><div class="">Thus, the utility and benefits of any mechanisms are about reducing this risk of third-party surveillance, disruption, or theft. This is what the "privacy and data protection related risks" should be weighed against.</div><div class=""><br class=""></div><div class="">How do we reduce risk of affected parties to third parties? Well, we started with the notification mechanism known as controlled interruption (CI) -- which is mentioned in the document. Here is my brief summary of benefits and shortcomings:</div><div class=""><div class=""><br class=""></div><div class="">Since 2014 Controlled Interruption (CI) has already provided a mechanism for indirect notification of , via communication interruption and application disruption. As shown in the root cause analysis, there is evidence that the CI IP address has been found -- in many cases. However, the telemetry associated with CI is extremely limited. We only know where the CI IP address been found based on: 1) Web searches (i.e., online forums; see Section 5 of the root cause analysis report); 2) self-reporting through ICANN's form (see Section 4 of the root cause analysis report); and 3) results from a survey distributed to system administrators (see Section 9 of the root cause analysis report). However, #1 and #2 were limited to those that actually discovered the controlled interruption IP address, #2 was limited to those that found the ICANN report submission page and reported, despite the very high bar ("reasonable belief that the name collision presents a clear and present danger to human life"), and #3 was a relatively small sample. In short, we know that we have a limited view, but we don't really know what we don't know. We might infer that it's "working" based on the downward trend of collision-related queries at the root, but (as has been pointed out, extensively), that is complicated because the collection of queries at the root servers is a mixed bag -- offering some insights, while there are growing concerns about their representativeness.</div><div class=""><br class=""></div><div class="">Summary: Based on limited data, we might suspect that CI has been "successful" and that any harm that was occurred was that associated with CI itself, as opposed to third-party surveillance. However, there really has been limited data to confirm this -- to know what's really going on and what potential harm might still remain -- both for users of TLDs since 2014 and users of future TLDs.</div><div class=""><br class=""></div><div class="">No interruption (NI) and Visible Interruption (VI) are attempts to get more data, so we can more effectively assess who is at risk and even initiate reach-out efforts. The former addresses caching and other issues with analysis of only root server query data, which is what we had with CI. But still only the IP address of the DNS resolver is revealed. The latter makes available client IP addresses and ports, to help identify organizations and even users potentially at risk, with greater fidelity. With both, additional data is leaked to the public Internet. But that is in the name of minimizing potential risk of harm to users and organizations leaking queries associated with colliding namespaces.</div><div class=""><br class=""></div><div class="">Visible Interruption and Notification (VIN) provides the same data as VI but also involves: 1) the exchange of application-layer data that might include HTTP Request data, such as the requested path, query string or request body data (which might include username/password data, session information, or other sensitive data), browser version, and OS version; and 2) the return of a "message" that might (or might not) been seen by an actual human, to more directly notify them that they are experiencing name collisions.</div><div class=""><br class=""></div><div class="">The question asked by ICANN legal is whether the benefits of not doing VI (and VIN) outweigh the risks. What I have written here is about the benefits of doing it -- something that was almost completely left out of the document.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>"Furthermore, the lack of transparency in data processing,</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is an unfair and possibly untrue statement. I think that the proposals in the study 2 report have provided as much transparency as they could. Even if the exact methodologies have not been spelled out, the objectives of such methodologies have been made pretty clear, from my perspective.</div><br class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div> the absence of data minimization practices,</div></div></div></blockquote><div class=""><br class=""></div><div class="">To be fair, the discussion group laid all the methods out in order of data minimization: NI, CI, VI, VIN. Between VI and VIN, VI *is* the data minimization.</div><br class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div> and the risk of exposing sensitive data of data subjects without legal basis make VI/VIN a concern regarding compliance with data protection laws."</div></div></div></blockquote><div class=""><br class=""></div><div class="">My second comment on the call last week was the point that while VI and VIN both involve the "risk of exposing sensitive data", the data disclosed is very different, in my opinion. That is, what is disclosed at the application layer with VIN is potentially much more sensitive than that disclosed at the network and transport layers with VI. Referring back to my previous comment about data minimization, these are two very different things and need to be considered differently, not simply lumped together.</div><br class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>"However, due to the unpredictable nature of the data collected and the potentially high residual risks</div><div>associated with data collection and further processing, implementing these privacy safeguards appears<br class="">to be challenging, if not impossible...."</div></div></div></blockquote><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><br class=""></div><div>"As it will be difficult or even impossible to implement suitable mitigation measures this could have legal and reputational</div>consequences for the entities conducting VI/VIN"</div></div></blockquote><div class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div></div></div><div class="">ICANN surely cannot be the first to implement data privacy techniques. Calling this "challenging, if not impossible" sounds overly harsh and negative.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">"Overall, the benefits of conducting VI/VIN may be overridden by the interests or fundamental rights and</div>freedoms of the data subjects if the processing of personal data for this purpose involves significant risks<br class="">or negative impacts on their privacy and data protection"</div></blockquote><div class=""><br class=""></div><div class="">This is true, but again, the benefits need to be considered.</div><br class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">"Implementing the other safeguards to limit the amount of personal data processed would require knowing in advance what data would be collected when conducting VI/VIN, which is impossible."</div></blockquote><div class=""><br class=""></div>Section 3.5 is pretty clear about what data would be disclosed and stored. I don't understand this statement at all.</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">"When a TLD is undergoing VI/VIN, the DNS queries from any system that attempts to resolve a domain<br class="">name under that TLD are ultimately received by the TLD’s name servers.1 This means that information<br class="">about the domains being queried is processed and this information may include personal data. If the<br class="">entity conducting the assessment is not transparent about their data collection practices, this could be<br class="">seen as invasive and raise concerns about data privacy."</div><span id="x-apple-selection:end"></span></blockquote><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This is the same as pre-CI, CI, and NI. So I'm not sure what this paragraph adds.</div></div></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This is my 2 cents.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Casey</div></body></html>