[db-wg] NWI-13 Geofeed Legal Analysis

Hi there,

Following others, this looks like a crazy situation. Reading the
discussions for a long time it looks like you are turning around since
months with contradictory actions and no clear convergence on the defined
purposes. Nothing personal but just my opinion reading your discussions
regularly.

I understand geofeeds may contain personal data but you manage the pointer
not the content as others said.  Personal information from geofeeds is not
collected nor processed.

Citing the answer from Maria "other geolocation information is already
provided in the RIPE Database (i.e. geoloc, country code attributes in ORG
and resource objects)", I am even more confused:

   - How can you guarantee a geoloc (latitude, longitude) is not personal
   information in that case? Following the recent discussions about the
   proposal to hide street addresses from the registry, this looks weird. A
   geoloc is entered by a user with no validation and nothing prevents people
   from putting coordinates to a location that identifies a real address
   (outside of this discussion, it's crazy to see geolocs pointing in the
   ocean, or maybe many subnets are in use on oil rigs...).

   - Is there really a consensus about what the country code in "resource
   objects" other than organizations mean?
   Citing your docs for inetnum object: "It has never been specified what
   this country represents. It could be the location of the head office of a
   multi-national company or where the server centre is based or the home of
   the End User. Therefore, it cannot be used in any reliable way to map IP
   addresses to countries.". Can we really consider this as geolocation
   information?

It's sad to see real solutions around geolocation (which helps users in
many ways) overthought and killed in the eggs.

Kind regards,
Laurent Pellegrino

On Thu, Jul 28, 2022 at 3:57 PM Gert Doering via db-wg <db-wg at ripe.net>
wrote:

> Hi,
>
> On Thu, Jul 28, 2022 at 01:33:07PM +0200, Maria Stafyla via db-wg wrote:
> > As mentioned in the Legal Review Impact Analysis, if the geofeed
> > attribute is inserted for registrations of assignments that are
> > reasonably assumed to be related to one individual user, then the
> > attribute will be considered as containing personal data and GDPR will
> > apply. This is why we have proposed to implement restrictions.
>
> I maintain that this part of the analysis is fundamentally flawed.
>
> The size of an assignment does not have any correlation to the entity
> that the prefix is assigned to - we can assign IPv4 /32s to corporate
> customers, and we can assign IPv4 /28s to private end users, and this
> is perfectly within the scope of the relevant RIPE policies.
>
> Inventing restrictions based on "but it looks like!!" guesswork is
> not what we are paying the RIPE NCC for.
>
> *Especially* as the information entered is not PII itself, but
> a pointer to a URL which could, as has been stated, contain anything
> from "ZZ" to very detailed addresses, fully under control and fully
> in the responsibility of the entity maintaining that list.
>
>
> I have the nagging suspicion that people are not listening here, because
> all this was already said months ago, and we're still running in circles.
>
> Gert Doering
>         -- totally not interested in geofeed:, but annoyed by arbitrary
>            restrictions not in line with RIPE policies
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20220728/2f6bb693/attachment.html>