Hi Simon, 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 > <https://wiki.openstreetmap.org/wiki/File:GDPR_Position_Paper.pdf> > > 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 > below).. 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 difficult. 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. *Timestamps* 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 timestamps. 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 https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png 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 http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf 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. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
