<<<
Chronological Index
>>> <<<
Thread Index
>>>
[dow2tf] ALAC recommendations for WHOIS Task Force 2
- To: dow2tf@xxxxxxxxxxxxxx
- Subject: [dow2tf] ALAC recommendations for WHOIS Task Force 2
- From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 26 Mar 2004 17:47:01 +0100
- Mail-followup-to: dow2tf@xxxxxxxxxxxxxx
- Sender: owner-dow2tf@xxxxxxxxxxxxxx
- User-agent: Mutt/1.5.6i
Hello,
please find below a policy proposal from ALAC on how to change
the data elements collected and displayed.
For your information, our input for Task Force 1 is also included.
Unless we specifically speak about registrars, our remarks apply to
registrar and to thick registry WHOIS systems alike.
Regards,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/
Task Force 2: Data elements displayed and collected
Policy proposal
We recommend that the mandatory collection and display of
personal information about registrants be reduced as far as
possible. What information is actually required for placing
a domain name registration should be a matter of registrars'
business models, and of applicable law, not of ICANN policy.
We consider the removal of the following data elements from
registrars' and registries WHOIS services (in a tiered
model, from *all* tiers) a priority:
- registrant name, address, e-mail address, and phone
number, unless registrant has requested that this
information be made available.
- administrative contact name, address, e-mail address, and
phone number, unless registrant (or admin-c) has requested
that this information be made available.
- Billing contact. These data are traditionally not
published by registrars, but are included in many thick
registries' public WHOIS services.
For the purposes of a tiered access system (see
recommendations for task force 1), we would recommend that
the following information be included in a public tier:
- Registrar of record.
- Name servers.
- Status of domain name.
- Contact data, if the data subject specifically requests
that these data be included in the public tier.
Implementation remarks
None.
Rationale
For personal registrations, the registrant, administrative
contact, and billing contact data sets are most likely to
concern sensitive information, such as the registrant's home
address and phone number.
We recognize that domain name registrations by online
merchants often imply less privacy concerns; it has been
argued that online merchants must make privacy information
public in many jurisdictions. We are confident that
businesses will also follow these duties by requesting
registrars to make contact information about them available
publicly. Conversely, if bad actors decide not to make
contact information publicly available, that could actually
make bad actors more easily recognizable, and provide
consumers with a "red flag."
Discussion of other proposals
At the WHOIS workshop in Rome, we have heared several
lawyers praise the usefulness of registrant and other
telephone numbers in WHOIS services. That way, we were
told, many cases could be settled by a single phone call.
The easier the contact, we were told, the merrier.
This argument is troubling: What we were hearing there is a
request to ICANN to enable lawyers to make off the record
contact with other parties to a dispute that may not have a
lawyer readily available, and to make this contact in a way
which makes it hard for the registrant to get legal counsel
involved in early negotiations arising out of the dispute.
Telephone numbers of registrant and administrative contacts
should be *removed* from WHOIS services for precisely this
reason: Forcing the non-registrant party to a dispute to
open up that dispute by on-the-record means (e-mail, fax
[not universally available], postal mail) ensures that
registrants have an opportunity to retain legal counsel in
these disputes, and to fully understand any claims made by
the non-registrant party. It also helps to avoid legal
bluff and plain bullying.
To summarize, it may be true that availability of phone
numbers enables quick settlement. But availability of phone
numbers also favors situations in which these settlements
are achieved by dubious means, to the detriment of the
registrant.
Task Force 1: Access to data
Policy proposal
We recommend a simple two-tiered system.
Tier 1 -- public access. Users who access a future
WHOIS-like system anonymously get access to non-sensitive
information concerning a domain name registration, to be
defined in detail by task force 2.
Tier 2 -- authenticated access. Users who want to access a
more complete data set (to be defined in detail by task
force 2) need to reliably identify themselves, and indicate
the purpose for which they want to access the data.
The identity of the data user and their purpose is recorded
by registrars and registries, and made available to
registrants when requested. This information could be
withheld for a certain amount of time if the data user is
(1) a law enforcement authority that is (2) accessing the
data for law enforcement purposes.
Implementation remarks
We do not recommend any particular implementation of this
proposal, but note that "reliable identification" could be
provided by commercially available SSL certificates. In
general, we would favor implementation of our proposal in a
dedicated protocol (such as IRIS) over implementation
through Web forms.
Rationale
The key aspect for deciding whether access to data gathered
by registrars can be given to a third party is the purpose
for which this data is going to be used. Obviously,
registrars have no way to verify the purpose for which WHOIS
data is being accessed.
The best heurisitc we know of is to hold data users
accountable for their activities, and to put enforcement of
purpose limitations into the hands of registrants. This can
be achieved by reliably identifying data uses and putting
their identity, contact information, and purpose indication
in the hands of registrants.
At the same time, a tiered system -- if implemented
reasonably -- could preserve the ability of data users to
automatically access WHOIS data in reasonable quantities.
Registrars, on the other hand, would be enabled to limit the
amount of data any particular party can access in a given
interval of time.
Identifying data users and their purposes would also enable
registrars to comply with legal obligations to make this
kind of information available to data subjects.
Discussion of other proposals
There have been suggestions that "automated access" could be
used as a heuristic to determine illegitimate access. In
this scheme, automated access is blocked by attempting to
require human attention with all queries. One set of
implementations of these kinds of tests is known as CAPTCHA.
There is evidence that automated access is also being used
for legitimate purposes; on the other hand, there is
publicly available information on how CAPTCHA-like tests are
being circumvented in other contexts. The circumvention
here is based on a fundamental design problem of CAPTCHAs.
<http://boingboing.net/2004_01_01_archive.html#107525288693964966>
One particularly popular CAPTCHA has been broken in academic
more than a year ago, but is still being used by registrars.
<http://www.cs.berkeley.edu/~mori/gimpy/gimpy.html>
Accessibility problems posed by CAPTCHA-like tests are not
fully understood by now; we note, though, that purely visual
tests are insufficient from an accessibility point of view.
<http://www.w3.org/TR/turingtest/>
In conclusion, CAPTCHA tests address the wrong problem, and
they address it badly. We strongly recommend against going
down this path.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|