To respect user privacy and comply with GDPR, use openstreetmap.de for Leaflet maps

A little more than a month to launch, perhaps this can get looked at?

Assigning to track lead.

As of 📌 Enable privacy app when applying Event recipe Active the map tiles are not loaded automatically, unless the user explicitly chooses to load them, or their privacy settings have been changed to load third-party content. To my thinking, that should address GDPR concerns, at the very least. Is this change still needed?

I think the more privacy, the better. Yes, there should be a protection until you add consent, but after that, your data will be stored on US servers and it may not have the privacy protection level as it is required on EU servers. Also I think the privacy policy needs to be a bit different in case you are providing data to companies outside EU (if I am not mistaken).

https://techgdpr.com/blog/server-location-gdpr/

Given this was already one in the prototype, I think it is a good idea for EU users, even that we are not speaking about some very rich data (mostly IP addresses, ...).

Thanks for fast replies from everyone. To respect user privacy, usage of external resources should be avoided or kept at a minimum, to avoid "Accept third-party" pop-ups as much as possible.

Drupal CMS should be as GDPR compliant by default as possible, and if openstreetmap.de tiles were used, EU-users would not need to consent to using a third-party service, as I understand it.

So I do think serving tiles from openstreetmap.de (Germany) would be better, than via openstreetmap.org+fastly.net (USA/Canada).

Adding https://techgdpr.com/blog/server-location-gdpr/ in Issue Summary, thanks @poker10 for sharing that link.

To be clear, Fast.ly is a global CDN, with a variety of Points of Presence within the EU as well as other parts of the world, so it still isn't clear to me why the assets need to originate only within the EU.

It's true that fastly.net can use servers from all over the world, USA-located servers were used, when I visited https://www.openstreetmap.org/ and checked with https://www.nslookup.io/

openstreetmap.org

IP address		Type	Hosted by	Location
104.21.88.66		IPv4	Cloudflare, Inc.	United States of America
172.67.173.161		IPv4	Cloudflare, Inc.	United States of America
2606:4700:3034::6815:5842	IPv6	Cloudflare, Inc.	United States of America
2606:4700:3030::ac43:ada1	IPv6	Cloudflare, Inc.	United States of America

https://www.nslookup.io/domains/openstreetmap.org/webservers/

fastly.net

IP address		Type	Hosted by	Location
151.101.1.6		IPv4	Fastly, Inc.	United States of America
151.101.65.6		IPv4	Fastly, Inc.	United States of America
151.101.129.6		IPv4	Fastly, Inc.	United States of America
151.101.193.6		IPv4	Fastly, Inc.	United States of America
2a04:4e42::262		IPv6	Fastly, Inc.	United States of America
2a04:4e42:200::262	IPv6	Fastly, Inc.	United States of America
2a04:4e42:400::262	IPv6	Fastly, Inc.	United States of America
2a04:4e42:600::262	IPv6	Fastly, Inc.	United States of America

https://www.nslookup.io/domains/fastly.net/webservers/

dualstack.n.sni.global.fastly.net

IP address		Type	Hosted by	Location
151.101.193.91		IPv4	Fastly, Inc.	United States of America
151.101.65.91		IPv4	Fastly, Inc.	United States of America
151.101.129.91		IPv4	Fastly, Inc.	United States of America
151.101.1.91		IPv4	Fastly, Inc.	United States of America
2a04:4e42:400::347	IPv6	Fastly, Inc.	United States of America
2a04:4e42:200::347	IPv6	Fastly, Inc.	United States of America
2a04:4e42:600::347	IPv6	Fastly, Inc.	United States of America
2a04:4e42::347		IPv6	Fastly, Inc.	United States of America

https://www.nslookup.io/domains/dualstack.n.sni.global.fastly.net/webser...

openstreetmap.de

IP address		Type	Hosted by		Location
138.201.247.34		IPv4	Hetzner Online GmbH	Germany
2a01:4f8:c17:ead7::1	IPv6	Hetzner Online GmbH	Germany

https://www.nslookup.io/domains/openstreetmap.de/webservers/

