[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
allison nixon
elsakoo at gmail.com
Wed May 31 16:53:37 UTC 2017
I strongly agree with informed consent. When I first purchased my domain,
my registrar did not inform me that I was likely to receive spam or renewal
scams at the contact info I left. They should be responsible for explaining
to the customer how their product works. Changing how the product works to
fit customer misconceptions is absurd. Now that I know what info is public
and what is not, I now provide the info I think is appropriate.
On Wed, May 31, 2017 at 12:49 PM, jonathan matkowsky <
jonathan.matkowsky at riskiq.net> 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> 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 <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> <dotzero at gmail.com>; Volker Greimann
>> <vgreimann at key-systems.net> <vgreimann at key-systems.net>
>> *Cc:* RDS PDP WG <gnso-rds-pdp-wg at icann.org> <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> 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> 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>
>> 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> 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 :
>>
>> SOA ns1.google.com. dns-admin.google.com. 157458041 900 900 1800 60
>> netearthone.com
>>
>> SOA ns1.netearth.net. root.netearthone.com. 2016090201
>> <%28201%29%20609-0201> 14400 3600 1209600 86400
>>
>> law.es
>>
>> SOA ns1.eurodns.com. hostmaster.eurodns.com. 2016061402
>> <%28201%29%20606-1402> 43200 7200 1209600 86400
>>
>> riskiq.net
>>
>> SOA ns-1754.awsdns-27.co.uk. 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>
>> *To: *"nathalie coupet" <nathaliecoupet at yahoo.com>
>> *Cc: *"gnso-rds-pdp-wg" <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> 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> 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/company/legitscript-com> | Facebook
>> <https://www.facebook.com/LegitScript> | Twitter
>> <https://twitter.com/legitscript> | *Blog
>> <http://blog.legitscript.com/>* | Google+
>> <https://plus.google.com/112436813474708014933/posts>
>>
>>
>>
>>
>>
>> On Tue, May 30, 2017 at 12:57 PM, Paul Keating <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> 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> 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 at icann.
>> <gnso-rds-pdp-wg-bounces 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
>
--
_________________________________
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/64eb8818/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list