[OSM-talk] GDPR introduction
simon at poole.ch
Tue Apr 17 18:56:12 UTC 2018
Am 17.04.2018 um 19:37 schrieb Michael Reichert:
> *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:
There are essentially 3 routes that we could take:
- not distribute meta-data to third parties at all (sure to be very
- a controller - data processor type arrangement. Besides the construct
being a bit contrived in our case, the typical data-processing
agreements I've seen are rather large legal monsters that are not going
to be easy on anybody, but we are not going to rule this completely out,
at this point in time-
- the entities processing the data are doing so on their own behalf and
are acting as independent controllers (which is more what is really
going on in any case)
>> 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.
A DPA is definitely not some piece of paper :-) (make that 10+)
> 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?
Well that depends on the reasoning the controller uses to document that
the processing of personal data is "lawful", as the data hasn't directly
been obtained from the data subject you will not be able to rely on
consent as a basis, but likely similar legitimate interests arguments
could be made as the OSMF will likely do (vandalism protection, QA, and
> 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
We intend to provide a list of "deleted users" or rather user ids so
this shouldn't be all to difficult, but the entities processing the data
will need to make their own determination on how to handle the deletions.
> 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
> metropolitan areas.
> 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.
The timestamps are simply flagged as potentially problematic, in the end
somebody will need to make a judgement call if we leave them in or do
> *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.
> Best regards
There is nothing in the GDPR stopping us from doing sensible things, in
particular there is no requirement that account deletion be immediate
(and as already said, there is only a direct right for deletion if the
lawful processing is based on consent).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the talk