<<<
Chronological Index
>>> <<<
Thread Index
>>>
Feedback Hostnet bv on Privacy & Proxy Services Accreditation Issues PDP
- To: comments-ppsai-initial-05may15@xxxxxxxxx
- Subject: Feedback Hostnet bv on Privacy & Proxy Services Accreditation Issues PDP
- From: Arthur Zonnenberg <azonnenberg@xxxxxxxxxx>
- Date: Wed, 01 Jul 2015 17:58:05 +0200
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The website form is broken so I submit our comments thus:<br>
<br>
<br>
1. What is your name?<br>
Arthur Zonnenberg<br>
<a class="moz-txt-link-freetext"
href="http://icannwiki.com/Arthur_Zonnenberg";>http://icannwiki.com/Arthur_Zonnenberg</a><br>
<br>
<br>
2. What is your affiliation (e.g. name of ICANN Supporting
Organization, Advisory Committee, Stakeholder Group, Constituency,
individual)<br>
<br>
GNSO - Registrar Stakeholder Group<br>
<br>
<br>
3. Are you completing this survey on behalf of your group? If yes,
please specify which group if different from your listed
affiliation. <br>
<br>
Yes.<br>
<br>
<br>
4. Please indicate if you agree or disagree with the WG's
recommended definitions for the following terms: Disclosure,
Publication, Person, Law Enforcement Authority, Relay, Requester<br>
<br>
Agree with all<br>
<br>
<br>
5. Do you agree with the WG's recommendation that privacy and proxy
services should be treated the same way for the purpose of the
accreditation process?<br>
<br>
No.<br>
A proxy is a 3rd identifiable party. A privacy is a non existent
party that provides a similar service. But not equal. There are
legal differences in liability for example.<br>
<br>
<br>
6. Do you agree with the WG's recommendation that:<br>
<br>
(1) the status of a registrant as a commercial organization,
non-commercial organization, or individual should not be the driving
factor in whether proxy/privacy services are available to the
registrant;<br>
<br>
(2) privacy and proxy services should remain available to
registrants irrespective of their status as commercial or
non-commercial organizations or as individuals; and<br>
<br>
(3) privacy and proxy registrations should not be limited to private
individuals who use their domains for non-commercial purposes?<br>
<br>
Agree with all three statements. Do not limit privacy, or it is not
a universal right anymore and you will alienate users from your
system, by definition.<br>
<br>
<br>
<br>
7. Do you agree with the WG's recommendation that domain names
registered using a privacy or proxy service should be labeled as
such in Whois? <br>
<br>
No.<br>
An extra label is not necessary, as long as contact information is
correct. It will only promote bulk retrieval and bulk violation of
privacy.<br>
<br>
<br>
<br>
8. Do you agree with the WG's recommendation that:<br>
<br>
(1) privacy/proxy customer data is to be validated and verified in a
manner consistent with the requirements outlined in the WHOIS
Accuracy Specification of the 2013 RAA; and<br>
<br>
(2) in the cases where a privacy/proxy service provider is
Affiliated with a registrar (as defined by the 2013 RAA), and
validation and verification of the customer data has been carried
out by the registrar, re-verification by the privacy/proxy service
provider of the same, identical, information should not be required?<br>
<br>
No.<br>
Based on privacy laws in the Netherlands and the EU, we including a
group of 10 accredited registrars have several objections to the
WHOIS Accuracy Specification of the 2013 RAA. We do agree that
re-verification should not be required on identical data.<br>
<br>
<br>
9. Do you agree with the WG's recommendation that:<br>
<br>
(1) all rights, responsibilities and obligations of registrants,
privacy/proxy service customers and service providers need to be
clearly communicated in the privacy/proxy registration agreement,
including a provider’s obligations in managing those rights and
responsibilities and any specific requirements applying to transfers
and renewals of a domain name; and<br>
<br>
(2) all privacy/proxy service providers must disclose to their
customers the conditions under which the service may be terminated
in the event of a transfer of the domain name, and how requests for
transfers of a domain name are handled?<br>
<br>
Yes, with conditions.<br>
In the case of a transfer, the service cannot be guaranteed or
forced. If a reseller does not offer the service, a client
transferring to that reseller in the market cannot force the
reseller to do so via any ICANN policy or contract. Resellers retain
their freedom to enter into a contract with a client or not.<br>
<br>
<br>
10. Do you agree with the WG's recommendation that accredited P/P
service providers must include on their websites, and in all
Publication and Disclosure-related policies and documents, a link to
either a standardized request form or an equivalent list of specific
criteria that the provider requires in order to determine whether or
not to comply with third party requests, such as for the Disclosure
or Publication of customer identity or contact details?<br>
<br>
Yes, with conditions<br>
Where the only parties using said form are authorized by local
authorities to do so. Quasi-governmental or similar is too vague,
not in line with privacy law, and unacceptable.<br>
<br>
<br>
11. Do you agree that the following additional provisions regarding
Disclosure and Publication should be included in the Terms of
Service:<br>
<br>
(1) clarification of when there is a reference to Publication
requests (and their consequences) and when to Disclosure requests
(and their consequences);<br>
<br>
(2) explanation of the meaning and consequences of Publication;<br>
<br>
(3) the specific grounds upon which a customer’s details may be
Disclosed or Published or service suspended or terminated; and<br>
<br>
(4) clarification as to whether or not a customer:<br>
<br>
(i) will be notified when a provider receives a Publication or
Disclosure request from a third party; and<br>
(ii) in the case of Publication, whether the customer may opt to
cancel its domain registration prior to and in lieu of Publication
or Disclosure?<br>
<br>
No.<br>
Not until it is clear that these clarifications and explanations are
required by local authority law.<br>
<br>
<br>
12. Do you agree that the following should be recommended as "best
practices" for P/P service providers:<br>
<br>
(1) they should facilitate and not obstruct the transfer, renewal or
restoration of a domain name by their customers, including without
limitation a renewal during a Redemption Grace Period under the
Expired Registration Recovery Policy and transfers to another
registrar;<br>
<br>
(2) they should use commercially reasonable efforts to avoid the
need to disclose underlying customer data in the process of
renewing, transferring or restoring a domain name; and<br>
<br>
(3) they should include in their terms of service a link or other
direction to the ICANN website (or other ICANN-approved online
location) where a person may look up the authoritative definitions
and meanings of specific terms such as Disclosure or Publication?<br>
<br>
No.<br>
Privacy can be an obstruction for transfer if either party does not
offer the service.<br>
The P/P service provider should not decide or make efforts on
whether said privacy is to be upheld or not. If a legitimate and
legal need to disclosure is submitted, it must be executed.<br>
The distinction between Disclosure and Publication is ripe for abuse
by those parties requesting Disclosure in bulk. Parties should not
generally be allowed, unless they are local authority binded by law.<br>
<br>
<br>
13. Do you agree with the WG's recommendation that:<br>
<br>
(1) ICANN should publish and maintain a publicly accessible list of
all accredited P/P service providers, with all appropriate contact
information;<br>
<br>
(2) registrars should provide a web link to P/P services run by them
or their Affiliates; and<br>
<br>
(3) P/P service providers should declare their Affiliation with a
registrar (if any) as a requirement of the accreditation program? <br>
<br>
Yes to some (please indicate which you agree or disagree with, and
why, in the box below)<br>
Disagree with (2). There are way too many affiliates to provide
links to. They change too often. It's unlikely to provide a complete
or clarifying overview.<br>
<br>
<br>
14. Do you agree that providing a “designated” rather than a
“dedicated” point of contact will be sufficient for abuse reporting
purposes, since the primary concern is to have one contact point
that third parties can go to and expect a response from? Do you also
agree that the designated point of contact should be capable and
authorized to investigate and handle abuse reports and information
requests received (a standard similar to that currently required for
a Transfer Emergency Action Contact under the Inter Registrar
Transfer Policy)?<br>
<br>
No.<br>
Not above and beyond the normal abuse channel. There is no
additional ground for it.<br>
<br>
<br>
<br>
15. Do you agree with the WG's recommendation that P/P service
providers should be fully contactable, through the publication of
contact details on their websites in a manner modelled after Section
2.3 of the 2013 RAA Specification on Privacy and Proxy
Registrations?<br>
<br>
Yes, but in a different way from what the WG recommends<br>
<br>
All communication should be subject to review by the registrar
offering and the person using the service, as well as subject to
approval for any Disclosure or Publication, where not legally
binding or forced to do so.<br>
<br>
<br>
16. Do you agree that a list of the forms of malicious conduct to be
covered by a privacy/proxy service provider's designated published
point of contact should be included? Do you also agree that these
requirements should allow for enough flexibility to accommodate new
types of malicious conduct, and that Section 3 of the Public
Interest Commitments (PIC) Specification in the New gTLD Registry
Agreement or Safeguard 2, Annex 1, of the GAC’s Beijing Communique
could serve as starting points for developing such a list?<br>
<br>
Malicious conduct should not be covered this way. New forms are
found every day, while what may be malicious in one jurisdiction is
not malicious in another jurisdiction. Compare US and EU law on
privacy, for example. The US privacy law can be called malicious in
our view.<br>
<br>
<br>
<br>
17. Do you agree with the WG's recommendation that a standardized
form should be developed for the purpose of reporting abuse and
submitting requests (including requests for Disclosure of customer
information), to also include space for free form text? Do you also
agree that privacy/proxy service providers should have the ability
to “categorize” reports received, in order to facilitate
responsiveness?<br>
<br>
Not beyond the normal abuse form already present.<br>
<br>
<br>
<br>
18. Do you agree with the WG's recommendation concerning the
relaying of electronic communications? Namely, that:<br>
<br>
(1) All communications required by the RAA and ICANN Consensus
Policies must be forwarded; and<br>
<br>
(2) For all other electronic communications, P/P service providers
may elect one of the following two options:<br>
<br>
i. Option #1: Forward all electronic requests received (including
those received via emails and via web forms), but the provider may
implement commercially reasonable safeguards (including CAPTCHA) to
filter out spam and other forms of abusive communications, or<br>
ii. Option #2: Forward all electronic requests received (including
those received via emails and web forms) received from law
enforcement authorities and third parties containing allegations of
domain name abuse (i.e. illegal activities)?<br>
<br>
Yes, with conditions<br>
<br>
Do you also agree that P/P service providers must publish and
maintain a mechanism (e.g. designated email point of contact) for
Requesters to contact to follow up on, or escalate, their original
requests?<br>
<br>
Option #2 with the exclusion of 3rd parties, and the right for
registrars to filter commercial offers to the end user and person
using the service. Allegations of illegal activities must follow the
normal abuse procedure.<br>
<br>
<br>
<br>
19. Do you agree with the WG's recommendation that:<br>
<br>
(1) all third party electronic requests alleging abuse by a P/P
service customer will be promptly forwarded to the customer; and<br>
<br>
(2) a Requester will be promptly notified of a persistent failure of
delivery that a P/P service provider becomes aware of? [In answering
this question, please feel free to provide additional guidance to
the WG as to what would constitute a "persistent delivery failure"
beyond what is stated in the Initial Report]<br>
<br>
No.<br>
If included, this is not a privacy service anymore. Anybody alleging
abuse is way too broad and intrusive. The feedback of delivery
failure goes to the registrar or P/P service provider. They will
find alternative means. It is not the right of the Requester to know
so, nor should it be.<br>
<br>
<br>
<br>
20. The WG has not yet reached consensus on mandatory next steps for
a privacy/proxy service provider regarding the escalation of relay
requests. What should be the minimum mandatory requirements for
escalation of relay requests in the event of a persistent delivery
failure of an electronic communication? What is your view of the
current language under consideration by the WG?<br>
<br>
Relay requests should not follow different rules or paths compared
to regular information requests as part of investigating abuse
and/or illegal behaviour.<br>
<br>
<br>
<br>
21. Do you agree with the WG's recommendation that when a P/P
service provider becomes aware of a persistent delivery failure to a
customer, that will trigger the provider’s obligation to perform a
verification/re-verification (as applicable) of the customer’s email
address(es), in accordance with the WG’s recommendation that
customer data be validated and verified in a manner consistent with
the WHOIS Accuracy Specification of the 2013 RAA?<br>
<br>
Yes, with conditions<br>
Only due to delivery of authorized parties, not 3rd parties alleging
abuse. Otherwise, this recommendation is open for abuse by 3rd
parties suspecting a temporary e-mail failure and seizing the
opportunity to disable the domain name.<br>
Efforts for P/P service provider within commercial reason.<br>
<br>
<br>
<br>
22. What are your views on the WG's recommended illustrative
Disclosure Framework (Annex E of the Initial Report) for IP
rights-holders? Note that the proposal contains some alternative
language formulations not yet finalized by the WG.<br>
<br>
This disclosure framework destroys any privacy the person using the
service may have had. When refusing the request to disclose. This is
ludicrous.<br>
<br>
<br>
23. The WG's illustrative Disclosure Framework currently applies
only to IP (i.e. trademark or copyright) rights-holders. Please
provide your views on the applicability of a similar framework or
policy to other types of requesters. In particular, please provide
your views on the following specific questions:<br>
<br>
(1) Should it be mandatory for accredited P/P service providers to
comply with express requests from LEA in the provider’s jurisdiction
not to notify a customer?<br>
<br>
(2) Should there be mandatory Publication for certain types of
activity e.g. malware/viruses or violation of terms of service
relating to illegal activity?<br>
<br>
(3) What (if any) should the remedies be for unwarranted
Publication?<br>
<br>
(4) Should a similar framework and/or considerations apply to
requests made by third parties other than LEA and intellectual
property rights-holders?<br>
<br>
(1) only if mandated by law.<br>
(2) only if mandated by law.<br>
(3) punishment of the requester by law.<br>
(4) no separate framework should be supported for IP rights-holders.
No separate framework than that existent for LEA is necessary or
warranted.<br>
<br>
<br>
<br>
<br>
<br>
24. Do you agree that privacy/proxy service customers should be
notified prior to de-accreditation of a P/P service provider, to
enable them to make alternative arrangements? If so, should this be
when Compliance sends breach notices to the provider, as customers
would then be put on notice (as is done for registrar
de-accreditation)?<br>
<br>
Yes<br>
<br>
<br>
25. Do you agree that other P/P service providers should also be
notified, to enable interested providers to indicate if they wish to
become the gaining P/P provider (as is done for registrar
de-accreditation)? If so, should all notification(s) be published on
the ICANN website (as is done for registrar de-accreditation)?<br>
<br>
Yes<br>
<br>
<br>
<br>
26. Do you agree that a de-accredited P/P service provider should
have the opportunity to find a gaining provider to work with (as
sometimes occurs with registrar de-accreditation)? <br>
<br>
Yes<br>
<br>
<br>
<br>
27. Do you agree that a “graduated response” approach to
de-accreditation should be explored, i.e. a set series of breach
notices (e.g. up to three) with escalating sanctions, with the final
recourse being de-accreditation?<br>
<br>
Yes, with conditions<br>
That local authority law is not infringed upon by this
de-accreditation process.<br>
<br>
<br>
28. Do you agree that, where feasible, a customer should be able to
choose its new P/P service provider in the event of de-accreditation
of its existing provider?<br>
<br>
Yes, with conditions<br>
Within the arrangments made by parties.<br>
<br>
<br>
29. Do you agree that the next review of the IRTP should include an
analysis of the impact on P/P service customers, to ensure that
adequate safeguards are in place as regards P/P service protection
when domain names are transferred pursuant to an IRTP process?<br>
<br>
Yes<br>
<br>
<br>
30. Please provide any suggestions you may have on a possible
compliance framework that may facilitate the effectiveness of the
de-accreditation process. <br>
<br>
To not use a separate framework for this, or go beyond regular
de-accreditation.<br>
<br>
<br>
31. Before answering this question, please review the WG's
deliberations on the issue of whether registrants of domain names
associated with online financial transactions should be permitted to
use privacy/proxy services (including the Additional Statements in
the Final Report). What is your view on the following questions:<br>
<br>
(1) Should registrants of domain names associated with commercial
activities and which are used for online financial transactions be
prohibited from using, or continuing to use, privacy and proxy
services? If so, why, and if not, why not?<br>
<br>
(2) If you agree with this position, do you think it would be useful
to adopt a definition of “commercial” or “transactional” to define
those domains for which P/P service registrations should be
disallowed? If so, what should the definition(s) be?<br>
<br>
(3) Would it be necessary to make a distinction in the WHOIS data
fields to be displayed as a result of distinguishing between domain
names used for online financial transactions and domain names that
are not?<br>
<br>
Nobody should be prohibited from using privacy.<br>
It is an universal right.<br>
What happens when a dissident journalist or a women’s shelter are
forced to remove privacy because they have a donation button on
their websites or when they are simply soliciting support?<br>
<br>
<br>
32. Please include any additional comments or suggestions for the WG
here.<br>
<br>
The voice of the IPC is way too loud in this proposal. This flies in
the face of consensus and developing an internet everybody can use
and enjoy. Based on what does the IPC place itself above privacy
laws?<br>
<br>
<div class="moz-signature">-- <br>
<p>Met vriendelijke groet / Kind regards,</p>
<p><b>Arthur Zonnenberg</b> <br>
Product manager</p>
<a href="https://www.hostnet.nl/";><img style="width: 150px;
height: 29px; width: 150px; height: 29px; width: 150px;
height: 29px; width: 150px; height: 29px; width: 150px;
height: 29px;" alt="Hostnet"
src="cid:part1.04000302.05080309@hostnet.nl" height="29"
width="150"></a>
<p><b>Hostnet bv</b> <br>
De Ruyterkade 6 | 1013 AA Amsterdam <br>
T: 020-7500834 | F: 020-7500825 <br>
<a style="color: #4a2567;text-decoration: none;"
href="https://www.hostnet.nl/";>www.hostnet.nl</a> | <a
style="color: #4a2567;text-decoration: none;"
href="http://weblog.hostnet.nl/";>weblog.hostnet.nl</a> <br>
<br>
<a style="text-decoration: none;margin-top: 5px;margin-right:
5px;" href="https://nl-nl.facebook.com/Hostnetbv";><img
style="width: 30px; height: 25px; width: 30px; height: 25px;
width: 30px; height: 25px; width: 30px; height: 25px; width:
30px; height: 25px;" alt="Facebook"
src="cid:part5.07030405.09050607@hostnet.nl" height="25"
width="30"></a> <a style="text-decoration: none;margin-top:
5px;margin-right: 5px;" href="https://twitter.com/Hostnet";><img
style="width: 30px; height: 25px; width: 30px; height: 25px;
width: 30px; height: 25px; width: 30px; height: 25px; width:
30px; height: 25px;" alt="Twitter"
src="cid:part7.03090408.01000800@hostnet.nl" height="25"
width="30"></a> <a style="text-decoration: none;margin-top:
5px;margin-right: 5px;"
href="https://www.linkedin.com/company/hostnet-bv";><img
style="width: 30px; height: 25px; width: 30px; height: 25px;
width: 30px; height: 25px; width: 30px; height: 25px; width:
30px; height: 25px;" alt="Linkedin"
src="cid:part9.00060605.03020809@hostnet.nl" height="25"
width="30"></a> </p>
</div>
</body>
</html>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|