Since everything your site does basically is defined as “collecting” or “tracking” it’s absurd to claim you can just simply “not do so”.
If Google tracks something, whether it is via their fonts, by putting some cookie on your site or whatever, it is their problem (and they actually said so, in that Github post referring to the font issue). They are the ones collecting and processing the data, not you, so they will have to deal with the GDPR compliance.
But what’s special about fonts? If I can’t reference an asset outside my own domain because the network request could allow the 3rd party to log an IP address, How is that not antithetical to the foundation of the WWW?
Besides the fact that this goes against the last decade of advice on how to speed up your site...
Is it really that unreasonable that loading a page to x.com should only load resources from x.com and 3rd-party resources compatible with X's privacy policy?
Seems like a contradiction, and exactly my point. Trying to collect privacy policies and compliance statements from any place you might load an <img> or <script> from is extraordinarily burdensome and pointless besides. Totally absurd over-reach IMO.
And what about the 25 hops in between you and them which also collect your IP and the domain being contacted?
If someone is going to have top-notch legal team on this it is going to be Google. So if Google's legal says that it is alright because they are the data processor/controller as defined by GDPR you can pretty much take them for the word there.
I wonder whether people spreading this sort of panicked disinformation about the fonts and what not have actually read the GDPR text. It is pretty clear about who is considered to be a "data processor" or "controller" - someone who merely uses a resource like fonts is certainly not one if you aren't collecting any information yourself or having someone else do it on your behalf. That Google may be doing it is irrelevant as long as they aren't providing the data to you (which would make you a "data controller").
And if you are neither a data controller nor data processor you aren't concerned by GDPR at all.
It is well explained here: https://www.gdpreu.org/the-regulation/key-concepts/data-cont...
This is a very good point, and to be fair you're absolutely right. The definition of user-tracking extends far beyond Google analytics, and if you're not fully informed about what 3rd-party services you're using on your own website, and the ramifications of those, this could present problems.
When I said "they can simply not do so", that assumes they are aware of what tracking they're doing, which may not be the case. If you're using some WordPress.com blog theme with CDN calls built in, you might have no idea. There may even be an argument for this falling to WordPress.com (in this example) as the provider of the themes.
Realistically, I don't predict CDN calls to turn out to be in violation of GDPR in practice, even though there's a very reasonable argument for them being that in theory.
I kind of half-hope they are though, as a user. I've never been a fan of their use, and use the uBlock and Decentraleyes add-ons personally to avoid them. I wouldn't be devastated if we returned to a norm of locally linked resources (especially with HTTP2 adoption), though that's probably just wishful thinking.
Of course, if you do, like in this forum example, you will have to do something, but that doesn't apply to all the information/blog/brochure sites using unnecessary tracking, etc. They can simply not do so.