[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
John Bambenek
jcb at bambenekconsulting.com
Wed May 31 14:50:25 UTC 2017
It is still stored by the provider in a service operated by the provider
and edited with an interface created by the provider using whatever
business logic or validation that is written by the provider. Fine,
control is not the precise word.
All that being said, if SOA is ok even when editable only by an
interface by the provider then so is all WHOIS data which is entered by
the consumer. It really is either/or here. You can't on one hand say
there are no privacy implications of SOA and then turn around when you
have an almost identical set of facts and cry privacy foul over whois.
j
On 5/31/2017 9:46 AM, Chris Pelling wrote:
> John,
>
> You are entirely wrong in your statement : Point in fact, for
> consumers, SOA is NOT under control of the consumer.
>
> Yet many of the largest and paid service allow you to edit just that
> record as the consumer.
>
> Kind regards,
>
> Chris
>
> ------------------------------------------------------------------------
> *From: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
> *To: *"Paul Keating" <paul at law.es>
> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
> *Sent: *Wednesday, 31 May, 2017 15:14:53
> *Subject: *Re: [gnso-rds-pdp-wg] Principle
> on Proportionality for "Thin Data"access
>
> Point in fact, for consumers, SOA is NOT under control of the
> consumer. I would bet a very rare set of consumers who own domains
> actually run their own DNS servers. They are either using the
> registrar or their hosting provider.
>
> Sure they put in the data. But that is also true of whois/rds. No one
> does this for the consumer. They put in all their own data.
> Considering the number of domains under the control of various
> registrars that still accept all 0s for phone number, no one verifies
> that data either.
>
> This does, however, reinforce that making whois for free solves almost
> all of this issue. If consumers have a true choice that's free and the
> choices are explained, all of these privacy issues almost completely
> are resolved.
>
> J
>
> Sent from my iPhone
>
> On May 31, 2017, at 08:38, Paul Keating <paul at law.es
> <mailto:paul at law.es>> wrote:
>
> +1!
>
> Sent from my iPad
>
> On 31 May 2017, at 11:38, Victoria Sheckler <vsheckler at riaa.com
> <mailto:vsheckler at riaa.com>> wrote:
>
> +1
>
>
>
> *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
> *Andrew Sullivan
> *Sent:* Tuesday, May 30, 2017 10:36 PM
> *To:* Chris Pelling <chris at netearth.net
> <mailto:chris at netearth.net>>
> *Cc:* gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject:* Re: [gnso-rds-pdp-wg] Principle on Proportionality
> for "Thin Data"access
>
>
>
> Hi,
>
>
>
> This is a pretty strained example, since the RDS is irrelevant
> here. You can get the SOAs in the examples as soon as you
> know the domain name. You have no need to consult RDS at all.
> And the SOA is completely under the control of the DNS
> operator, and in the absence of Internet Protocol Police you
> can put whatever you want in there for your own zones. No
> real dns admin has trusted that field for years.
>
>
>
> This repetitious and always fruitless discussion of whether
> anyone can get any data to "abuse" out of the thin data seems
> to miss the point of why we started with thin data: it was
> supposed to be easy. I've yet to hear even one remotely
> plausible issue with respect to any of this data, because it's
> all needed by virtue of creating a name space on the Internet.
> That's what domain name registrations do, so if you don't
> want to expose this much data you shouldn't register domain
> names. Unless someone can come up with a single concrete
> example of something problematic, I'd like us to move on to a
> topic where there's some substance to discuss.
>
>
>
> Best regards,
>
>
>
> A
>
> --
>
> Andrew Sullivan
>
> Please excuse my clumbsy thums.
>
>
> On May 30, 2017, at 17: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
>
>
>
> *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 <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 <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/20170531/bd944e59/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list