[db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)

Hi Nick, Cynthia

On Wed, 25 May 2022 at 13:10, Nick Hilliard <nick at foobar.org> wrote:
>
> This came up quite a bit at the dbtf, where several of us came into the
> discussion with fingers on the throttle of their chain saws.

I can imagine...

>
> By the end of the TF discussions, there was a pretty sober realisation
> that it was not going to be trivial to get from where we are now, to
> where we might want to be at some point in the future.  There were a
> bunch of things that were clear, though:
>
> - many of the problems we see with person objects will recur with role
> objects.  Someone commented about this at the mic at the RIPE meeting
> last week, and we cannot look away from this reality.

There is a reality and a (shared) responsibility, the two are not the
same. Currently we have an object type defined as PERSON. It is
difficult to argue that this contains anything but personal data. The
RIPE NCC, as the data controller of the RIPE Database, is inviting
users of the database to enter personal data, even though in almost
all cases it is not necessary for the purposes of the database. Much
of the documentation for the database and the RIPE NCC procedures
promote or encourage the entering of personal data. I am not a lawyer,
but I am sure this puts some responsibility onto the RIPE NCC for the
personal data contained in the RIPE Database as they have facilitated
it, invited it and promoted it.

Now we need to turn this around. Putting aside for the moment the
issue of resource holders who are natural persons, which we will
consider separately. We need to relieve the RIPE NCC of any
responsibility for entering personal data into the RIPE Database and
put this responsibility for entering unnecessary personal data fully
onto the shoulders of the resource holders who enter the data. By
having a formal policy that clearly states that personal data 'must
not' be entered into the RIPE Database where it is not necessary and
adjusting all documentation and procedures to promote 'not' entering
personal data into the database, we take the RIPE NCC as data
controller and database facilitator out of the firing line for
responsibility over personal data.

If a resource holder ignores the formal policy that they are
contractually obliged to follow, the documentation, all procedures and
trainings on using the RIPE Database and still enters personal data
into ROLE objects which is not necessary for the purposes of the
database then the responsibility of any consequences rest with the
resource holder.

Suppose I enter my home address and phone number into my facebook
account and have it open to the public and suffer some consequences as
a result of that. If I try to take action against facebook I am sure
they will point me to some terms & conditions or acceptance agreement
or user policy that clearly states or recommends or advises me not to
do that. The responsibility of any consequences will be mine for
entering that data against the policy, not facebook's responsibility.

>
> - setting a long term strategic object is fine, but it needs to be
> realistic, and part of that assessment needs to include a migration path
> from here to there.  If the migration path is too steep or too
> extensive, then the migration will fail.

Yes I agree we do need to have the long term strategic goal in place.
We have to know where we are heading for, even if we understand it may
be a long and difficult path to get there. It may be steep or it may
be extensive or it may take a number of years, but as long as it is
possible it needs to be in place. As you know I do have a deep
understanding of the internals of the database and it's operation. I
did write some additional information covering many elements of
migration. It was considered too technical to be a part of the policy
proposal. I am happy to publish and discuss this in a separate thread
if anyone thinks it would be useful at this stage.

>
> - it would be important not throw the baby out with the bath water
>
> I.e. gut feeling => probably better to pick away incrementally at this
> issue rather than attempting to do a wholesale data reorientation /
> translation project which would likely leave the db in worse shape than
> before.

To some extent I disagree with this. We need a policy in place
defining the destination. We know it is achievable even if it is a
long and difficult path. The migration can be done incrementally so
long as we know the direction.

>
> As Daniel said at one point, if this were an easy problem to solve,
> someone would have already tackled it.

Daniel also said it is time to stop tinkering around the edges and
address the major problems :)

cheers
denis
proposal author

