Hi Shane,
These are very good points. Within the working group, we're still deciding on
the best path forward, and what I (and others in the NCSG) are advocating for is
to first decide if there is even a basis for collecting registration data. I
tend to think there is not, and the only reason WHOIS exists at the moment is
because of historical accidents left uncorrected because of endless contention.
At the moment WHOIS records are publicly accessible — there's no gated access,
let alone records kept on how frequently a particular record is viewed (though I
understand some registrars do voluntarily collect this information). If we do
decide that personally identifiable data must be collected, even if access is
restricted to law enforcement or similar parties, I would hope we could have
some transparency around who is accessing data, for what purposes, and which
records.
There are a few requirements flagged at the moment in the list to do with
knowing the purpose of why a record is queried, but I agree with you that we
should be asking for stronger audits and the timely publication of transparency
reports. I write this, of course, on the proviso that there even is a need to
collect personally identifiable information in the first place — which I do not
think is a given, and do not think should be happening.
So yes. I think this is something that Farell should be taking back to the
working group as of concern to one of our members :-)
Best wishes,
Ayden
On Wed, Jun 15, 2016 12:56 PM, Shane Kerr [log in to unmask] wrote:
Ayden,
I haven't gone through the (780) possible requirements - apologies.
Your mail sparked some thoughts that I mentioned earlier on-list, but
I'll bring up again.
----
One thing that I am curious about is whether there are requirements for
how access is delivered, as well as transparency and auditing of access
to data.
I am thinking of the case where a law-enforcement agency (LEA) gains
access to private data (like phone numbers). Ideally the LEA would have
to impose controls over who within the LEA has access to the data. For
example, it would be nice to know if a police officer was using RDS
data for extortion of stalking or the like - which can only be done if
the LEA has unique access credentials with strong authentication. I'm
not sure how this could be best made into a policy, but I think that it
is important (surely ICANN has experience with related
cross-organizational privacy restrictions from the registry/registrar
model).
Likewise, it would be good to know if an LEA (or anyone else) was
mining the data for mass-surveillance purposes or the like. While
registries may not be legally permitted to report such information,
there are good models that can be encouraged, such as:
https://en.wikipedia.org/wiki/Transparency_report
----
In a related topic, both registrars and registrants may want to know
when information about the registrant is accessed. (This is certainly
technologically possible. LinkedIn tells me how many people have looked
at my page when I log in.) As a registrant, I probably also want
context... if my basic data was shown 10 times in a month and my full
data was shown 2 times, is that less or more than average?
On the other hand, registrants may NOT want information stored about
access to their data, as any information that is stored can presumably
be accessed by LEA. That implies some sort of way for registrants and/or
registrars to specify preferences for the handling of meta-information
about who has accessed what records.
----
Again, sorry for not going through the possible requirements to see if
they are listed. I am being lazy and hoping that since you have put in
so much work on this that you will know roughly what is contained. ;)
Cheers,
--
Shane
At 2016-06-15 11:27:55 +0000
Ayden Férdeline <[log in to unmask]> wrote:
> One gap that I see among the (780) possible requirements is to do with under
> what conditions transfers of data to foreign jurisdictions is permitted.
> [CM-D30-R10] does talk about Privacy Shield and the transfer of data between
the
> US and EU, but it doesn't seem sufficient to me. Does anyone know of any
> resources we can turn to re: restrictions on the overseas transfer of
personally
> identifiable information? Would also be great if we had some case studies or
> costly judgements to include which make it clear that the data controller has
> legal liability for any breaches of privacy… I think we need to turn this
debate
> into one about $$$ and less about privacy rights, because to come up with a
> wishlist of so many pieces of data to collect (and we are not yet even looking
> to consolidate this - just to expand it even further) seems not only unwise,
but
> scandalously expensive. Particularly so if we go down the path of gated access
> and there are breaches - which there inevitably will be.
> - Ayden
>
>
> On Wed, Jun 15, 2016 10:06 AM, Farell FOLLY [log in to unmask] wrote:
> Dear all,
>
>
>
> In addition to my previous e-mail, I think it would be nice to recall a brief
> history about the next-gen RDS. You can either read this e-mail for brevity or
> download the attached presentation (from which I withdrew the information).
>
>
>
> 1. Why this PDP Working ?
>
>
>
> WHOIS was created in the 80s to identify & contact those responsible for
> operation of Internet network resources. After nearly 15 years of GNSO task
> forces, working groups, workshops, surveys & studies, the ICANN community has
> been unable to reach consensus on comprehensive WHOIS policy reforms. In
> response to the 2012 WHOIS Policy Review Team’s Final Report, the ICANN Board
> launched the RDS PDP & the Expert Working Group (EWG) to inform it The EWG was
> tasked with taking a fresh approach by redefining the purpose of gTLD
> registration data & then proposing a new model for gTLD Registration Directory
> Services to address accuracy, privacy & access issues.
>
>
>
> 2. What is WHOIS
>
>
>
> <<WHOIS is an overloaded term, it could mean:
>
> ü Registration data
>
> ü Access protocol (WHOIS protocol)
>
> ü Directory Service
>
> ü It is best to use individual terms
>
>
>
> It was created in 1982, but as the Internet grew, WHOIS began to serve the
needs
> of different stakeholders such as registrants, law enforcement, intellectual
> property & trademark owners, businesses & individual users - but the protocol
> remained largely unchanged. Through the Affirmation of Commitments (AOC),
ICANN
> is committed to “enforcing its existing policy relating to WHOIS, subject to
> applicable laws. Such existing policy requires that ICANN implement measures
to
> maintain timely, unrestricted & public access to accurate & complete WHOIS
> information, including registrant, technical, billing, & administrative
contact
> information.”>>
>
>
>
> 3. What is Next-Gen RDS
>
>
>
> << In 2012, the ICANN Board resolved to
>
> ü launch a new effort to redefine the purpose of collecting, maintaining, &
> providing access to gTLD registration data, & consider safeguards for
protecting
> data, as a foundation for a new gTLD policy & contractual negotiations, as
> appropriate
>
> ü Prepare an Issue Report on the purpose of collecting & maintaining gTLD
> registration data & on solutions to improve accuracy & access to gTLD
> registration data, as part of a Board-initiated GNSO PDP
>
> ü These efforts are collectively known as the: Next-Generation gTLD
Registration Directory Services to Replace WHOIS (Next-Gen
> RDS)>>
>
>
>
> This RDS is described by 180 principles and should address the following
> questions :
>
> i. Users & Purposes
>
> ii. Gated Access
>
> iii. Privacy & Data Protection
>
> iv. Data Quality
>
> v. Data Elements
>
> vi. Compliance & Accountability
>
> vii. Implementation Model
>
> viii. Cost
>
> ix. Risks & Benefits
>
>
>
>
>
>
>
> I hope this will help you understand more and stimulate your contribution.
>
>
>
>
>
> --ff--
>
> Best regards
>
> ------------------------------------------------------------------------------
>
> Farell FOLLY
>
> Africa 2.0 Foundation
>
> Chapter Head - Technology Champion
>
>
>
> t: +22997 248100
>
> s : Skype: farellf
>
> m: [log in to unmask]
>
> w :www.africa2point0.org
>
> l : www.linkedin.com/in/farellf
>
> tt : www.twitter.com/__f_f__
>
>
>
>
>
>
>
> -----Message d'origine-----
> De : NCSG-Discuss [mailto:[log in to unmask]] De la part de Farell
> FOLLY
> Envoyé : lundi 13 juin 2016 17:13
> À : [log in to unmask]
> Objet : Re: Request for additional “possible” requirements for Next Generation
> RDS
>
>
>
> (Sorry to have forwarded an unfinished e-mail, This is the final response)
>
>
>
> @Shane, and all
>
>
>
> The RDS PDP WG has the job to gather all “possible” requirements for the
> next-gen RDS to replace the WHOIS protocol. So many documents has been found
> useful / relevant to provide insightful issues to serve as inputs for the
> characteristics of the next-Gen RDS. However, WG found it impossible to read
all
> documents together as a team and agree on what can be a “possible” requirement
> and what can/should not be a requirement (one by one, document per document).
> Then it was proposed and adopted that group members volunteer to read the docs
> and extract as many as inputs as possible. Then the ICANN staff worked hard
and
> concatenated all these requirements by naming them appropriately without no
> change to the requirements themselves
>
>
>
> Therefore the word “possible” means that the stated requirement may be removed
> at the end of the current phase if it is judged so. However, it is not yet
time
> to make this decision.
>
>
>
> Consequently, if you find any bogus or meaningless information (according to
> you), please just make a comment to me offline and I will forward to the staff
> as necessary. At this stage, we just need to propose new “possible”
> requirements, so if you think you have a new requirement for the next-gen RDS
> that is not already in the RDS PDP list I previously sent (or by discarding
all
> inputs you classify as bogus or legalese), please send it/them through.
>
>
>
> Finally for other members I would to clarify that each requirement has been
> given a specific annotation in the form of [QQ-R#-D#], for instance in
> [UP-D26-R06] : the first two letters identify the associated charter question
> (Users Purposes, in this case), the D26 identifies the input document (Annex
A)
> from which the requirement has been extracted, and R06 means is the 6th
> “possible” requirement).
>
>
>
> I suggest to anyone in this group to read (in priority, iteratively) a
sub-list
> of all these “possible” requirements depending or based on his/her expertise
or
> background. For instance, If you have experience in data privacy, you can
> quickly check all “possible” requirements starting by [PR-Dxx-Ryy] and a new
one
> if any. For any new “possible” requirement, don’t forget to add the source
> document.
>
>
>
> --ff--
>
> Best regards
>
> ------------------------------------------------------------------------------
>
> Farell FOLLY
>
> Africa 2.0 Foundation
>
> Chapter Head - Technology Champion
>
>
>
> t: +22997 248100
>
> s : Skype: farellf
>
> m: [log in to unmask]
>
> w :www.africa2point0.org
>
> l : www.linkedin.com/in/farellf
>
> tt : www.twitter.com/__f_f__
>
>
>
>
>
>
>
> -----Message d'origine-----
>
> De : Shane Kerr [ mailto:[log in to unmask] ]
>
> Envoyé : lundi 13 juin 2016 15:37
>
> À : Farell FOLLY
>
> Cc : [log in to unmask]
>
> Objet : Re: Request for additional “possible” requirements for Next Generation
> RDS
>
>
>
> Farell,
>
>
>
> At 2016-06-13 11:30:10 +0100
>
> Farell FOLLY < [log in to unmask] > wrote:
>
>
>
> > Few months ago I decided to join the NCSG in order to serve and defend
>
> > the interest of the community regarding Internet resources use. Before
>
> > that, I started working with the GNSO Policy Development Process
>
> > Working Group (PDP
>
> > WG) to contribute in the development process of the Next Generation
>
> > Registration Directory Services (Next-Gen RDS). Time comes now that I
>
> > engage more and participate within this stakeholder Group. Therefore,
>
> > I volunteer to serve as a liaison/point of contact between NCSG and
>
> > GNSO PDP WG as far as the attached documents are concerned.
>
>
>
> Cool, thanks for this!
>
>
>
> > 1. Read the outreach message 2 in attach
>
> >
>
> > 2. Read and check the RDS PDP list of possible requirements, also in
>
> > attach
>
> >
>
> > 3. Reply to this mail by asking any questions to me or adding
>
> > additional requirement
>
> >
>
> > Please before replying to this e-mail to add a “new” requirement, make
>
> > sure you read the entire document and check whether this requirement
>
> > was not duplicated already. Also, ensure that you send your contact
>
> > details (name, first name, e-mail) if not explicitly included in your mail
> signature.
>
>
>
> [ Apologies if the following reads as a rant. It kind of is. Probably
>
> my own fault for looking at policy stuff. ]
>
>
>
> Is there a summary of the PDF, or any kind of specific issues that seem
> contentious that one would look at?
>
>
>
> I ask because the PDF alone is over 100 pages. Is this a typical ICANN
document?
> I was going to have a look since I'm somewhat technical and was involved with
> WHOIS in the distant past, but honestly I don't really have the many days time
> that would be necessary to make any sense out of this. :(
>
>
>
> ------
>
>
>
> I did skim a bit, and while parts of it are pretty clear:
>
>
>
> [UP-D01-R17] – Since it is likely that further [permissible
>
> purposes] will be identified over time, any [gTLD registration
>
> directory service] must be designed with extensibility in mind.
>
>
>
> (This is a bogus requirement, BTW. Without specific descriptions of the
expected
> changes then it is impossible to implement. It's like someone saying “prepare
> for the weather tomorrow” without telling you what the weather will be. Better
> to leave this out and let people make their own design decisions.)
>
>
>
> Other parts are complete legalese:
>
>
>
> [UP-D26-R06] – According to the Directive (30), whereas, in order
>
> to be lawful, the processing of personal data must in addition be
>
> carried out with the consent of the data subject or be necessary
>
> for the conclusion or performance of a contract binding on the data
>
> subject, or as a legal requirement, or for the performance of a
>
> task carried out in the public interest or in the exercise of
>
> official authority, or in the legitimate interests of a natural or
>
> legal person, provided that the interests or the rights and
>
> freedoms of the data subject are not overriding....subject to the
>
> provisions allowing a data subject to object to the processing of
>
> data regarding him, at no cost and without having to state his
>
>
>
>
> I mean, really, the last person to use “whereas” in English outside of legal
> on plain English suggests “because” or “since”, as does the “
www.plainlanguage.gov ” site, although in this particular case I'd say just
leave it out.)
>
>
>
> I don't even know what the requirement is here. I read it 4 times and can't
> figure it out. I feel sorry for the poor software engineer that has to try to
> convert this to running code. :P
>
>
>
> Given the many hundreds of possible requirements, many of which are written
like
> this, I don't see any way that anyone who has anything else to do for before
the
> deadline can possibly hope to help properly review this work, at least without
> some coordinated plan such as “please review the following 10 requirements”
for
> 50 volunteers.
>
>
>
> Sorry for ranting. :(
>
>
>
> Cheers,
>
>
>
> --
>
> Shane
>
>
> Ayden Férdeline Statement of Interest
Ayden Férdeline Statement of Interest
|
