[ALAC] [CPWG] URGENT: DRAFT ALAC Statement on the EPDP Phase 1 Final Report

[Alan Greenberg]

Thanks George.

Rec #6 requires that registrars must give registrants the choice of 
publishing contract details but there is no timeline when this will 
be done. So registrars could delay.

Alan

At 14/02/2019 08:54 PM, George Kirikos wrote:
>Hi Alan,
>
>I have strong concerns that the current recommendations are
>anti-choice, namely that they prevent registrants from even consenting
>to publication of their full contact detail (i.e. all the contact
>details that have historically been in the WHOIS).
>
>According to the Feb 11, 2019 draft version at:
>
>https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report
>
>recommendation #10 forcibly redacts the registrant Name, Street,
>Postal Code, Phone, Fax (which is completely missing in the table!).
>Email is also redacted, subject to recommendation #13. Footnote 16
>says it can be replaced by a form or anonymized email, but that
>suffers from the issues I pointed out at:
>
>https://mm.icann.org/pipermail/cpwg/2019-February/000853.html
>
>Now, Recommendation #13 also refers to "Recommendation X"
>(non-existent!) which would allow the Registered Name Holder to
>provider consent for publication of just its email address. However,
>that doesn't seem to allow the registrant to consent to publication of
>*ALL* of its contact details (i.e. name, phone number, fax, full
>mailing address, etc.).
>
>Many registrants *want* that fully published, and these
>recommendations take away that choice from the registrant.
>
>The same issue exists for the tech contact. Some folks want that
>separate contact's full info to be collected and published, but aren't
>going to be able to even consent to that (again, it just says "Yes"
>for "Redacted", without the footnote to consent to publication). That
>secondary contact point is going to be useful if the primary contact
>has downtime, becomes invalid, is on vacation, or is otherwise
>unavailable. With just 1 visible contact, it creates a single point of
>failure, if communications are missed.
>
>In essence, these recommendations are overapplying the GDPR (e.g. to
>non-persons, and to those outside the EU), *even* if the registrant
>wants to fully consent to full publication of their own data (Rec #17
>shows that overapplication). It takes a "father knows best" approach,
>to disregard the registrant's own wishes and doesn't give them the
>opportunity to consent, to exercise their own choices. By all means,
>if someone wants to not publish their data, respect that choice. But,
>those who *do* want to publish their data are totally disrespected by
>the current recommendations.
>
>Folks have many legitimate reasons for wanting to fully publish their
>own data, including not wanting their communications to be intercepted
>by the registrar, and also to be able to openly demonstrate that they
>own their domains! The WHOIS is supposed to be the authoritative
>record of domain ownership (simply putting the data on the website
>associated with a domain name is *evidence* of ownership, but isn't
>*proof* -- the WHOIS is the proof; e.g. the website or nameservers can
>be hacked, and have false info in the "evidence", but the WHOIS itself
>should always show the true owner).
>
>The text of the recommendations is also open to interpretation, which
>is unwise. e.g. on page 40 it says openly:
>
>"The Team could not come to agreement on this issue and as such no
>recommendation is included in this Final Report in relation to whether
>optional also means, optional or required for the registrar to offer."
>
>i.e. if one can't even agree on what the recommendations *say*, that's
>just wishy-washy, and doesn't help anyone. Recommendations should have
>clarity, not purposeful ambiguity.
>
>By forcing more info to be private (even against the wishes of the
>registrant), this will erode the trust of the entire DNS.
>
>BTW, for Recommendation #16, one might want to mention that registrars
>routinely accurately determine the location of registrants, in order
>to make sure that the correct sales tax is charged to them. I'm not
>too concerned about loss of thick WHOIS (.com has proven that thin
>WHOIS can work).
>
>Copying the message originator (on page 2 of the draft letter) isn't
>going to work, as it would *enable* spam (unless the originator is
>somehow verified in advance). This was pointed out in the first
>paragraph of:
>
>https://mm.icann.org/pipermail/cpwg/2019-February/000853.html
>
>Sincerely,
>
>George Kirikos
>416-588-0269
>http://www.leap.com/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On Thu, Feb 14, 2019 at 7:28 PM Alan Greenberg 
><alan.greenberg at mcgill.ca> wrote:
> >
> > As discussed on the CPWG call yesterday, attached please find the 
> draft statement to be attached to the report.
> >
> > I believe that it addresses all of the issues we discussed and 
> for which there was general concern. As decided, we will support 
> the overall report, but note that some of the particular 
> recommendations do not have our support. Others we will support but 
> nevertheless have concerns.
> >
> > The lack of focus on public interest issues puts into question 
> whether Phase 2 will suitably address access and other issues.
> >
> > THIS STATEMENT MUST BE SUBMITTED BY THE END OF FRIDAY. Please 
> make any comments with utmost urgency.
> >
> > Maureen tells me that she will issue a VERY SHORT Consensus Call 
> tomorrow, to complete prior to the submission deadline.
> >
> > WORD and PDF formats are attached.
> >
> > Alan
> > _______________________________________________
> > CPWG mailing list
> > CPWG at icann.org
> > https://mm.icann.org/mailman/listinfo/cpwg