[gnso-rds-pdp-wg] The principle for thin data (was Re: Principle on Proportionality for "Thin Data"access)
John Bambenek
jcb at bambenekconsulting.com
Thu Jun 1 17:02:35 UTC 2017
Hmm, not sure why that's happening but fair enough request.
John Bambenek
On 6/1/2017 11:58 AM, Ayden Férdeline wrote:
> Can you please sign off your emails with your name or initials? For
> some reason, many of the messages I receive from this list come from
> "RDS PDP WG" and do not affix the sender's name. Thank you.
>
> Ayden Férdeline
> linkedin.com/in/ferdeline <http://www.linkedin.com/in/ferdeline>
>
>
>> -------- Original Message --------
>> Subject: Re: [gnso-rds-pdp-wg] The principle for thin data (was Re:
>> Principle on Proportionality for "Thin Data"access)
>> Local Time: June 1, 2017 5:52 PM
>> UTC Time: June 1, 2017 4:52 PM
>> From: gnso-rds-pdp-wg at icann.org
>> To: gnso-rds-pdp-wg at icann.org
>>
>>
>> So you agree that you can educate your customers to make consent
>> possible? Good.
>>
>> Now can we move on?
>>
>>
>> On 6/1/2017 11:46 AM, Ayden Férdeline wrote:
>>> +1 Stephanie. The vast majority of people, if given the appropriate
>>> information and time, are perfectly capable of understanding a
>>> complex or technical issue.
>>>
>>> Ayden Férdeline
>>> linkedin.com/in/ferdeline <http://www.linkedin.com/in/ferdeline>
>>>
>>>
>>>> -------- Original Message --------
>>>> Subject: Re: [gnso-rds-pdp-wg] The principle for thin data (was Re:
>>>> Principle on Proportionality for "Thin Data"access)
>>>> Local Time: June 1, 2017 3:40 PM
>>>> UTC Time: June 1, 2017 2:40 PM
>>>> From: stephanie.perrin at mail.utoronto.ca
>>>> To: jonathan matkowsky <jonathan.matkowsky at riskiq.net>
>>>> RDS PDP WG <gnso-rds-pdp-wg at icann.org>
>>>>
>>>>
>>>> I certainly agree that if people enter personal information as part
>>>> of their DNS registration or their motor vehicle licence
>>>> registration, it is done with implied consent... as long as there
>>>> is sufficient information to permit them to understand just how the
>>>> data is being used and where it is going. However, as I tried to
>>>> say with respect to registering a domain name, I really don't think
>>>> the average non-expert citizen who might want to register a domain
>>>> name would get enough information to truly understand how far
>>>> his/her information goes, and how difficult it is to get it removed
>>>> once it has appeared in the public record. We should build this
>>>> system so that everyone understands it, not just the experts.
>>>>
>>>> cheers Stephanie
>>>>
>>>>
>>>> On 2017-06-01 05:18, jonathan matkowsky wrote:
>>>>> Stephanie,
>>>>>
>>>>>
>>>>> I agree with you that we should not conflate collection limitation
>>>>> principles with openness principles.
>>>>>
>>>>> I respectfully disagree with most of what you wrote in the first
>>>>> paragraph of your post script.
>>>>> Here we are talking about users potentially entering personal or
>>>>> pseudonymous information when they are not being asked for it (nor
>>>>> is it required) to begin with, and it is not required for purposes
>>>>> of which it's being collected. That is the
>>>>>
>>>>> scope
>>>>> of what needs to be assessed
>>>>> if at all and how the scope needs to be
>>>>> defined from the beginning
>>>>> if you were to conduct a PIA
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Personal information is not being used or intended to be used just
>>>>> because a person decides to enter personal information into a field.
>>>>>
>>>>> The example of how you can combine databases to re-identify a
>>>>> person based on the SOA record is the equivalent of protecting
>>>>> domain names as personal information because a person
>>>>> can register their driver's license
>>>>> or name and date of birth
>>>>> as a domain name.
>>>>>
>>>>> I would argue no PIA should be required
>>>>> as a result
>>>>> even in accordance even with best practices.
>>>>>
>>>>> A PIA needs to be conducted in a manner that is commensurate with
>>>>> the level of privacy risk identified
>>>>> .
>>>>>
>>>>> I respectfully disagree with you that thin data is personal. We
>>>>> are talking about identifiers (codes or strings that represent an
>>>>> individual or device). Many labels can be used to point to
>>>>> individuals. Some are precise and most, imprecise or vague.
>>>>> There's no question that an IP address is a device identifier.
>>>>> Device IDs, MAC addresses can be a source for user tracking. But
>>>>> i
>>>>> dentifiers can be strong or weak depending on how precise they are
>>>>> as well as the context. It cannot be measured without taking
>>>>> linkability into consideration. For that reason, name servers are
>>>>> not the same as IP addresses or MAC addresses any more so than the
>>>>> existence of a domain name is an identifier. If a person chooses
>>>>> to use identifiable information when it is not being asked for or
>>>>> required for purposes of which the data is being collected, that
>>>>> does that mean we need to classify all the data according to that
>>>>> unlikely scenario. Those setting up their own DNS would be
>>>>> relatively speaking, sophisticated Internet users that presumably
>>>>> know the basics of how DNS operates in any case, so by entering
>>>>> the information in that way, they are choosing to customize their
>>>>> DNS in a personal way similar to a person that chooses to show
>>>>> personal information on their license plate number.
>>>>>
>>>>> I know that the motor vehicle registry is restricted now in most
>>>>> places so that you would need a subpoena to get that kind of
>>>>> personal information. This is also true of an IP address though
>>>>> and IP providers. The fact is a person can put their name and date
>>>>> of birth on a license plate if they want to customize it. And then
>>>>> they get on the road. That does not mean the license plate numbers
>>>>> are all personal information. It's pseudonymous data. It is true
>>>>> that it is a stronger identifier than an IP address insofar as if
>>>>> you subpoena the motor vehicle registry operator, you will get the
>>>>> personal information behind that license plate number. If you
>>>>> subpoena the ISP, you MIGHT get the personal information depending
>>>>> on the nature of the IP address. It's still true that to drive a
>>>>> car, you need to show your license plate number on the vehicle.
>>>>>
>>>>> I would argue that thin Whois data is pseudonymous or personal
>>>>> data to the same extent that a person can choose to _customize_ a
>>>>> license plate if they want to, and put personal or psuedonymous
>>>>> data into fields
>>>>> for which the data being collected does not ask for or require
>>>>> them to do so.
>>>>>
>>>>>
>>>>> A
>>>>> person can register their driver's license as a domain name.
>>>>> They can use a personal email in their SOA record, or personal NS.
>>>>> Just because it's theoretically possible for someone to enter
>>>>> pseudonymous (or even personal) data into multiple databases when
>>>>> they are not being asked for it, and those combination of choices
>>>>> make it possible to identify them, does not mean one of the sets
>>>>> (Thin Whois) should be classified as personal information subject
>>>>> to a PIA.
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Matkowsky,
>>>>> VP – IP & Brand Security
>>>>> USA:: 1.347.467.1193 | Office:: +972-(0)8-926-2766
>>>>> Emergency mobile:: +972-(0)54-924-0831
>>>>> Company Reg. No. 514805332
>>>>> 11/1 Nachal Chever, Modiin Israel
>>>>> Website <http://www.riskiq.co.il>
>>>>> RiskIQ Technologies Ltd. (wholly-owned by RiskIQ, Inc.)
>>>>>
>>>>> On Thu, Jun 1, 2017 at 12:02 AM, Stephanie Perrin
>>>>> <stephanie.perrin at mail.utoronto.ca
>>>>> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>>>>>
>>>>> Your summary today was great Andrew.
>>>>>
>>>>> I am not arguing about the disclosure of thin data. We
>>>>> already voted on unauthenticated mandatory disclosure, weeks
>>>>> ago (or at least it feels like weeks ago). Lets please move
>>>>> on. We are debating this yet again, because people keep
>>>>> asking, is thin data personal? [lots of people missed the last
>>>>> call] The answer is yes (IMHO). Does that mean it cannot be
>>>>> disclosed? The answer is no. Does the proportionality
>>>>> principle apply? Yes. Have we already gone through this?
>>>>> Yes. Can we come back to it? Yes, but hopefully only if we
>>>>> have to.....we will have to when we get to data elements.
>>>>>
>>>>> cheers Stephanie
>>>>> PS a fundamental problem here is that people try to categorize
>>>>> information that in their view should be disclosed, as not
>>>>> personal information. This fight has gone on for years over
>>>>> IP address, for instance. The important question is not
>>>>> actually whether it is personal data or not, it is "do you
>>>>> need to disclose it to make things work?"....and if the answer
>>>>> is yes then you try to mitigate the disclosure and try to keep
>>>>> it minimized to what is absolutely required. Hence the PIA,
>>>>> which should employ both data minimization and the test in the
>>>>> proportionality principle as techniques to evaluate data elements.
>>>>> A good and really simple example is a phone number. IS it
>>>>> personal info? (the telcos fought for years, trying to claim
>>>>> they owned it and it was not personal). Obviously it pertains
>>>>> to you, people feel strongly that it is personal (culturally
>>>>> relative of course but...) and yet if noone ever learns your
>>>>> number your phone won't ever receive a call. That does not
>>>>> mean you have to disclose it everywhere.....only where
>>>>> necessary. And it should mean that it does not have to follow
>>>>> you everywhere, but that is becoming increasingly hard to
>>>>> manage....
>>>>>
>>>>> By the way, informed consent is not the same as transparency
>>>>> requirements. Transparency requirements are exactly
>>>>> that....you have to be transparent about what you are doing
>>>>> with data. Let us not conflate that with consent.
>>>>>
>>>>> I will quit now and stop trying to answer questions. I would
>>>>> like to humbly suggest, however, that we have a real shortage
>>>>> of basic understanding of how data protection law works and is
>>>>> interpreted. If there is a data protection law expert that
>>>>> folks might listen to, we should hire that person to advise
>>>>> us. It might save a lot of time.
>>>>> On 2017-05-31 16:00, Andrew Sullivan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, May 31, 2017 at 03:20:59PM -0400, Stephanie Perrin wrote:
>>>>>>
>>>>>>
>>>>>>> That does not mean we need to protect it, it means we have to examine it in
>>>>>>> terms of DP law. May I repeat the suggestion that Canatacci made in
>>>>>>> Copenhagen in response to a question.....(I forget the precise question he
>>>>>>> was asked, sorry). If you want to figure out whether you have to protect
>>>>>>> something or not, do a privacy impact assessment.
>>>>>>>
>>>>>>>
>>>>>> As I think I've said more than once in this thread, I think we _have_
>>>>>> done that assessment and I think the answers are obvious and I think
>>>>>> therefore that there is nothing more to say about this principle in
>>>>>> respect of thin data:
>>>>>>
>>>>>> - the data is either necessary for the operation of the system
>>>>>> itself or else necessary for distributed operation and
>>>>>> troubleshooting on the Internet.
>>>>>>
>>>>>> - the data does not expose identifying information about anyone,
>>>>>> except in rather strained examples where the identifying
>>>>>> information is already completely available via other means.
>>>>>>
>>>>>> What more is one supposed to do?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> A
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
--
--
John Bambenek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170601/6a92d79f/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list