[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
Stephanie Perrin
stephanie.perrin at mail.utoronto.ca
Tue May 30 21:51:29 UTC 2017
I have explained this with nauseating repetition on the list, and I am
sorry to do it again.
Data that is gleaned from a file related to an individual, ie in this
case their registration data, even if it is nameservers and the like, is
their personal data. eg. If my birthplace is Ottawa Ontario, Ottawa
ONtario becomes my personal info as my birthplace, the actual place is
not personal information. It is the association with the individual
that counts. Now in the case of "thin data", what we are looking at is
non-nominative data.....the data is not identifiable as personal data on
its own. However, as Canatucci said in Copenhagen during our meeting,
personal data does not lose its character as personal data simply by
having the identifier stripped. It is clearly much less sensitive, but
it remains personal to a varying extent, depending on the
characteristics of each data element.
Stephanie Perrin
On 2017-05-30 17:40, Paul Keating wrote:
> 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 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 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
>>
>>
>> *FollowLegitScript*: 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
>> <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 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
>> *Paul Keating
>> *Sent:* Tuesday, May 30, 2017 2:17 PM
>> *To:* Lisa Phifer <lisa at corecom.com
>> <mailto:lisa at corecom.com>>; 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
>> Im sorry to have missed the call but had a client engagement.
>> Can someone briefly describe the nature of the issue?
>> Thanks
>> Paul
>> *From: *<gnso-rds-pdp-wg-bounces@ icann.org
>> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of
>> Lisa Phifer <lisa at corecom.com <mailto:lisa at corecom.com>>
>> *Date: *Tuesday, May 30, 2017 at 7:52 PM
>> *To: *RDS PDP WG <gnso-rds-pdp-wg at icann.org
>> <mailto:gnso-rds-pdp-wg at icann.org>>
>> *Subject: *[gnso-rds-pdp-wg] Principle on Proportionality
>> for "Thin Data"access
>>
>> All, per today's call action item:
>>
>> *Action Item: Nathalie Coupet and any other WG
>> members who wish to do so to propose to the WG list a
>> new principle on proportionality for "thin data." All
>> WG members to comment on that proposed principle in
>> advance of next call.
>>
>> *we are starting a new thread here which anyone may
>> reply to if they wish to propose (or respond to) a
>> new principle on proportionality for "thin data" access.
>>
>> Best, Lisa
>> ______________________________ _________________
>> 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
>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>
>> ______________________________ _________________
>> 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
>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>
>>
>> ______________________________ _________________
>> 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
>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>
>>
>> ______________________________ _________________
>> 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
>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170530/da5d2e24/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list