Enable GDPR-conform user analyses and UID extraction

[SlowMo24]

Based on the advice given in https://wiki.openstreetmap.org/w/images/8/88/GDPR_Position_Paper.pdf ohsome limits its functionality by removing the UID from all data extraction endpoints and not exposing any user-based endpoints.

Use Case Description

For any user based calculation as well as any join between an ohsome-extract and user information the UID would be necessary.

Request Description

Add the UID to extracted data and enable the development of user based endpoints.

Additional Information

Since the decision to drop user information from public endpoints the legal restrictions have not changed (only been clarified?). For ohsome to be able to expose this information or endpoints there are the following options:

• Make it available internally and ensure users have agreed to the ToU
• Make it available publicly ensuring the user has agreed to the ToU by logging in with an OSM account
• Make it available publicly ensuring the user has agreed to the ToU by logging in with an (to be created) ohsome account (similar to ORS)

[SlowMo24]

related: #52 , GIScience/oshdb#349, GIScience/oshdb#170,

[SlowMo24]

see https://osmcha.org/api-docs/ for another example of how authentication could work

[tordans]

Looking at #303, I wonder what the status of this ticket is a few years after GDPR was introduced and based on the experience the OSM community has with the topic of usernames as personal data.

Or, to put it differently, what information would the ohsome-api expose that is not already available via the public OSM website right now? And, what is the actual risk to expose the public OSM username via the app? – To my understanding some individual (not a company…) would have to first complain and then later maybe sue the organization giving the data. If this where to happen, I would expect it to be OSMF that gets the complaint, first. Giving ohsome plenty of time to change the service. But even if it where ohsome, this would first be an inquiry, not a lawsuit. Again, giving ohsome plenty of time to change or shut down the service. — My take is: We learned a lot about how GDPR works and is handled in practice since it was introduced and I suggest to re-evaluate if some level of risk is acceptable for this project.

[tordans]

Looking at this from a different angle:

• It would always be possible to hash the the public user id in a way that does make it impossible to recreate the original value ("Hash with itself"). However, that would only allow for very abstract analysis and not be helpful for services like Allow charts like potm.osm.ch/superset/dashboard/31/ #303

• For all the ideas of a login, I wonder what the login actually does. Is it about mass scraping? Is it about a specific consent – but what consent would that be? Who does actually need to give the consent? Would a consent by the party that requests the information (the app/frontend) be sufficient?