Make Starshot compliant from day one (GDPR in the EU, etc.)

[roromedia]

Please integrate all necessary modules to ensure that Starshot complies with the relevant laws in the EU and other jurisdictions. This includes adding a cookie disclaimer module and all relevant text to provide an out-of-the-box, turn-key solution.

[phenaproxima]

I love this idea, and we should ship it as a distinct recipe within Starshot. Which modules, in particular, are you thinking of? Can you submit a pull request?

[gitressa]

I agree that Starshot should be as GDPR-compliant, and privacy-respecting as possible. We can make it privacy-respecting by continuing to not use any unnecessary third-party resources, such as fonts, scripts, etc. I believe that Drupal 10 does not set any cookies for anonymous user, so we do not need to show any Cookie disclaimer-boxes for that.

Also, according to GDPR, you do not need consent to set an authentication cookie, used to log in a user:

How do you avoid cookie consent?

You can avoid the necessity of asking for cookie consent when you do not use cookies that track users’ personal data. Cookies necessary to a website’s operation are exempt from the need for consent.

From Cookie Consent Exemptions: Strictly Necessary Cookies.

If the GDPR-solution is an optional recipe inside Starshot, I see no harm, but I don't think it should be enabled by default. A simpler solution would be to just not use third-party-scripts, -fonts, -tracking etc., since it would make any GDPR-boxes redundant, while respecting user privacy.

PS. The three services fastly.net, openstreetmap.org, unpkg.com are contacted on the page /event/2024/nasas-boeing-crew-flight-test-launch where I think only openstreetmap.org may be needed?

[pameeela]

Living in Australia I am pretty clueless about GDPR but we do get asked about it occasionally. I was always curious about authentication cookies, but I am not sure it is exempt:

Persistent authentication cookies are not exempted under criterion B. It is because the users expect to end the session once they close the browser. On their next visit, they will expect that they are anonymous but because of persistent authentication cookies, they are still logged in to the services. A simple “remember me” checkbox would suffice in this case to obtain consent from the users.

By default, the Drupal auth cookie is persistent by this definition, so would we need to change that to remove the max lifetime? Or, add the checkbox to allow it, and make sure the cookie is cleared if the box is not checked. Or have I misinterpreted this?

[gitressa]

Maybe I shouldn't have linked to that site, because I am not sure that's correct ...

I have now read the https://gdpr.eu/cookies/ page more closely (it really only takes a few minutes) and it states the following:

Types of Cookies

Purpose

• Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site.

[...]

Cookie compliance

To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must:

• Receive users’ consent before you use any cookies except strictly necessary cookies.

I can't see that cookie life time is mentioned as a qualifier for requiring user consent ...

So, as I read it, a standard Drupal 10 installation is GDPR-compliant. Of course, if third-party-scripts, -fonts, -tracking, etc. are added by the user, a cookie consent pop-up is now also required.

PS. Ironically, gdpr.eu contacts these third-parties for fonts, scripts, tracking, etc.:

• facebook.net
• fontawesome.com
• fonts.googleapis.com
• jsdelivr.map.fastly.net
• cdn.jsdelivr.net
• jsdelivr.net
• sharethis.com

[gitressa]

As a more general observation, for higher security and privacy in Drupal, it would be awesome, if you could set authentication cookies to expire when the browser is closed, directly in Drupal core. There are modules such as Persistent Login, but cookies are so tightly connected to the inner workings of Drupal, that it's probably best done directly in Drupal core.

By default, the Drupal auth cookie is persistent by this definition, so would we need to change that to remove the max lifetime? Or, add the checkbox to allow it, and make sure the cookie is cleared if the box is not checked.

[roromedia]

The site mentioned is no official page by the EU but it tries to look very official - all official pages are under the "europa.eu"-domain.

Here are two official resources for general information by the European Commission and the European Data Protection Board in regards to GDPR and data security:
https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en
https://www.edpb.europa.eu/edpb_en

A very brief summary on what's needed:

For cookies it boils down to different types of cookies:

