[OSM-talk] GDPR introduction
osm-ml at michreichert.de
Tue Apr 17 17:37:19 UTC 2018
Am 2018-04-17 um 12:48 schrieb Simon Poole:
> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation>* will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
> The LWG has prepared a position paper on the matter that has been
> reviewed by data protection experts and in general the approach to not
> rely on explicit consent has been validated. It should be noted that
> while the paper outlines our approach, some of the details still need to
> be determined. In particular the future relationship with community and
> third party data consumers that utilize OSM meta-data and what will
> actually be dropped/made less accessible of the data listed in Appendix B.
> LWG GDPR Position Paper
> Please feel free to discuss on the talk page
> <https://wiki.openstreetmap.org/wiki/Talk:GDPR> or on this list.
I would like to thank you for your work and agree that the OSMF should
not ignore GDPR. I think that it is a huge step forwards in terms of
data protection in general.
*Controller vs. processor*
Chapter "Recommendations", section 3 (page 10) writes:
> Using the data for user and contribution profiling will either require a data
> processing agreement (and a similar agreement for research) or the the OSM
> data consumer needs to operate as an independent data controller (see
Does this mean that someone who runs a service to fight vandalism and
other bad edits has the choice to either sign a data processing
agreement with the OSMF or to work as independent data controller? I am
not sure because section 5 on the same page writes:
> Entities receiving full data (that is including metadata) are expected to operate as
> independent controllers.
Working as data processor has the disadvantage that the service provider
has to sign some piece of paper. On the other hand it provides safety
for them. If a service provider acts as data controller any OSM user can
ask him to delete his user data?
Users asking the service providers instead of the OSMF to delete their
data add addition hassle to the service provider and harm the
development of OSM:
- The service provider has to "filter" incoming data from OSM (diffs,
planet dump, …) to remove data they are not permitted to use.
- The community is unable to review edits of that user using the
third-party service because the user is not visible there. Users with
bad faith (they exist and I know a few examples) can use that to do
edits below the radar and make validation and reverts of their edits
That's why I would like to ask the OSMF to let service providers choose
their favourite legal model. If the service provider chooses to be a
data processor, he can redirect incoming request of deletion to the OSMF
and the OSMF has to delete the user and block his account. The latter
makes further validation of his edits mostly unnecessary.
Appendix B writes:
> It can be argued that completely removing timestamps causes a significant loss of
> functionality and information, for example when an object was last updated. This
> could be partially rectified by simply reducing the granularity of the timestamps in
> publicly available data, for example by only displaying dates.
Removing user names, user IDs and changesets from data dumps and general
API access does not really harm most usage of OSM. However, one change
might cause more trouble if it were seriously followed through – the
If you reduce their granularity to one day, it is still possible to
group edits in areas with a low density of mappers. I am not talking
about central Sahara, the poles or the Middle West of the U.S. I am
talking about almost all areas of Central and Western Europe except the
See the following picture of my master thesis
It shows the frequency of map edits in the north-east of Germany between
2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
imported the hourly diffs from OSM into my database. Dark blue means
that within more than one month, less than four diffs contained updates
for that area. You would have to reduce the granularity to a month to
make the recreation of changesets impossible!
Slide 15 of
shows the same for California. It is possible to group edits in the Bay
Area if the granularity is reduced to one day.
I agree that timestamps can be used to group edits but it is not
possible to group them properly and you still don't know who uploaded
the changeset. That's where personal information begins, isn't it?
If the OSMF reduces the granularity of timestamps, it also should stop
providing minutely, hourly and daily diffs to the public because they
still provide a granularity of one minute/hour/day.
Please let the timestamps as they are.
*Deletion of accounts*
I agree with the proposed solution. However, I remember of a few cases
when users requested the deletion of their account while their edits
have been discussed or criticized (depends on the viewpoint) by the
community and a revert was prepared or the community waited for the user
to answer some questions and decide about the revert afterwards. If
their accounts disappears for normal community members who want to
review or revert the edits, these members would have to ask DWG or OWG
for help. There are multiple possible solutions (some should be combined
with each other):
- Other contributors can request a delete lock, i.e. the account will be
visible for a grace period of about two weeks before it will be deleted.
- Deleted accounts are accessible for a certain timespan (e.g. one
month) to a wider audience of trustworthy and experienced mappers than
the current size of the DWG to reduce the workload of the DWG.
- We review the changesets of all users requesting deletion carefully
when they request deletion.
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
I prefer GPG encryption of emails. (does not apply on mailing lists)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the talk