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

Roland Olbricht roland.olbricht at gmx.de
Wed Jun 20 18:16:50 UTC 2018


Hi,

brief and frank: The suggested way that users of Overpass API have to 
sign up as OSM users would cause a downtime of some months and a 
development backlog of more than a year, or kill the project entirely.
Because this sounds harsh, I will explain that further down.

The key point is: please do not bind information intended for data 
processors to OSM user accounts.

> The only alternatives I can see would be:
> 
> 1. Stop distributing who-did-what-when information
> [...] it would create a privileged class inside OSM
> [...] 2. Take the view that distributing the data is what we do and tough
> luck, you've signed up to it.

As Simon has pointed out there is another alternative. And I have 
understood so far the OSMF that way wanted to follow that way:

> as has been outlined before, 3rd parties using OSM data with user data
> will be acting as independent data controllers and will not be
> processing data on behalf of the OSMF (which would require a DPA and all
> the associated complications). They will have to make their own
> determinations on how to deal with the situation. We will  provide some
> support to such entities to help them fulfil their legal obligations
> (for example a list of deleted users), but that's it.

In particular, data processors do a much better job if they do not deal 
with OSM accounts at all, avoiding having and triggering extra 
who-viewed-what data.

Most important, privacy relevance varies heavily with context. Hence I 
will and should inform users about different risks than the OSMF, and 
HDYC may again decide to stress other aspects. A central ToU cannot do 
that. Also, for that reason the GDPR is a law and not a suggestion for a 
contract, and the OSMF decided to handle it as such.

To give an analogy, think of blades. It is forbidden by law to injure or 
kill someone, and blades of any kind do pose a risk. Kitchen knives can 
be used to stubb someone, but nobody every got stubbed with a kitchen 
blender. By contrast, user may harm themselves when using a kitchen 
blender. For that reason, you should be informed about the blades in the 
kitchen blender's manual, but no knife salesman in the world would 
require you to sign a contract not to stubb someone else with the knife. 
Conversely, giving too detailed information what approaches of stubbing 
are physologically risky and which are harmless could be abused as 
how-to-stub instructions.

Taking GDPR serious means every data processor must decide which use 
cases they make simple, which use cases they make hard, and tailor the 
documentation according to that. For example, for that reason Overpass 
API has no feature to track all actions of a single user. I have 
proposed a declaration tailored to Overpass API on the FOSSGIS list (the 
FOSSGIS is sponsoring the server operations), and I would prefer to go 
forward with that one. A central ToU does not help, hence having it 
ticked or not is of no interest to the data processor.

Then there is the problem that regardless whether you expect that OSM 
users will read or just tick the box, you have downsides:
- If you expect that users do read the ToU then we will scare away users 
that just signed up to fix a POI and find themselves scrolling through 
pages of legalese on a mobile phone
- If you do not expect that users read the ToU then the bad guys in 
particular won't do, and no judge ever would count that as an 
appropriate technical protection of data

In addition, this is stealing users' attention from more important 
matter. Our contributor terms have quite some content and that so for a 
reason.

On the technical side, things are even worse. The elephant in the room 
is OAuth. OAuth is built on in particular the assumptions that
- the consumer ("the website") acts stateful
- sessions are relatively long-lived, i.e. some seconds to some hours
- the identity provider has the cross-origin assets
All three are not true for Overpass API which means that I have to work 
around OAuth or significantly mess with it.

For example, implementing to have sessions on Overpass API will require 
to develop a full-fledged security system to deal with the hundres of 
potential modes of attacks on session based systms. Even if that works, 
the median runtime for a request on Overpass API is well below a second, 
and just the roundtrip times for the OAuth threesome communication sum 
up to more. We have not even started to talk about the plethora of error 
messages that need to be formulated, explained, and implemented.

On top of that, the OAuth idea means that each and every sequence of 
user data access will trigger an event on the central OSM OAuth server. 
This is quite Orwellian. Even if you do not store that information, your 
friendly agency of choice will do so on the line that connects the server.

Additionally, if you monitor "independend processors" so closely, it is 
questionable whether they are not seen as disguised contractors by a judge.

I can live with the requirement to do OAuth do download diffs, although 
it is substantial effort on its own.

But, please, if you want Overpass API in the future then please do not 
bind third party data delivery to OSM user accounts.

Best regards,

Roland



More information about the dev mailing list