[OSM-dev] GDPR implementation on planet.osm.org

Frederik Ramm frederik at remote.org
Wed Jun 20 07:03:01 UTC 2018


On 20.06.2018 07:58, Jochen Topf wrote:
>> 3a. issue guidelines about what you are allowed to do with the user data
>> files,
>> 3b. ensure that everyone who has an OSM account agrees to these
>> guidelines one way or the other,

> This is the part that's not easy and where there is a lot of important
> detail missing. You have to get everybody to agree, which is not going
> to happen.

I was thinking of simply blocking accounts from logging in until they
have agreed. Or more precisely, they would be able to log in, but only
to see the message telling them they need to "click here".

> You probably have to
> change rules in the future so you have to make this generic, keeping
> information about who clicked through which version of the rules. 

Unsure how useful that would be; would I not want to have everyone "on
the same page" at all times, i.e. having agreed to the same rules?

> So you
> are generating more information you are tracking with each user, more
> personal information for which you need consent from the user. 

As I said, I would simply block all accounts until they have agreed to
the rule. This is not just about being allowed to download data; someone
who edits OSM will also have access to the full user data through the
API and hence agreeing to the rules is a prerequisite for editing too.

> All of
> this needs to be tied in the OAuth stuff and it has to be done in a way
> that 3rd party services using OSM data can ask *their* downstream users
> to identify in the same way which allows OSM to track everybody who uses
> the full OSM data everywhere adding more personal data to keep and to
> explain to users and get permissions from users for.

No, there's a mistake in your reasoning here.

It is true that downstream data distributors like Overpass or the
Geofabrik downloads need to be able to verify whether someone has an OSM
account or not. Pascal has been doing that for ages on his HDYC site,
for example.

But downstream data distibutors do not need to know or store anything
more than that; the Geofabrik download server for example will not even
store the user name of the person who has logged in, just that "whoever
is here has just proven they have an OSM account". So the downstream
distributor can deal with this without processing any personal data. (It
would be possible to extend our OAuth system by a call that would not
even return the user's identity to the caller - currently the identity
is returned to the caller and the caller must then decide whether to
process it or not.)

On the OSM server side it is true that the server can know that "user X
has just gone through the OAuth process at <downstream site>". But
there's no reason why we would have to keep, store, or process this
information in any way. If we don't process the data then we don't have
to explain, and we don't have to get permission either.

(I don't see why it would be useful to store who has downloaded a full
planet file when.)

> Please stop this nonsense now!

The only alternatives I can see would be:

1. Stop distributing who-did-what-when information to everyone, period.
This is possible but it would create a privileged class inside OSM that
has access to this information, and it would harm the ability of the
community to do QA.

2. Take the view that distributing the data is what we do and tough
luck, you've signed up to it. The LWG has advised against that course of
action. Even if we were to get away with it, we would still have to stop
distributing someone's data once they protest (or at least restrict the
distribution of data), at which point you either have to implement the
whole stuff I outlined in my original post and ensure that some user
data is not publicly available, or (point 1 above) stop distributing
that one person's data altogether.

Given these alternatives, I think the course currently followed by the
OSMF is the least disruptive.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the dev mailing list