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

Simon Poole simon at poole.ch
Wed Jun 20 18:54:13 UTC 2018


Just as a clarification:

- we do intend to have ToS for both the website and the API, that among
other things address privacy aspects (a 1st draft went out for comment
to the OSMF board and the WGs today, and if no major blockers are found
will be available for public comment rsn).

- I expect that access to the "raw" data including user data will only
be possible with a login and correspondingly agreeing to the ToU

- use of OSM data within the limits of the ToU will likely not cause any
privacy related issues, so the barrier of having an OSM account and
agreeing to the ToU would seem to be enough for the typical use of
contributors,

- use of the data as in say osmcha, Pascals services and so on, which
would not be covered by the ToU, does raise privacy issues and such
consumers/distributors of OSM data are expected to act as independent
controllers as already outlined. Essentially what we can offer as
support there is the already mentioned list of deleted accounts, and
providing all contributors with a list of data controllers to fulfil the
obligations in GDPR Art. 14.

As said some details still need to be worked out, so I wouldn't take it
as gospel right now.

Simon


Am 20.06.2018 um 20:16 schrieb Roland Olbricht:
> 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
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180620/4090cbef/attachment-0001.sig>


More information about the dev mailing list