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

Hi Cynthia

On Wed, 25 May 2022 at 12:17, Cynthia Revström <me at cynthia.re> wrote:
>
> 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.

A contact needs to be contactable. So I think verification on input is
an important part of defining a contact.

> 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.

I totally agree. Verification is to ensure you have initially entered
valid data that you have access to. This does not need to be an
ongoing process unless you change the data.

>
> > 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.

Then these legitimate use cases need to be defined as part of the
evolving purpose of the database over time. Whether it is personal
data subject to the GDPR or not, we still need to know what purposes
the database is being used for.

cheers
denis
proposal author

>
> -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://mailman.ripe.net/
> > > >
> > > > --
> > > >
> > > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
> >
> > --
> >
> > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/