Re: [gnso-acc-sgb] WG B Proposal (although odd)

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Hi Pat,

Just a quick response to a thoughtful idea:

In the privacy-protection community, the ideal standard for control of
personal data is that it is to be controlled by the person whom the data
describe (with systematic exceptions in legally well-defined cases
involving due process).  Thus your idea seems very good to me from that
perspective.  (And as you note, it also frees the registries and registrars
from some potentially expensive human intervention.)

A fine-tuning of that idea is (a) that people should be well-informed about
the use of their data in order to control it properly, and (b) that when
signing up for some new service generally, an opt-in approach is more
privacy-centric than opt-out.  That is, new "subscribers" to any service or
system that collects personal data should ideally default to "non-access"
unless those people explicitly authorize use of their individual personal
data (i.e., require explicit opt-in by the person described by the data in
order to allow access, rather than defaulting to access unless the person
opts-out).

I would prefer to start from a position of non-access and carve out opt-in
cases and conditions where access may be given, rather than starting from a
position of access and carving out opt-out cases and conditions.  Opt-in is
especially important for "due process" when subscribers are less
well-informed about the use of their personal data.

I do think the burden of proof generally should be on the parties who want
to get access to show why they should get access, and then access policy
can be designed such that they get the access that is appropriate to that
need without necessarily getting inappropriate access.

I look forward to examining your proposal in more depth over the next
couple days leading up to our Wednesday call.

Dan

PS -- Some registrars (such as NSI) do provide partial opt-out for some
Whois data, but it may require additional payment for the privacy service
as a separate contract.  However some registrars may already provide this
option without extra charge.  It seems to me that it may be productive to
standardize this practice as a free option for all registrars under the
OPOC paradigm.  Converting it to opt-in would be even better from my point
of view.

Note also that some registrars actually take ownership of the domain during
the period of the contract, and as a proxy they list themselves in the
Whois database (cf. GoDaddy).  But their policies regarding data access may
not necessarily protect privacy substantially better than the NSI-type
option, and they may intervene more in domain operation in the case of
non-public-LEA disputes, which can be a serious trade-off in with regard to
some cases of unwarranted domain harassment.



At 4:51 PM -0400 5/7/07, patrick cain wrote:
>Hi,
>
>After listening to numerous group debate the "how do people get access" I
>thought about attacking the problem from the other direction. Since our goal
>is to provide privacy protections for domain registrants/owners via OPOC, I
>keep returning to the idea of allowing registrants to add some 'privacy
>protections' during the registrations process -- and then not change the
>rest of the Whois world. The 'privacy protection' can be enabled from the
>billing address and also be selectable by people who may or may not want it.
>But the onus is now on the domain registrant to decide instead of the
>registrar/registry -- which I don't think is really workable with 800 of
>them.
>
>Trying to fit this into the "how do people access Whois data?" may require
>some squinting, but it does work with the OPOC proposal and shouldn't
>require much retooling of the infrastructure. I will also readily agree that
>the proposal is not fully thought out, but I'm starting to like it more as
>I'm engaged in more conference calls.
>
>Milton, please advise if there is a better place to bring this up because
>this is too off base from our subgroup charter.
>
>Pat Cain
>
>Attachment converted: Macintosh HD:task B - template - pc prop.doc
>(WDBN/«IC») (0006E603)