1. Cookies Requiring Consent (Non-Essential Cookies like marketing etc. or Analytical Cookies)
2. Cookies Not Requiring Consent (Essential Cookies for basic functioning of the website like shopping cart cookies, session cookies and Preference Cookies like language settings etc.)

Access to Third-party resources:
Furthermore Starshot needs to be compliant by not accessing third-party resources without user consent (eg. Webfonts, Captcha, CDNs outside the relevant legislation, etc.)

[gitressa]

Thanks for clarifying that, and the links @roromedia. Do you agree that a standard Drupal 10 installation is GDPR-compliant, and does not need a cookie consent? I ask because in the Issue Summary created by you, it says (relevant text made bold):

Please integrate all necessary modules to ensure that Starshot complies with the relevant laws in the EU and other jurisdictions. This includes adding a cookie disclaimer module and all relevant text to provide an out-of-the-box, turn-key solution.

If you agree that we can make Starshot GDPR-compliant and privacy-respecting by continuing to not use any unnecessary third-party resources, such as fonts, scripts, etc., perhaps the Issue Summary can be updated to reflect this?

[roromedia]

I had a brief look: Normal pages are fine, no cookies set, no third-party scripts. The content "NASA's Boeing Crew Flight Test Launch" features a Leaflet map which is embedded by unpkg.com which is powered by CloudFlare. A quick resolve of the IP I got when receiving leaflet.js showed an IP in the US - this is not allowed without prior consent.
My message regarding the "Cookie Disclaimer" was a bit misleading as the "Cookie Disclaimer" should not only handling cookies but should also take care of all consent in general (or at least should be the API to integrate custom consent solutions).
With this issue I also meant consent to third-party applications like leaflet.js but also to block embedded services like YouTube-iFrames (be aware that there are privacy-enhanced modes for Youtube like embedding with youtube-nocookie.com but this doesn't solve the problem of the third-party request involved in the iframe-src). iFrames should be implemented in a way that you can either give consent through the "Cookie-Disclaimer" but also, if you don't consent initially you should be able to unblock inidividual iframes manually. The basic way of doing this is to change the "src" attribute to "data-src" and then switch back upon consent.
Another quite recent topic is Google Analytics Consent Mode V2 - here the users consent should be transferred to Google Tag Manager and then via the Tag Manager the individual tags are fired or blocked.
To sum things up: From a Starshot-point of view I would refrain from any cookies and third-party requests so the initial install is GDPR-compliant. But if there is no proper module or plugin to easily enable compliance for tools like Google Analytics or Google Tag Manager it is in no way a viable contender to eg. Wordpress where you can install/buy a plugin like Borlabs Cookies and within a few clicks even more complex scenarios like iFrame-embeddings are fully covered.

[gitressa]

To fix the Leaflet challenge, I presented a solution in #81. As soon as it's implemented, the leaflet.js file will no longer be requested from unpkg.com.

For analytics, Matomo offers self-hosted, cookie-free statistics, or you can host at Matomo. For hosted, free and easy web analytics with no tracking of personal data, there's also GoatCounter.

Using Google Analytics in 2024 in an EU country seems like bad judgement to me, especially since France joined Austria in finding Google Analytics illegal.

For videos, Vimeo also offers GDPR-compliant video hosting, as does youtube-nocookie.com, like you mention.

From a Starshot-point of view I would refrain from any cookies and third-party requests so the initial install is GDPR-compliant.

Great that we agree.

But if there is no proper module or plugin to easily enable compliance for tools like Google Analytics or Google Tag Manager it is in no way a viable contender to eg. Wordpress where you can install/buy a plugin like Borlabs Cookies and within a few clicks even more complex scenarios like iFrame-embeddings are fully covered.

But there is, they can just install https://www.drupal.org/project/gdpr if they need it. Not every site needs this, so forcing it on all sites seems to me overkill ...

[roromedia]

Fixing leaflet.js this way is an excellent solution for addressing the GDPR during the initial installation. I also fully agree that Google Analytics is currently not a safe option for analytics, and alternative solutions like Matomo are preferred.

Regarding data protection, the Schrems II decision in 2020 rendered previous efforts like youtube-nocookie.com insufficient. Since then, IP addresses have been classified as "personal data," requiring adequate protection or upfront user consent before loading iframes.

Considering compliance, it heavily depends on the installed modules or recipes. The more I think about it a better approach might be to develop specific GDPR-compliance helper recipes alongside pre-installed common ones. For example, a "Blog" recipe might need a Cookie Disclaimer with third-party blocking if the blog embeds videos or transfers IP addresses to a third party outside the EU so there could be a "Blog GDPR" recipe or similar to accompany the Blog recipe. Same for Drupal Commerce where cookie consent might be needed. If someone eg. comes up with a Google Analytics or Tag Manager recipe there could be a recipe accompanying that as well.

[roromedia]

One more thing I have just seen in your link to #81 :

To fix the Leaflet challenge, I presented a solution in #81. As soon as it's implemented, the leaflet.js file will no longer be requested from unpkg.com.

There is still the map loading without user consent. The tiles of the OSM are loaded via fastly which is a US-based company and therefore this is not GDPR-compliant out of the box. It would be best to leave out the map altogether or implement a third-party blocking solution.

[phenaproxima]

Just to state the obvious: if someone can reconfigure Geofield+Leaflet to set up a nice map for the Event content type that "just works" without any additional setup or configuration, I will gladly merge that PR.

[gitressa]

Thanks for clarifying that the Schrems II decision in 2020 made consent required for youtube-nocookie.com as well, @roromedia.

Similarly, regarding IP addresses having been classified as "personal data", this includes also map tile services. I found Use Leaflet GDPR conform and after reading through it, I must eat humble pie and back-track, and admit that getting map tiles, even if it was only from openstreetmap.org (which it is not, Fastly are also involved) requires consent from the user.

There's the issue Add COOKiES submodule for leaflet GDPR, which looks like the best hope for an OSM solution.

About developing GDPR-recipes, that's a great idea! Individual web sites will have their own unique combination of services, and consent requirements. A suite of different solutions could be shared on the Recipes Cookbook page.

https://www.drupal.org/project/cookies has sub-modules for services, such as Matomo and Google Analytics, whereas the most popular GDPR cookie module https://www.drupal.org/project/eu_cookie_compliance has another approach, where the user can register blockable JavaScripts into a form to disable them. I can't see that either of them support blocking a third-party resource, such as map tiles or fonts, though ... So Add COOKiES submodule for leaflet GDPR could be our best bet.

@phenaproxima: Did you see that I documented how to set it up in #81?

[roromedia]

Thank you @gitressa for the detailed write-up on Leaflet and the community efforts on making it GDPR-compliant. Currently I am favouring COOKiES over eu_cookie_compliance, I like the usability of it and it is easily stylable. For third-party iFrame-blocking the COOKiES-module should have functionality integrated as stated here: https://www.drupal.org/project/cookies/issues/3225243#comment-14602076
We would need to test if it works with the Leaflet-map or if there is some customization needed to get it working via a recipe.

[gitressa]

You're welcome @roromedia, and it's great to hear that you have a positive impression of COOKiES, which also aligns well with the possible future Leaflet-support. I also see it as a quality assurance when @AnyBody and the rest of the DROWL.de team maintain a module, so it's perfect that the COOKiES module support iFrame-blocking.

[roromedia]

Agree, Anybody (@JPustkuchen) and the guys at DROWL.de are very committed and knowledgeable. As Germany (as well as Austria) had quite a lot of "Cease-and-desist letter / Warning notice" cases in recent years, companies and service providers got very aware of the GDPR and now all had to build up knowledge to be as compliant as needed.

[JPustkuchen]

Thanks for the positive feedback @roromedia :) We('ll) do what we can!
Sadly not much spare time currently, but we'll definitely try to help and especially ensure community isn't blocked somewhere in the COOKiES project.

BTW we were coming from the eu_cookie_compliance module that we used in Drupal 7 but had many issues with that, we COOKiES was the successor for us. Thanks to @jfeltkamp!

[pameeela]

Just posting the meta issue for the privacy work track here for further discussion: https://www.drupal.org/project/starshot/issues/3454549