Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not GDPR compliant due to including GoogleFonts #11648

Closed
wpaustria opened this issue Nov 8, 2018 · 17 comments
Closed

Not GDPR compliant due to including GoogleFonts #11648

wpaustria opened this issue Nov 8, 2018 · 17 comments

Comments

@wpaustria
Copy link

@wpaustria wpaustria commented Nov 8, 2018

Google Fonts in Gutenberg-Code

Legal Problem - GDPR

  • Due to the fact that Google Fonts are loaded directly from Google and there is no opting out in collection user data, Google Fonts are violating GDPR in most cases. This is due to the lack of given consent by the user.
  • There is no point in the GDPR where gFonts could fit in to be allowed. Google Fonts are not necessary for operating a website and are loaded upfront. Without the given consent of the user.
  • Therefore Gutenberg will be a legal issue in Europe!

Result

  • Everyone activating and offering Gutenberg will violate the GDPR.
  • So using WordPress with Gutenberg will be a legal risk.
@GlennMartin1
Copy link

@GlennMartin1 GlennMartin1 commented Nov 8, 2018

See conversation at google/fonts#1495

@mcsf
Copy link
Contributor

@mcsf mcsf commented Nov 9, 2018

This is on the radar of the WordPress Core Privacy team, who might be tracking it elsewhere. @allendav, should this issue here be closed in favour of some other one?

@allendav
Copy link

@allendav allendav commented Nov 14, 2018

I don't think using Google Fonts causes non-compliance, but IANAL. That said, the use of 3rd party fonts should be captured in WordPress core's privacy policy at a minimum.

It isn't immediately clear if this only impacts post editor users or also site visitors.

https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users

@aristath
Copy link
Member

@aristath aristath commented Nov 15, 2018

So far nobody knows what Google actually logs, for how long these logs are kept and how they are later used. There have been many inquiries but there is no official response that says "no we don't log IPs" or anything like that.
Most of us hope that using gfonts is OK, but tbh there's just no sufficient data to support either side.
I understand that Noto is a beautiful font and using it in the editor was a design decision, but it took us years to get rid of Open-Sans in the dashboard, and it was done for very good reasons.
Adding Noto now just adds more assets for users to download, we have no idea if there's a GDPR issue because there's just not enough data, and it ultimately just slows down loading times. That may not be an issue for you and I, but it's certainly an issue for people that are not blessed or privileged with fast connections.
If a theme uses a gfont, then it is the theme's responsibility to add that font in the editor. Otherwise there's no point in forcing an arbitrary font that will not be what is used on the frontend and Gutenberg should use system fonts.

@youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Feb 1, 2019

Unless, I'm wrong. I think the Core Privacy Team decided that it's ok to use Google Fonts before 5.0. If not let's open a trac ticket as this code is in Core now.

@youknowriad youknowriad closed this Feb 1, 2019
@mundschenk-at
Copy link

@mundschenk-at mundschenk-at commented Feb 1, 2019

Unless, I'm wrong. I think the Core Privacy Team decided that it's ok to use Google Fonts before 5.0. If not let's open a trac ticket as this code is in Core now.

As you are closing this issue, will you create the trac ticket? Doing nothing and then simply closing tickets seems a bit disingenuous to me. Why should there be a need for a third-party dependency in a self-hosted WordPress installation?

@mcsf
Copy link
Contributor

@mcsf mcsf commented Feb 1, 2019

Unless, I'm wrong. I think the Core Privacy Team decided that it's ok to use Google Fonts before 5.0. If not let's open a trac ticket as this code is in Core now.

As you are closing this issue, will you create the trac ticket? Doing nothing and then simply closing tickets seems a bit disingenuous to me. Why should there be a need for a third-party dependency in a self-hosted WordPress installation?

The point that @youknowriad is making is that the team in charge of assessing the GDPR-compliance of Gutenberg—and/or the rest of WP core—had approved the use of Google Fonts. That is grounds for considering this issue resolved, and it also means that any appeal of this decision should be made with the Core Privacy Team in a new issue. Moreover, since the code in question has landed in core WordPress as of WP 5.0, the Gutenberg repository is no longer the place for this discussion, but rather Core Trac.

In short, it shouldn't be seen as disingenuous that the issue isn't automatically opened in Core Trac, since opening that issue means appealing a previous decision. You are welcome to do it.

@mundschenk-at
Copy link

@mundschenk-at mundschenk-at commented Feb 1, 2019

Well, except I was there for that discussion in Slack and it wasn't at all like you describe. There simply was no consensus to demand immediate removal as a pre-requisite for merging (which would have probably been ignored anyway, but that's a different issue). Certainly no finding of "everything's hunky-dory".

