[gnso-rds-pdp-wg] The principle of consent
Volker Greimann
vgreimann at key-systems.net
Thu Jun 1 16:20:33 UTC 2017
Good question Tom, and I guess we will have to see how the providers of
services will deal with it. I certainly do not remember giving consent
in the required form when I joined Facebook or was auto-joined to Google
Plus...
VG
Am 01.06.2017 um 18:17 schrieb Tom Lancaster:
> How do other fields get around this? WHOIS data is not the first
> domain where by participating the participant will have to publish a
> small amount of data that could be considered PII for the world to see....
>
> For example, if I create pretty much any social media account, my
> username/profile name could be considered PII, and by default it (and
> likely a whole bunch of other data) would be visible to anyone who
> searches for it on that social media platform... How is creating a
> domain different in terms of the privacy regulations and public
> visibility of the data therein?
>
> On 1 June 2017 at 17:08, Volker Greimann <vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>> wrote:
>
> As it has been brought up by Dotzero in a very reckless manner, I
> feel it is important to point out what "consent" actually means in
> the context of the GDPR:
>
> First, implied consent is no longer sufficient under the current
> regulation. The GDPR requires that the data subject signals
> agreement to the specific and defined use of its data by "a
> statement or a clear affirmative action".
>
> In other words, an explicit and seperate opt-in is required, where
> the action of providing consent is clearly distinguishable from
> any other matters in a written document. This may be ticking a
> seperate box on a website or choosing specific technical settings,
> but in all cases it must be based on an explanation of what it is
> that the data subject is agreeing to. Silence, pre-ticked boxes or
> inactivity is insufficient. Hiding the consent clauses in the
> registration agreement is insufficient.
>
> This consent must be "freely given, specific, informed and
> unambiguous."
>
> Fun stuff comes in the next bit:
>
> The controller is required to provide “accurate and full
> information on all relevant issues,” including the nature of the
> data that will be processed, the purposes of processing, the
> identity of the controller, and*the identity of any other
> recipients of the data*.
>
> I will highlight the salient part again: "ANY OTHER RECIPIENTS OF
> THE DATA." So no expansion of those with access at a later data,
> because that would immediately invalidate the consent given.
>
> Finally, this:
>
> "Importantly, a controller may not make a service conditional upon
> consent, unless the processing is necessary for the service."
> So no consent can be construed for any uses beyond the functioning
> of the service, the internet and any other use tied directly to
> the service. All those nice uses that whois data is currently put
> to that have nothing to do with the service that is provided to
> the data subject? Say goodbye to them now!
>
> Further reading for those so inclined:
> https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-3-consent/
> <https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-3-consent/>
>
> Also note that the consent provided by current registrant does not
> satisfy the requirements, so what happens with legacy data with
> regard to its import into any RDS system will be a whole new
> nightmare down the road.
>
> Am 01.06.2017 um 17:41 schrieb Michael Peddemors:
>> +1
>>
>> On 17-06-01 07:47 AM, Dotzero wrote:
>>> The issue you raise is addressed simply enough by requiring a
>>> privacy
>>> disclosure be displayed at the time of domain registration. This
>>> requirement can be incorporated into the ICANN registry
>>> agreements. Note
>>> that this does not resolve the issue for CC domains.
>>>
>>> Michael Hammer
>>>
>>> On Thu, Jun 1, 2017 at 10:43 AM, Stephanie Perrin
>>> <stephanie.perrin at mail.utoronto.ca
>>> <mailto:stephanie.perrin at mail.utoronto.ca>
>>> <mailto:stephanie.perrin at mail.utoronto.ca>
>>> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>>>
>>> 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 <tel:%28347%29%20467-1193>
>>>> <tel:%28347%29%20467-1193> <tel:%28347%29%20467-1193> | Office::
>>>> +972-(0)8-926-2766 <tel:+972%208-926-2766>
>>>> <tel:+972%208-926-2766> <tel:+972%208-926-2766>
>>>> Emergency mobile:: +972-(0)54-924-0831
>>>> <tel:+972%2054-924-0831> <tel:+972%2054-924-0831>
>>>> <tel:+972%2054-924-0831>
>>>> Company Reg. No. 514805332
>>>> 11/1 Nachal Chever, Modiin Israel
>>>> Website <http://www.riskiq.co.il> <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>
>>>> <mailto: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>
>>>> <mailto: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>
>>>> <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>
>>> <mailto: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>
>>> <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>
>>>
>>
>>
>>
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Volker A. Greimann
> - Rechtsabteilung -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901>
> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851>
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
>
> --------------------------------------------
>
> Should you have any further questions, please do not hesitate to contact us.
>
> Best regards,
>
> Volker A. Greimann
> - legal department -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901>
> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851>
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
>
>
>
>
> _______________________________________________
> 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>
>
>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170601/501dc3b9/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list