I'll look at this, but I want to note that this is exactly the same situation as hotlinking an image, or loading a JavaScript library off a CDN - both extremely common things to do.

I would have assumed the website requesting the font/image/js is the IP that got shared, not the actual user of the website. I've learnt something new. Imagine getting a massive fine for not knowing that using a CDN was breaching GDPR. 100 euros was a slap on the wrist, but GDPR is serious business when it comes to how much they can fine you.

Yes, from what I read, what happened was the IP addresses of the users got shared to Google via the loading of Google Fonts. This sets a dangerous precedence though; there are many ways an IP address can be shared and technically violate the GDPR. The use of the StopForumSpam service, for example, could technically violate GDPR (though we mention it in the Privacy Policy so I wonder if that is legally covered). Or, Composr reporting errors to Chris if said errors happened to contain IP addresses in them. Unfortunately, if this is what the GDPR is going to enforce, then there might not be any other option than to comply. Although, I wonder if merely sticking this info in the Privacy Policy is good enough.

Adding the info to the Privacy Policy is probably a good thing to do. Currently the compo.sr website is not using cookie consent so google analytics and youtube cookies are flagged as problematic (in the EU) when checking compliance. Youtube flagged on "Business by Manoj Sree" theme in addons. Not sure about analytics but using the youtube-nocookie domain (also in galleries) would solve the latter without consent being needed.

Okay I've had a look at the ruling, as I wanted to know if it was an issue with IPs and/or referrers. It's just IPs.

"The unauthorized disclosure of the plaintiff's dynamic IP address by the defendant to Google constitutes a violation of the general right of personality in the form of the right to informational self-determination according to § 823 Para. 1 BGB," the ruling stated, as algorithmically translated. "The right to informational self-determination includes the right of the individual to disclose and determine the use of their personal data."

This is pretty absurd. An IP alone only identifies that some machine on a particular network was turned on at some time and went somewhere-unknown to request a common font. That's an incredible stretch of personally-identifying.

This judgement would block:
- hot linked images
- CDNs
- Any remote-hosted ad hosting platform
- Any remote-hosted analytics platform

If we were talking about referrers, that's another story. I can legitimately see why we would want to block referrers to Google Fonts and CDNs, as they have no business knowing it (actually we could consider Google Fonts a kind of CDN).
When it comes to hot linked images, or even outbound links, it becomes thorny. For privacy we could say no outbound link should pass a referrer, yet knowing referrers is very basic for digital marketing. It probably should be an option to block all referrers, on by default.

Thinking about this some more, it's extremely thorny.

We can use "referrerpolicy" to limit individual a/area/img/iframe/script/link elements to not send referrers.
However, referrerpolicy does not allow granular limits on video/source/audio/object/track/embed/input (https://github.com/w3c/webappsec-referrer-policy/issues/160)
We need fine-grained control really. We also need WYSIWYG to be able to set that control.
I think it'll be a while until everything catches up.

Looking at our code, we currently have non-bundled addons that hotlink to Google for data-map embeds (COUNTRIES_ON_MAP and PINS_ON_MAP templates), eBay and Amazon for embeds, Facebook embeds, and Twitter embeds.
In bundled, we have Google Translate for language editing, and Google Analytics. Also any kind of media system remote video embed, like YouTube.
All this stuff is potentially going to want to be able to check referrers for security reasons, and if it's not by HTTP it could be by JavaScript.

I have added referrerpolicy for Google Fonts. This solves the referrer issue for Google Fonts, but not the IP issue. I'm considering it a special case, and for v12 we may make a separate broader set of changes.

I have disabled tracking on YouTube and Vimeo embeds using their method to do so.

Changes potentially for v12...

Add to privacy policy if:
1) Google Fonts is enabled (explain IPs may be leaked)
2) Google Analytics is enabled (not just about cookies as it is now) (explain IPs and origins may be leaked)
3) Google Translate is enabled for translating (explain IPs and origins may be leaked)

Add new privacy policy section regarding embeds, and document the following embeds could leak visitor IPs and origins and tie users to a remote site's own cookies, and that's all outside our control (as JS code we are not directly prescribing is running):
1) YouTube video (new option to disable YouTube embeds, so privacy clause only shows if enabled)
2) Vimeo video (")
3) Facebook video (" - and disabled by default)
4) oEmbeds (list all domains oEmbed is enabled for, or omits clause if no oEmbed domains are listed)
5) Data maps/eBay/Amazon/Facebook/Twitter (if the relevant non-bundled addons installed)

New privacy option to turn on <meta name="referrer" content="same-origin" /> in the header easily to entirely block referrers that aren't explicitly inclusion-listed. On by default. Must clearly explain that partners cannot enable embed/API access from your server or track your outbound links based on referrer - unless you are individually marking things up to allow referrers, and that is not currently possible for videos/audio. Partners could implement tracking via tracking IDs on URLs, or where applicable via the JavaScript code they run. In any case any such tracking should be reported by manually adding it to your privacy policy.

Disable all embeds until Cookie Consent (or some replacement) is properly agreed to. Needs to be more than a yes/no now.
Other stuff discussed in the privacy policy may need to be disabled too if not agreed to. Case-by-case basis, as we can't just disable IP block checks.

#4914 talks about a new privacy tutorial. Document stuff discussed here there too.

I'm not sure if this is the same Cookie Consent that Silk Tide created originally but it claims to handle GDPR and ePrivacy https://www.cookieconsent.com/ - It doesn't allow the banner to only show in countries which require it (at least in the free version), but perhaps Tempcode could do that.

There is also https://cookieconsent.popupsmart.com/gdpr-cookie-consent/ which is free and allows a company logo and also what I assume is the older version (still claims GDPR compliance but offers more layout/theme options) @ https://cookieconsent.popupsmart.com/.

Another which is free @ https://tarteaucitron.io/en/ - easy to add services with autocomplete dropdown.

Just read that youtube-nocookie does set a cookie if a video is engaged with, but at least it isn't setting them if not.