[gnso-rds-pdp-wg] The principle of consent
Gomes, Chuck
cgomes at verisign.com
Fri Jun 2 12:51:44 UTC 2017
Jonathan makes a point that all of us should remember when dealing with one another who do not speak English as their native language and come from a different culture than us.
For those who do not know, Volker’s native language is German.
Chuck
From: jonathan matkowsky [mailto:jonathan.matkowsky at riskiq.net]
Sent: Friday, June 02, 2017 6:08 AM
To: Volker Greimann <vgreimann at key-systems.net>
Cc: Gomes, Chuck <cgomes at verisign.com>; gnso-rds-pdp-wg at icann.org
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] The principle of consent
I don't know Volker to know if his native language is English or not. And I don't want to draw more attention to this example.
But I think it's still probably worth pointing out that with ICANN working groups being so international, sometimes emails may sound harsh because something is lost in translation. So we should keep that in mind too.
I know as an American and Israeli living in Israel for the last 5 years, that very often I thought Israelis meant one thing when it was just a matter of translating words from Hebrew into English in a way that didn't fully work the way intended. I look back and see that a lot of communication is sometimes based on cultural differences and ways of thinking in different languages. Something can sound derogatory when translated into English the wrong way, even where the intent was not meant to be negative. So, even if it doesn't apply here, we as a team should be mindful of that possibility because English may not be everyone's first language.
Jonathan Matkowsky,
On Fri, Jun 2, 2017 at 12:36 PM, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:
My apologies. The term reckless was not the one I was looking for.
Am 01.06.2017 um 23:06 schrieb Gomes, Chuck:
I apologize for using Volker’s message as an example but I think it might serve as a useful lesson for everyone. The clause I highlighted in yellow below is derogatory and adds no value to the points made. I ask Volker and everyone to avoid derogatory remarks and stick to the points that will constructively contribute to the discussion.
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] On Behalf Of Volker Greimann
Sent: Thursday, June 01, 2017 12:09 PM
To: gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: [EXTERNAL] [gnso-rds-pdp-wg] The principle of consent
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/
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:(347)%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>
_______________________________________________
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>
_______________________________________________
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
--
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.
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170602/8548b49d/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list