Asking the user for their consent to deliver external content (that's for videos, fonts, maps, etc.) is compliant with known legislations (including GDPR, CCPA, and others) and not only relevant in the EU but an emerging requirement in more territories around the globe.

Delivering external content from different locations might be an option, too. But it's less reliable, and would have to be provided by the leaflet module in this case. But I wouldn't put too much hope into that approach, as it could easily ruin e.g. caching, etc.

From the privacy track's point of view, we seem to have accomplished what's required for Drupal CMS 1.0 in the short term. There is a road map to improve the features, but as for maps (topic of the IS) I'd consider that fixed and suggest to mark this issue accordingly. Follow-ups for consent management should be created in the Klaro module's issue queue, and other improvements for privacy and data protection are probably best covered by the privacy track here in the Drupal CMS project.

I still do not understand, if there was openstreetmap.de in the prototype (which is for sure a better alternative from the privacy point of view for EU users), what was the reason to switch it to the fastly - is there any explanation? And why it is a problem switching it back?

Asking the user for their consent to deliver external content (that's for videos, fonts, maps, etc.) is compliant with known legislations (including GDPR, CCPA, and others) and not only relevant in the EU but an emerging requirement in more territories around the globe.

In general this is true, but the requirements to companies in EU / non-EU differs, so it is more convenient for users in EU to use EU based service. Unless there are any benefits, or huge amount of work needed for the switch, I personally do not see a reason to won't fix this. But maybe I am missing something? Thanks!

I still do not understand, if there was openstreetmap.de in the prototype (which is for sure a better alternative from the privacy point of view for EU users), what was the reason to switch it to the fastly - is there any explanation?

The simple explanation is that the Events recipe from the prototype was completely replaced by the one that @mandclu built. It wasn't "switched back to Fastly" on purpose.

This all arises from the simple fact that nothing in the prototype was ever intended to be permanent. Some aspects of it have made it into the product, but in general it is very different and that's okay.

I didn't check out CCPA before, so thanks for sharing @jurgenhaas. Great that there are consumer protecting initiatives world wide.

I acknowledge that my approach has been EU/GDPR-centric, but in light of the different requirements from region to region, adding https://www.drupal.org/project/leaflet_more_maps → could make sense, since US-based web sites can then select to use US-served openstreetmap.org/fastly.net tiles, while EU-sites can choose to use tiles served from openstreetmap.de in Germany. Even more geographically diverse based tile servers can be added along the way.

This would remove the need for a consent form for Leaflet maps, if I am not mistaken, and a better user experience.

For whatever my opinion's worth, removing the need for user consent before displaying a map would be a better, more seamless experience. So +1 for it.

@poker10 in #12

I still do not understand, if there was openstreetmap.de in the prototype (which is for sure a better alternative from the privacy point of view for EU users), what was the reason to switch it to the fastly - is there any explanation? And why it is a problem switching it back?

osm.de would be a great idea for a global product. It's osm.org now, but not fastly.

In general this is true, but the requirements to companies in EU / non-EU differs, so it is more convenient for users in EU to use EU based service. Unless there are any benefits, or huge amount of work needed for the switch, I personally do not see a reason to won't fix this. But maybe I am missing something? Thanks!

Again, we have to provide default settings for a global audience. We do have tasks on the roadmap to provide location specific recipes to tailor the setup for specific countries or regions. But Drupal CMS doesn't allow us to do that yet, since it doesn't determine the location yet. And also, after that, we need context specific recipe support, i.e. that different recipes will be applied depending upon the selected location.

@ressa in #14

US-based web sites can then select to use US-served openstreetmap.org/fastly.net tiles, while EU-sites can choose to use tiles served from openstreetmap.de in Germany

That's already possible today, that sites can individually (re-)configure themselves. What our recipes do is a reasonable and globally applicable default setting which has to be a best-match for everyone. As for location based default configuration, see my comment above.

This would remove the need for a consent form for Leaflet maps, if I am not mistaken, and a better user experience.

That's not agreed upon all legal advisors that we spoke to. It is strongly recommended to get the user's consent before transferring their PII to any third-party service. Especially but not limited to the fact that server locations can easily change without anyone noticing.

@jurgenhaas we are setting the timezone now from the browser since 📌 Figure out how to handle the site timezone Active was committed. Not sure if that helps with this.

But I do agree that we can't ship something that works by default in one region but not another. If we can't automate it, we could make a point of it in the user guide as a way for site owners to remove the consent requirement for maps?

@pameeela the timezone doesn't help much, we do need the location. We've touched on that several times and I understood that this would be something for post-release. In addition to the location we will then need some enhancement to the recipe system to apply some recipes depending on that location.

Yes, in the meantime we're preparing for the user guide. Initially we were hoping for tours, but as that will not be in 1.0 either, we have to document the fine tuning of privacy in the user guide. This for for disabling certain features as well as explaining how to go about certain local requirements that didn't make it into the global default. Is there an issue somewhere that lets us hook into for the user guide work?