@wpaustria
Copy link
Author

@wpaustria wpaustria commented Feb 1, 2019

FYI:
https://whotracks.me/trackers/google_fonts.html
Only as a humble hint.
So yes, google fonts are not GDPR compliant...
And still you cannot get a contract from google for using google fonts nor do they state anything in their rules of usage, what they do with the gathered data.
Clearly not GDPR compliant.

@garretthyder
Copy link
Contributor

@garretthyder garretthyder commented Feb 1, 2019

After a recent discussion in #core-privacy I've moved this issue to Core Trac as it not only has Privacy implications but also Performance;
Core Ticket - https://core.trac.wordpress.org/ticket/46169

Discussion - https://wordpress.slack.com/archives/C9695RJBW/p1549043771637800

@youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Feb 1, 2019

Thanks for the update @garrett-eclipse 👍

@tomjn
Copy link
Contributor

@tomjn tomjn commented Feb 9, 2019

Is it not worth making sure this isn't an issue in the plugin too? Privacy for all except those running the gutenberg plugin is still a problem

@mcsf
Copy link
Contributor

@mcsf mcsf commented Feb 11, 2019

Is it not worth making sure this isn't an issue in the plugin too? Privacy for all except those running the gutenberg plugin is still a problem

Absolutely, but I would defer to the decision-making process in Core. Once core-46169 resolves, which ever resolutions are effected in Core should be so in the plugin as well. Until then, this issue isn't actionable, which is a major criterion for all issues in the Gutenberg repository.

@garretthyder
Copy link
Contributor

@garretthyder garretthyder commented Feb 11, 2019

Thanks @tomjn & @mcsf
Definitely, the direction core takes here will set the precedent and I'll make sure to follow and update this thread with further information, potentially reopening when core is committed.

@wpaustria
Copy link
Author

@wpaustria wpaustria commented Apr 10, 2019

Für alle, die Interesse an der derzeitigen Rechtslage haben und auf dieses Ticket stoßen:
https://www.datenschutz.rlp.de/fileadmin/lfdi/Dokumente/Orientierungshilfen/OH_TMG.pdf

Kurz:
Einwilligung muss vorab passieren, bevor irgendwelche Daten weitergegeben werden.

@garretthyder
Copy link
Contributor

@garretthyder garretthyder commented Apr 13, 2019

FYI - I posted an update on the Core ticket here;
https://core.trac.wordpress.org/ticket/46169#comment:11

TLDR; Discussion via make/core points towards bundling fonts or system fonts. Once a discussion and decision is made by Gutenberg design lead(s) this should hopefully move forward.

@reserl
Copy link

@reserl reserl commented Jul 29, 2019

Update on the legal side of this topic, in short and English (german version below is a little bit more detailled)

  • You need the consent from the visitor bevor loading any remote assets. Upfront.
  • Any website owner is jointly liable for this consent.
  • The EuGH calls this "joint control".

GERMAN:
Mit dem Urteil vom 29.07.2019 (Az. C-40/17) hat der EuGH eine gemeinsame Verantwortung von Webseitenbetreibern und externen Verarbeitern (in dem Fall Facebook) bejaht.

  • Es gibt gemeinsame Verantwortlichkeit von Webseitenbetreibern und externen Dienstleistern (zb Facebook)
  • Ein Webseitenbetreiber, der den "Like-Button" einbindet, ist deshalb Joint Controller mit Facebook - aber nur für die Phasen des Erhebens und deren "Weitergabe".
  • Der EuGH weist vorab auf die Rechtsansicht der EU-Kommission hin, dass aufgrund der ePrivacy-Richtlinie nur die Einwilligung in Frage komme. Also keine Interessensabwegung.
  • Urteil fußt nicht auf DSGVO sondern noch auf der Datenschutzrichtlinie, ist aber natürlich auch für Auslegungen der DSGVO maßgebend.
  • Laut EuGH kann nur der Webseitenbetreiber eine wirksame Einwilligung einholen, da Facebook "erst zu einem späteren Zeitpunkt beteiligt ist".
  • Die Informationspflicht müsse "sofort" erfüllt werden, nicht erst nach Datenerhebung.
  • Es geht hier nicht nur um den FB-Like-Button, sondern um alle externen Ressourcen. Dazu Peter Hense, Rechtsanwalt und Leiter des Fachbereichs Technologie, Marketing und Datenschutzrecht bei Spirit Legal LLP:

„Eine Reduzierung auf den ‚Like-Button‘ und Facebook verstellt den Blick auf die Reichweite der Entscheidung. Es geht um jeden Schnipsel von Programmcode, den ein Seitenbetreiber auf seiner Website oder App einbindet...."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests