[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
jonathan matkowsky
jonathan.matkowsky at riskiq.net
Wed May 31 16:49:27 UTC 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170531/d0c30d36/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list