[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
allison nixon
elsakoo at gmail.com
Wed May 31 17:07:27 UTC 2017
>> 'what' that information can or may be used for
Enforced how? WHOIS is not the only outlet for information collected by
registrars. And even if WHOIS thin data was put behind a EULA, the rest of
it can't be. You can't put a DNS query behind a EULA. We can't pretend
there are restrictions on this data.
On Wed, May 31, 2017 at 12:59 PM, Michael Peddemors <michael at linuxmagic.com>
wrote:
> +1 and a good enough statement to propose a discussion consensus around.
>
> o Because it cannot be assured that in some jurisdictions, information
> contained in 'Thin Data' may be considered 'personal information', and thus
> fall under various privacy regulations, it is a requirement by ICANN and
> registrars to get 'informed consent' from the party or parties registering
> a domain name.
>
> But I don't think that is yet in the time-line of discussions.
>
> We can however work on forming a statement of 'what' that information can
> or may be used for, to help form the basis of disclosure needed for that
> informed consent
>
>
> On 17-05-31 09:49 AM, jonathan matkowsky wrote:
>
>> I agree with Stephanie that the way to address the concerns are to make
>> sure users have provided informed consent. The registration agreement
>> should have a provision under applicable law.
>>
>> On Wed, 31 May 2017 at 19:40 Stephanie Perrin
>> <stephanie.perrin at mail.utoronto.ca
>> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>>
>> I think it is a very good summary. One issue which we do not
>> discuss very often is the fact that end users who register a domain
>> name do not understand very well (if at all) what the implications
>> for their privacy are. A requirement of most data protection law is
>> to provide transparency with respect to what happens to personal
>> data. This job, in my view, has not been tackled by ICANN in the
>> required way. So while I agree with the summary, it raises the
>> issue, for those of us who do not understand what an SOA record is,
>> what thin data is, how the DNS operates, etc. there is an obligation
>> on ICANN, through its contractual control of the registries and
>> registrars, to provide greater clarity about how personal data is
>> managed, and what the risks might be for the individual. Simply
>> saying "Let's remember we are talking about the public, open
>> Internet here. Nobody has to participate that doesn't want to, just
>> like if I don't want anyone to see my license plate number on the
>> road, I don't have to drive a car either. " is not adequate.
>> (Licence registries, by the way, have become private in most
>> jurisdictions because of the risk to registrants, so the chances of
>> being stalked by some nut with road rage have mercifully
>> decreased).____
>>
>> __ Stephanie Perrin
>> __
>>
>>
>> On 2017-05-31 11:07, Gomes, Chuck via gnso-rds-pdp-wg wrote:
>>
>>>
>>> I am open to disagreement, but it seems to me that Jonathan
>>> provides a good summary and maybe even a fair conclusion of the
>>> extensive discussion that has occurred on this thread since
>>> Tuesday. Rather than continuing the extensive back and forth,
>>> which in my assessment is mostly repeating things that have
>>> already been said several times, I request that anyone who
>>> disagrees with Jonathan’s conclusions to identify what you
>>> disagree with and provide your reasoning.____
>>>
>>> __ __
>>>
>>> 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] *On Behalf Of *jonathan
>>> matkowsky
>>> *Sent:* Wednesday, May 31, 2017 10:52 AM
>>> *To:* Dotzero <dotzero at gmail.com> <mailto:dotzero at gmail.com>;
>>> Volker Greimann <vgreimann at key-systems.net>
>>> <mailto:vgreimann at key-systems.net>
>>> *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] Principle on
>>> Proportionality for "Thin Data"access____
>>>
>>> __ __
>>>
>>> I think the discussion here reflects confusion between what's
>>> available in DNS based on the domain name alone, and Thin Whois
>>> data. The fact of whether SOA records or A records may contain PII
>>> is a totally separate issue than Thin Whois data elements.____
>>>
>>> __ __
>>>
>>> Based on a domain name alone, one can use it to query DNS for
>>> record elements that may contain PII or when combined with other
>>> data, can be used to obtain PII. But all of this PII is in the
>>> public domain voluntarily by their owners, and more importantly,
>>> is outside the framework of discussion, which is limited to Whois
>>> database--not DNS. They are simply not the same.____
>>>
>>> __ __
>>>
>>> So the fact that you can get SOA records from the domain name
>>> alone begs the question of whether the domain name needs to be
>>> protected because when combined with other data elements, can be
>>> used to obtain PII.____
>>>
>>> __ __
>>>
>>> But the domain names are publicly available on the internet by
>>> virtue of being in the zone files. So the fact you can obtain the
>>> domain from thin Whois doesn't make it any more available than it
>>> is from the zone files. It is outside the framework of
>>> discussion.____
>>>
>>> __ __
>>>
>>> The thin Whois database is not what is making domain names
>>> available--so the SOA records for the domain is not a good
>>> example, even if someone put PII in that field--as that is an
>>> issue of domain names being publicly available together with DNS.
>>> Totally outside the framework of discussion.____
>>>
>>> __ __
>>>
>>> The creation date of a domain, the NS records, when the domain was
>>> last updated, and the registrar of record are simply not by any
>>> stretch of the imagination arguably PII by virtue of Whois. This
>>> is information that was voluntarily made public by virtue of using
>>> the public Internet which relies on DNS. ____
>>>
>>> __ __
>>>
>>> Privacy enthusiasts can use .Onion if they want to. But if they
>>> want to use the open Internet, that means some basic data by
>>> definition is publicly available in the DNS. If they want to
>>> protect their privacy, then they need to use common sense and not
>>> put information they dont want to be made public into the public.
>>> ____
>>>
>>> __ __
>>>
>>> The creation date is as a matter of fact, used as one of several
>>> indicators to show a domain engaged in malicious activity was
>>> unlikely a victim of being compromised. It is a critical piece of
>>> data but also not by any stretch of the wildest imagination PII. ____
>>>
>>> __ __
>>>
>>> The principle of proportionality doesn't apply to thin data unless
>>> you want to argue it applies to the very fact a domain name record
>>> was created in the public Internet. By creating the record, a user
>>> has chosen to make that record's existence public--regardless of
>>> whether they use privacy protection or not. If I register my name
>>> and birthday as a domain name, it is PII, but PII that I chose to
>>> be made publicly available by virtue of creating the domain and
>>> putting it into the zone. Does that mean I am somehow entitled to
>>> have all the RFCs re-written for me and for the public Internet
>>> to be made private? Of course not. So when people make things
>>> public voluntarily by virtue of participating in society, the
>>> principles of data protection apply differently. Let's remember we
>>> are talking about the public, open Internet here. Nobody has to
>>> participate that doesn't want to, just like if I don't want anyone
>>> to see my license plate number on the road, I don't have to drive
>>> a car either. ____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> On Wed, 31 May 2017 at 16:50 Dotzero <dotzero at gmail.com
>>> <mailto:dotzero at gmail.com>> wrote:____
>>>
>>> Translation (per Google translate) of what Volker posted:
>>>
>>> "On the basis of the ECJ ruling, the factual feature" personal
>>> data "of § 12 (1) and (2) TMG in conjunction with § 3 (1) BDSG
>>> must be interpreted in accordance with the guidelines: a
>>> dynamic IP address provided by a provider of online media
>>> services In the case of access by a person to a website, which
>>> is made generally accessible by the provider, constitutes a
>>> (protected) personal date for the provider.
>>>
>>> The IP address can only be stored as a personal date under the
>>> prerequisites of § 15 (1) TMG. This provision is to be applied
>>> in accordance with the provisions of Article 7 (f) of
>>> Directive 95/46 EC, as interpreted by the Court of Justice, to
>>> the effect that a provider of on-line media services may
>>> collect personal data of a user without the consent of the
>>> user of the services To the extent that their collection and
>>> use is necessary to ensure the general functioning of the
>>> services. However, there is a need to balance the interests
>>> and the basic rights and freedoms of the users. "____
>>>
>>> __ __
>>>
>>> On Wed, May 31, 2017 at 9:47 AM, Volker Greimann
>>> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>>
>>> wrote:____
>>>
>>> Why, just this month the German Bundesgerichtshof
>>> confirmed this in a review of a decision of the state
>>> court Berlin ( Az. VI ZR 135/13):____
>>>
>>> http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/
>>> document.py?Gericht=bgh&Art=pm&Datum=2017&Sort=3&nr=78289&
>>> pos=0&anz=74____
>>>
>>> It followed the decision of the European Court from
>>> October last year:____
>>>
>>> C-582/14, NJW 2016, 3579____
>>>
>>> The German explanation:____
>>>
>>> /"Auf der Grundlage des EuGH-Urteils ist das
>>> Tatbestandsmerkmal "personenbezogene Daten" des § 12 Abs.
>>> 1 und 2 TMG in Verbindung mit § 3 Abs. 1 BDSG
>>> richtlinienkonform auszulegen: Eine dynamische IP-Adresse,
>>> die von einem Anbieter von Online-Mediendiensten beim
>>> Zugriff einer Person auf eine Internetseite, die dieser
>>> Anbieter allgemein zugänglich macht, gespeichert wird,
>>> stellt für den Anbieter ein (geschütztes)
>>> personenbezogenes Datum dar. /____
>>>
>>> /Als personenbezogenes Datum darf die IP-Adresse nur unter
>>> den Voraussetzungen des § 15 Abs. 1 TMG gespeichert
>>> werden. Diese Vorschrift ist richtlinienkonform
>>> entsprechend Art. 7 Buchst. f der Richtlinie 95/46 EG – in
>>> der Auslegung durch den EuGH – dahin anzuwenden, dass ein
>>> Anbieter von Online-Mediendiensten personenbezogene Daten
>>> eines Nutzers dieser Dienste ohne dessen Einwilligung auch
>>> über das Ende eines Nutzungsvorgangs hinaus dann erheben
>>> und verwenden darf, soweit ihre Erhebung und ihre
>>> Verwendung erforderlich sind, um die generelle
>>> Funktionsfähigkeit der Dienste zu gewährleisten. Dabei
>>> bedarf es allerdings einer Abwägung mit dem Interesse und
>>> den Grundrechten und -freiheiten der Nutzer."/____
>>>
>>> Hope this helps.____
>>>
>>> __ __
>>>
>>> Am 31.05.2017 um 15:38 schrieb Paul Keating:____
>>>
>>> See: recent Europrean court decisions on IP
>>> addresses as PII.____
>>>
>>> __ __
>>>
>>> Can you please provide the citations? I a-m not aware
>>> of any court decision issuingsuch a broad ruling. ____
>>>
>>> __ __
>>>
>>> Thanks,____
>>>
>>> __ __
>>>
>>> Paul
>>>
>>> Sent from my iPad____
>>>
>>>
>>> On 31 May 2017, at 12:20, Volker Greimann
>>> <vgreimann at key-systems.net
>>> <mailto:vgreimann at key-systems.net>> wrote:____
>>>
>>> In some cases the ability to use data set A in
>>> combination with data set B to enable one to
>>> identify an individual turns data set A into PII.
>>> ____
>>>
>>> See: recent Europrean court decisions on IP
>>> addresses as PII.____
>>>
>>> I am with you in viewing thin data as rather
>>> unlikely to be defined as PII, but depending on
>>> how this data is used it is not inconceivable that
>>> it may be found to contain PII depending on the
>>> use. Unlikely, but not impossible.____
>>>
>>> Volker____
>>>
>>> __ __
>>>
>>> Am 30.05.2017 um 23:40 schrieb Paul Keating:____
>>>
>>> Im sorry but i don't see the logic here (or
>>> the legal constraint)____
>>>
>>> __ __
>>>
>>> Privacy laws protect personal data of
>>> INDIVIDUALS. They do t protect non-personal
>>> data or data from non-individuals.____
>>>
>>> __ __
>>>
>>> Nothing on the list below is personal data.
>>> And no e of the principles given by Natalie
>>> apply.____
>>>
>>> __ __
>>>
>>> The fact that i could use the data to obtain
>>> other data is irrelevant. I can use a car to
>>> rob a bank but that itself is not a reason to
>>> restrict access to automobiles.____
>>>
>>> __ __
>>>
>>> Me thinks you are trying to create a scarcity
>>> for some reason.
>>>
>>> Sent from my iPad____
>>>
>>>
>>> On 30 May 2017, at 23:22, Chris Pelling
>>> <chris at netearth.net
>>> <mailto:chris at netearth.net>> wrote:____
>>>
>>> ok - a thought :____
>>>
>>> __ __
>>>
>>> Thin data includes nameservers, being able
>>> to *_mass_* collect thin data gaining NS
>>> information then allows you to do a DIG of
>>> a SOA record on the DNS service to gain
>>> the email address of the hostmaster : ____
>>>
>>> __ __
>>>
>>> Some examples (radomly picked from the
>>> list) :____
>>>
>>> gmail.com <http://gmail.com> :____
>>>
>>> SOA ns1.google.com
>>> <http://ns1.google.com>.
>>> dns-admin.google.com
>>> <http://dns-admin.google.com>. 157458041
>>> 900 900 1800 60
>>> netearthone.com <http://netearthone.com>____
>>>
>>> SOA ns1.netearth.net
>>> <http://ns1.netearth.net>.
>>> root.netearthone.com
>>> <http://root.netearthone.com>. 2016090201
>>> <tel:%28201%29%20609-0201> 14400 3600
>>> 1209600 86400____
>>>
>>> law.es <http://law.es>____
>>>
>>> SOA ns1.eurodns.com
>>> <http://ns1.eurodns.com>.
>>> hostmaster.eurodns.com
>>> <http://hostmaster.eurodns.com>.
>>> 2016061402 <tel:%28201%29%20606-1402>
>>> 43200 7200 1209600 86400____
>>>
>>> riskiq.net <http://riskiq.net>____
>>>
>>> SOA ns-1754.awsdns-27.co.uk
>>> <http://ns-1754.awsdns-27.co.uk>.
>>> awsdns-hostmaster.amazon.com
>>> <http://awsdns-hostmaster.amazon.com>. 1
>>> 7200 900 1209600 86400____
>>>
>>> __ __
>>>
>>> Now as you can see - those above examples
>>> allow you to get (or build) an email
>>> list. Most will normally point to the
>>> providers service, but, some that are
>>> DIY'ing their hosting, it might not be.____
>>>
>>> __ __
>>>
>>> Kind regards,
>>>
>>> Chris____
>>>
>>> __ __
>>>
>>> ------------------------------
>>> ------------------------------------------
>>>
>>> *From: *"allison nixon" <elsakoo at gmail.com
>>> <mailto:elsakoo at gmail.com>>
>>> *To: *"nathalie coupet"
>>> <nathaliecoupet at yahoo.com
>>> <mailto:nathaliecoupet at yahoo.com>>
>>> *Cc: *"gnso-rds-pdp-wg"
>>> <gnso-rds-pdp-wg at icann.org
>>> <mailto:gnso-rds-pdp-wg at icann.org>>
>>> *Sent: *Tuesday, 30 May, 2017 21:52:32
>>> *Subject: *Re: [gnso-rds-pdp-wg] Principle
>>> on Proportionality for
>>> "Thin Data"access____
>>>
>>> __ __
>>>
>>> so can you name one specific example of
>>> how someone could abuse thin data?____
>>>
>>> __ __
>>>
>>> On Tue, May 30, 2017 at 4:50 PM, nathalie
>>> coupet via gnso-rds-pdp-wg
>>> <gnso-rds-pdp-wg at icann.org
>>> <mailto:gnso-rds-pdp-wg at icann.org>>
>>> wrote:____
>>>
>>> *Abuse* is the improper usage or
>>> treatment of an entity
>>> <https://en.wikipedia.org/wiki/Entity>,
>>> often
>>> to unfairly
>>> <https://en.wikipedia.org/wiki
>>> /Distributive_justice> or
>>> improperly gain benefit. In our
>>> context, abuse is the improper usage
>>> of WHOIS/RDS to unfairly or improperly
>>> gain access to information or to game
>>> the system. ____
>>>
>>> __ __
>>>
>>> Here are some of the overarching
>>> principles which should guide us when
>>> building RDS: ____
>>>
>>> __ __
>>>
>>> DATA LIFECYCLE
>>> PRIVACY PRINCIPLE
>>> PROTECTION MEASURE____
>>>
>>> Collection
>>> Proportionality and purpose
>>> specification Data
>>> minimisation, Data quality____
>>>
>>> Storage
>>> Accountability, Security measures,
>>> Sensitive data
>>> Confidentiality, Encryption,
>>> Pseudonomisation____
>>>
>>> Sharing and processing Lawfulness and
>>> fairness, Consent, Right of access
>>> Data access control, Data leakage
>>> prevention____
>>>
>>> Deletion
>>> Openness, Right to erasure
>>> Retention,
>>> Archival, Erasure____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> If such principles are not respected,
>>> ICANN will be liable. Consumers don't
>>> need to have all the thin data when
>>> making a query. This could protect
>>> them and enable them to have access to
>>> the RDS without raising much
>>> opposition. ____
>>>
>>> __ __
>>>
>>> Now, we could discuss the possibility
>>> for broader query types. These
>>> principles would still apply, but
>>> would be contextualized in order to
>>> take into account new sets of
>>> parameters for each broader query. By
>>> increasing granularity as much as
>>> possible, while applying these
>>> aformentioned principles, we just
>>> might find a way to accomodate
>>> everyone. ____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> ____
>>>
>>> Nathalie ____
>>>
>>> __ __
>>>
>>> On Tuesday, May 30, 2017 4:00 PM, John
>>> Horton <john.horton at legitscript.com
>>> <mailto:john.horton at legitscript.com>>
>>> wrote:____
>>>
>>> __ __
>>>
>>> I was going to reply to Natalie's
>>> email as well, but Paul's comments
>>> capture my thoughts, so: *+1. *____
>>>
>>>
>>> ____
>>>
>>> John Horton
>>> President and CEO, LegitScript____
>>>
>>> ____
>>>
>>> __ __
>>>
>>> *Follow****Legit**Script*: LinkedIn
>>> <http://www.linkedin.com/compa
>>> ny/legitscript-com>
>>> | Facebook
>>> <https://www.facebook.com/LegitScript>
>>> |
>>> Twitter
>>> <https://twitter.com/legitscript> |
>>> _Blog
>>> <http://blog.legitscript.com/>_ |
>>> Google+
>>> <https://plus.google.com/11243
>>> 6813474708014933/posts>____
>>>
>>> __ __
>>>
>>> ____
>>>
>>> __ __
>>>
>>> On Tue, May 30, 2017 at 12:57 PM, Paul
>>> Keating <paul at law.es
>>> <mailto:paul at law.es>> wrote:____
>>>
>>> Natalie,____
>>>
>>> __ __
>>>
>>> Thank you for the email. Im
>>> copying the list because i see
>>> others have replied to your
>>> comment.____
>>>
>>> __ __
>>>
>>> I strenuously object to the
>>> concept. We are discussing THIN
>>> DATA ONLY HERE. Unless someone
>>> can explain to me why any of this
>>> data set has privacy concerns this
>>> is a non-issue. I would certainly
>>> appreciate someone explaining
>>> what, if any, privacy issues are
>>> perceived to be at issue here.____
>>>
>>> __ __
>>>
>>> Moreover, while you suggest that
>>> the idea escapes the need to
>>> declare a purpose, it does nothing
>>> but reinforce a subjective
>>> criteria based system in which the
>>> declared purpose is used to
>>> somehow limit the data being
>>> retrieved.____
>>>
>>> __ __
>>>
>>> If i am missing something please
>>> let me know. ____
>>>
>>>
>>> Paul____
>>>
>>>
>>> Sent from my iPad____
>>>
>>>
>>> On 30 May 2017, at 21:08, nathalie
>>> coupet via gnso-rds-pdp-wg
>>> <gnso-rds-pdp-wg at icann.org
>>> <mailto:gnso-rds-pdp-wg at icann.org>>
>>> wrote:____
>>>
>>> Hi Paul,____
>>>
>>> __ __
>>>
>>> In the context of thin data,
>>> in view of the opposition of
>>> some to allow unauthenticated
>>> access to all the thin data,
>>> the principle of
>>> proportionality serves as an
>>> over-arching principle at this
>>> particular phase in our work
>>> in order to protect data from
>>> abuse while not restricting
>>> access. ____
>>>
>>> Thin data must be
>>> proportionate to the query, be
>>> useful for that particular
>>> query. All and any other thin
>>> data foreign to this query
>>> should not be shared. This
>>> principle potentially avoids
>>> having to resort to
>>> 'legitimate purposes' which
>>> cannot be verified for
>>> unauthenticated access. ____
>>>
>>> ____
>>>
>>> ____
>>>
>>> Nathalie ____
>>>
>>> __ __
>>>
>>> On Tuesday, May 30, 2017 2:44
>>> PM, "Gomes, Chuck via
>>> gnso-rds-pdp-wg"
>>> <gnso-rds-pdp-wg at icann.org
>>> <mailto:gnso-rds-pdp-wg at icann.
>>> org>>
>>> wrote:____
>>>
>>> __ __
>>>
>>> Because Nathalie was the
>>> originator and was unable to
>>> speak on the call, I encourage
>>> her to describe the nature of
>>> the issue on this thread.____
>>>
>>> ____
>>>
>>> Chuck____
>>>
>>> ____
>>>
>>> *From:*gnso-rds-pdp-wg-bounces
>>> @icann.
>>> <mailto:gnso-rds-pdp-wg-bounce
>>> s at icann.org>
>>>
>>> --
>> jonathan matkowsky, vp - ip & head of global brand threat mitigation
>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
>>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> 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/20170531/48b4c529/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list