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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
