[gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")

Thu Mar 23 13:12:17 UTC 2017

Allison, you can find the Final EWG Report here: https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf. As a reminder, all relevant background documents have been collected here: https://community.icann.org/x/QIxlAw.

Best regards,

Marika

From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of allison nixon <elsakoo at gmail.com>
Date: Thursday, March 23, 2017 at 07:08
To: "Hollenbeck, Scott" <shollenbeck at verisign.com>
Cc: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")

The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.

Also how will the need for historical whois be fulfilled? The registrars do not maintain that and massive automated querying and redistribution of query results must happen.

I don't know where this EWG report is, and it's not in my email so please let me know where it is. I will read it.

Also, this gated access reminds me of how we treat personal data in the United States. We sign over our personal data to companies that promise to keep it private*

*but they will share with "authorized third parties". The end result is that every interested party has a copy of my personal data anyways! it's worse than if I was just told it was public. I would have at least been more careful.

So we are supposed to consider this whois data as private, but under any workable gated access scheme, tens of thousands of people and scripts are going to access this allegedly "private" data, where they will often use it in activities some of which result in publishing or sharing whois data. Potential victims of spam and harassment are going to over-disclose if they are told they can trust this system's "privacy" when the reality is the opposite. Informed consent is impossible and abusers do work at banks and security companies.

And I am no expert in european privacy law but i think it would frown on such a system that assures people of the privacy of data it's collecting and then releases it to thousands of people abroad, to use in insecure scripts, with $? funding to vet the people or detect abuse.

Maybe barbed wire is safer than padded corners.

On Thu, Mar 23, 2017 at 7:21 AM, Hollenbeck, Scott <shollenbeck at verisign.com<mailto:shollenbeck at verisign.com>> wrote:
Allison, who do you think the gatekeepers are? In the system I am designing, client identity and query purpose can be assigned and confirmed by entities within specific communities of interest. As one example, an entity like the FBI would be responsible for managing the identity credentials for people who claim to be affiliated with the FBI. Keepers of data would then make access control decisions based on whatever policies this group decides are appropriate for people affiliated with the FBI. I have code running in a lab environment right now that demonstrates that this approach really does work.

Scott

On Mar 23, 2017, at 4:49 AM, allison nixon <elsakoo at gmail.com<mailto:elsakoo at gmail.com>> wrote:

No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now.

Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself.

I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it.

On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes at verisign.com<mailto:cgomes at verisign.com>> wrote:
What system are you referring to Allison? Are you saying that RDAP is not workable?

Chuck

From: gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org>] On Behalf Of allison nixon
Sent: Thursday, March 23, 2017 4:01 AM
To: Andrew Sullivan <ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>>
Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")

This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again.

On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>> wrote:
Hi,

On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:

> My biggest fear
> is that in the monitoring that companies like mine do for banks, payment
> providers, e-commerce companies, etc. that helps determine whether a
> merchant is who they say they are, and whether they are engaged in other
> bad activity (i.e., laundering money) will be unable to obtain access to
> the Whois records we need in order to preserve the integrity of the
> payments system, protect payment providers from risk, and derivatively
> protect consumers.

Modulo the inclusion of "Whois" in the above, that all seems
reasonable.  What you are saying is that you need a mechanism by which
you can create risk analyses with respect to some domain name.  But,

> In other words, my fear is that we'll lose access to
> Whois records, which we need for that purpose.

this does not follow.

Consider, for instance, that RDAP works via http(s), and that we have
several kinds of authentication and authorization mechanisms related
to https, and such things can be federated.  It is a short hop from
that knowledge to understanding that someone(s) could operate a
service that authenticates service providers like you, using tokens
provided by the to-be-evaluated domain names.  A payment provider or
whatever, when offering service to a customer, could obtain from that
customer a token of consent allowing it to obtain the relevant data
from the registries and registrars in question.  That token could then
be provided to the authorization service, which would then
authenticate your request to the RDAP servers and they could provide
you the data you request.  This is by no means an impossible task --
every time you apply for insurance online or log into a payment
provider via Google or Facebook or Amazon, you're doing this.  This is
a technique that is already deployed all over the Internet where real
money is involved, so I fail to see how it could not be used in our
case.  (In addition, you may not actually need the particulars of an
individual -- it might be enough for you to be able to tell whether
the domain and people behind it are related in some important ways to
some other domain.  But we're getting ahead of ourselves in the use
case description here.)

This is also why separating the collection of data from questions
about display and so on is necessary: we need to understand as a group
the compelling use cases that the RDS data can support.  I agree that
reputation-of-vendor systems are among those uses, and that we ought
therefore to include support of such things in what we think we want
the system to be able to support.

Of course, all of this does represent some cost to you -- your
existing service would need to change to reflect the new business
logic and access rules and mechanisms and so on.  But I don't think
this WG has so far accepted, "But that's how we do it now," as a
legitimate purpose.

Best regards,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

--
_________________________________
Note to self: Pillage BEFORE burning.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

--
_________________________________
Note to self: Pillage BEFORE burning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170323/d7b28bed/attachment-0001.html>