>
> Nick
>
> Cynthia Revström via db-wg wrote on 25/05/2022 11:17:
> > Hi denis,
> >
> > I agree with your summary for the most part although I think that
> > if/how verification is done for contact details is slightly outside
> > the scope of the summary of what a contact is.
> > For what it's worth I do think it is probably a good idea to do
> > verification for e-mail addresses, maybe not recurring like for abuse
> > contacts but at least when the email address is set/changed.
> >
> >> Contacts listed for any other reasons should be removed.
> >
> > With regards to this I do think that there might be legitimate use
> > cases that I just can't think of currently or that currently don't
> > exist but may exist in the future.
> >
> > -Cynthia
> >
> > On Tue, May 24, 2022 at 5:02 PM denis walker via db-wg <db-wg at ripe.net> wrote:
> >>
> >> Colleagues
> >>
> >> I received quite a lot of feedback at RIPE 84 on this policy proposal.
> >> This was mainly on two aspects, resource holders name and address and
> >> contacts. I will start with a summary of the views on contacts as this
> >> is the easier one to deal with.
> >>
> >> Contacts are listed in the RIPE Database to resolve issues. Currently
> >> these are technical, administrative, abuse, routing and DNS issues.
> >> They can also be listed for external services like RIPE Atlas and
> >> IRTs. Other issues or services may be added in the future. Contacts
> >> should only exist in the database if they are relevant to one of these
> >> defined reasons. Contacts listed for any other reasons should be
> >> removed.
> >>
> >> A contact needs to be contactable. The whole RIPE philosophy is built
> >> around email. So every listed contact must have a mandatory and
> >> working email address. This should be verified on entry into the
> >> database.
> >>
> >> Any other means of contact should be optional. These other means may
> >> have dedicated attributes like phone and fax. Or they can be added via
> >> remarks to include, for example, a URL for a web form, irc, a facebook
> >> group, or any other social media. Any of these other means may have
> >> dedicated attributes added if there is sufficient interest. These
> >> other means should also be verified on entry into the database, where
> >> technically possible.
> >>
> >> Contacts are for resolving immediate issues. They are not for
> >> receiving legal notices or arranging site visits. An address is
> >> therefore not needed and should be deprecated from any form of
> >> contact.
> >>
> >> Identifiable individuals are not needed for the defined purposes of
> >> contacts. All contacts should therefore be defined as business roles
> >> and only contain non personal data.
> >>
> >> Does this sound like a reasonable summary of contact details?
> >>
> >> cheers
> >> denis
> >> proposal author
> >>
> >> On Tue, 17 May 2022 at 11:03, denis walker <ripedenis at gmail.com> wrote:
> >>>
> >>> Hi Cynthia and Peter
> >>>
> >>> You both raise some interesting points and I will address them all in
> >>> one email. Let's start with 'why' do we publish the name and address
> >>> of resource holders. The RIPE Database is one of a set of 5 databases
> >>> that collectively document the registration of all global internet
> >>> resources. This is to offer to the public an open source of the 'who'
> >>> is using internet resources. Only by offering this information openly
> >>> can we have accountability at all levels of society. If this
> >>> information is closed with restricted access then accountability can
> >>> only be judged and enforced by lawful authorities.
> >>>
> >>> So let's look in more detail at the consequences of open vs closed
> >>> data. This only applies to the name and address details of resource
> >>> holders who are natural persons as well as end users operating public
> >>> networks with assignments. No other personal data should even be
> >>> considered in this database.
> >>>
> >>> In an open system the names and addresses of all internet resource
> >>> holders and public network operators are published. In an ideal world
> >>> all this data will be verified and accurate. This makes it easy for
> >>> anyone who is following up on criminal activity or abuse on the
> >>> internet to look up who is using a particular (block of) addresses.
> >>> This is not only LEAs. Private organisations and individuals can also
> >>> follow up abuse and take civil actions against the abusers.
> >>>
> >>> In a closed system we don't publish names or addresses of natural
> >>> people. The information will be held by the RIPE NCC or a member or a
> >>> sub allocation holder, or ... This gives maximum privacy protection
> >>> for natural persons, but causes problems for anyone trying to address
> >>> criminal activities or abuse on the internet. This arrangement can be
> >>> further manipulated by the bad actors to hide their tracks. Suppose a
> >>> natural person in country A becomes a member. Their details are not
> >>> published. They sub-allocate to a natural person in country B who
> >>> assigns to a natural person in country C. None of their details are
> >>> published. If this assignee is an abuser, an LEA, or other
> >>> organisation, has to get a court order in the Netherlands to get the
> >>> details of the resource holder in country A from the RIPE NCC. Then
> >>> they need a court order in country A to get the details of the sub
> >>> allocation holder. Then they need a court order in country B to get
> >>> the details of the assignee. If we go down this closed system route we
> >>> may have to look at who has a right to this information (which is
> >>> currently public) and how....but that is outside the scope of this
> >>> policy proposal.
> >>>
> >>> Another option, where a resource holder is a natural person, is to
> >>> 'require' them to have an official, legal address such as an
> >>> accountant or lawyer office, with their consent to publish that (non
> >>> personal) address.
> >>>
> >>> Having a simple rule like 'we don't publish names or addresses of
> >>> natural persons' is easier to apply and less error prone. But we are
> >>> turning the RIPE Database into more like a domain registry where lots
> >>> of details are hidden from public view. Does this affect the
> >>> usefulness of the RIPE Database as a public registry?
> >>>
> >>> I think it is a good idea to extend the scope of this policy to
> >>> include anywhere that the RIPE NCC publishes personal details of
> >>> members. So it would include the web pages where members are listed.
> >>>
> >>> cheers
> >>> denis
> >>>
> >>> On Fri, 13 May 2022 at 00:56, Cynthia Revström via db-wg <db-wg at ripe.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I am generally in support of this policy, however I do wonder why
> >>>> publish legal names of individuals in the cases of natural persons
> >>>> holding resources?
> >>>>
> >>>> Like why can't it just be some alias and the real name needs to be
> >>>> requested from the RIPE NCC by court order or whatever would be
> >>>> required for physical addresses under this proposal.
> >>>>
> >>>> While my name is a bad example, there are plenty of names that are
> >>>> extremely common, and if all that is published is the name and
> >>>> country, is it really all that useful?
> >>>> It is not like knowing that it is someone in the United States with
> >>>> the name "Joe Smith" is particularly useful on its own to know who it
> >>>> is.
> >>>> But on the other hand in such cases it is not a big privacy problem I suppose.
> >>>>
> >>>> However with a name like mine it is a privacy concern as my name is
> >>>> not exactly common.
> >>>>
> >>>> I would like to hear what the reason would be for requiring this to be
> >>>> published if it is either kinda pointless information or still a big
> >>>> privacy issue.
> >>>>
> >>>> Also I have a kinda Sweden-specific question about the following part
> >>>> (from 1.0 Organisations):
> >>>>> personal address for the organisation which is already in the public domain in a national, public, business registry.
> >>>>
> >>>> In Sweden there are multiple private organizations that publish home
> >>>> addresses for almost everyone in the country by combining some quirks
> >>>> of the freedom of the press act and government transparency.
> >>>> Would this count according to that, and as such would you say it is
> >>>> okay to publish the personal addresses for almost everyone in Sweden?
> >>>> The government doesn't directly publish this information, people have
> >>>> no right to demand to be excluded but it is still public.
> >>>> The important thing here though imo is that these websites generally
> >>>> are a lot harder to scrape than the RIPE Database.
> >>>>
> >>>> Also what if it was an address that was kinda public but you had to
> >>>> create an account and agree to not re-publish it elsewhere, would that
> >>>> make it okay or not okay to publish?
> >>>> Or what if that address is published somewhere, but not linked to that
> >>>> person's name, maybe it is linked to some unrelated legal entity that
> >>>> is on the same address, would that make it okay to publish?
> >>>>
> >>>> I think it would be a lot easier to just say that personal addresses
> >>>> should never be published.
> >>>> Just because it is already somewhere on the internet doesn't mean that
> >>>> the RIPE Database has to spread it further.
> >>>>
> >>>> -Cynthia
> >>>>
> >>>> On Tue, May 10, 2022 at 11:29 AM Angela Dall'Ara via db-wg
> >>>> <db-wg at ripe.net> wrote:
> >>>>>
> >>>>> Dear colleagues,
> >>>>>
> >>>>> A new RIPE Policy proposal, 2022-01, "Personal Data in the RIPE Database"
> >>>>> is now available for discussion.
> >>>>>
> >>>>> The goal of this proposal is to allow the publication of verified Personal Data in the RIPE Database only when they are justified by its purpose.
> >>>>>
> >>>>> You can find the full proposal at:
> >>>>> https://www.ripe.net/participate/policies/proposals/2022-01
> >>>>>
> >>>>> As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase
> >>>>> is to discuss the proposal and provide feedback to the proposer.
> >>>>>
> >>>>> At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
> >>>>>
> >>>>> The PDP document can be found at:
> >>>>> https://www.ripe.net/publications/docs/ripe-710
> >>>>>
> >>>>> We encourage you to review this proposal and send your comments to
> >>>>> db-wg at ripe.net  before 8 June 2022.
> >>>>>
> >>>>>
> >>>>> Kind regards,
> >>>>>
> >>>>> Angela Dall'Ara
> >>>>> Policy Officer
> >>>>> RIPE NCC
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
> >>>>
> >>>> --
> >>>>
> >>>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
> >>
> >> --
> >>
> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
> >