# Currently not GDPR compliant - reason external fonts #739

Closed
opened this issue Mar 19, 2018 · 32 comments
Closed

# Currently not GDPR compliant - reason external fonts#739

opened this issue Mar 19, 2018 · 32 comments
Labels

## Description

As in EU the GDPR starts to be active from May 25th on. It would be good if all external fonts and services are part of the bundle and do not link to the CDN version. Otherwise we have to display a cookie consent and a privacy policy for a "documentation".

### Expected behavior

Please include the Material Icons and Roboto Font directly (and other external services) into the bundle at least everything which is needed for the default material theme.
Currently it is not GDPR compliant how it is right now.

### Steps to reproduce the bug

In the Base.html (maybe in other files as well) from the material design there are links to the CDN services.

### squidfunk commented Mar 19, 2018 • edited

 I'm a European citizen and highly critize the EU for issueing such a half-baked law. It will cost companies millions in implementation and legal fees. It's impractical to host everything by yourself. Is it even allowed to self-host Google Fonts per their license? Don't really know if I want to take any action here.

### DsrMedia commented Mar 20, 2018

 @wopian yes thats true, they are not using cookie, but they get the IP-address from the user. But the font awesome icons are setting a cookie, as there are hosted on cloudflare (partials/social.html). @squidfunk Yes I aggree, but still as company we have to deal with it as it is. For our side we adapted the base.html and the social.html and downloaded the necessary fonts to the assets folder.

### squidfunk commented Mar 20, 2018

 @DsrMedia: I totally understand. However, self-hosting all assets would mean we would need to keep everything in sync. Also when self-hosting Google Fonts we may loose rendering quality because Google's CDN serves distinct files for Windows and macOS for optimization reasons. You can disable Google Fonts entirely as described in the getting started guide. We could host FontAwesome by ourselves, as it's pinned to a specific version and upgrading to 5 would mean a major release of the theme because class names / qualifiers changed. Would that help?

### squidfunk commented Mar 20, 2018

 Oh and we would loose the ability to easily change the font face per configuration or would have to bundle all fonts.

### nikramakrishnan commented Mar 21, 2018 • edited

 Edit: This is not legal advice, and does not mean you can continue using Google Fonts in your project. I did some research and found a few links to point that it should not be a problem to use Google Fonts even after GDPR takes effect. Google Fonts FAQ Section on Privacy Discussion on GDPR Compliance on the Google Fonts GitHub Repository Google GDPR Compliance Notice I strongly believe that we should continue using Google Fonts, because it offers fast content distribution and optimizations as mentioned by @squidfunk Google should be releasing a statement of compliance soon.
added the label Mar 21, 2018

### squidfunk commented Apr 2, 2018

 Yes, we will definitely be using Google Fonts at least until May 25, and then reconsider how we use/advertise it depending on the statement of compliance Google will hopefully be issuing soon. I will close this issue for now because there's nothing that can be done right at the moment. Furthermore, Google Fonts can be disabled easily by setting the following parameter in mkdocs.yml: theme: font: false
closed this Apr 2, 2018
mentioned this issue May 9, 2018
mentioned this issue May 14, 2018
Closed

### justjanne commented May 31, 2018

 @squidfunk Considering your completely immature response to this, which leaves users up to liability, I am very disappointed in this project. For my own use cases I have now created a fork that does not use Google Fonts.

### squidfunk commented May 31, 2018

 @squidfunk Considering your completely immature response to this, which leaves users up to liability, I am very disappointed in this project. If you mean my initial reaction: I think GDPR is great in theory but is an entire gray area as there are no official judgments or guidelines what is okay and what is not. If you mean my intention to wait until it's clear what to do I cannot understand your anger. Google Fonts can be easily disabled and replaced by self hosted fonts (see my last comment) and there's definitely a plan to include FontAwesome into the distribution files (but that's only CSS, so probably not as critical as Google Analytics).

### justjanne commented May 31, 2018

 @squidfunk I mean your entire attitude towards a privacy and legal issue, which is "I don’t care". Completely disregarding the users that are affected by it. I can’t trust a project that might end up sending user’s data to who-knows-where because "it can be easily disabled and replaced".

### squidfunk commented May 31, 2018

 Okay, I see your point. Actually it's not that I don't care, I'm very aware of the issue. The problem is that many people are using Material and the changes that we discussed would have quite an impact. My aim is to keep things as stable and constant as possible. For this reason we decided to settle until we know how to implement this with maximum compatibility and optimal usability. I'm very concerned about usability. Could you make a constructive proposal how we could comply with GDPR and keep Material easy to use? Also, is Google Fonts not GDPR compliant? Did someone have the time to study this topic?

### squidfunk commented May 31, 2018

 I think we should issue a statement in the docs on GDPR compliance of Material and how to achieve it.

### squidfunk commented May 31, 2018

 Thanks! What about if we include the default Roboto font family with the Material distribution, so by default Material would not query the Google Fonts CDN. If the fonts are set via mkdocs.yml, we would link to Google Fonts and add an Admonition to the docs that this possibly breaks GDPR compliance. Font Awesome will be directly included. This way all external dependencies could be eliminated by default and the UX would stay the same. Any thoughts?

### nikramakrishnan commented May 31, 2018

 I believe this is what we should do till Google and other providers clear the issue. Can the font parameter be programmed to enable/disable CDN for Font Awesome, too? There may be developers who may decide not to disable CDN, for faster loading.

### justjanne commented May 31, 2018

 That would be appreciated, yes. For now I’ve taken down my sites that use this until the issue is resolved. (But I’d want to keep an option to stick with entirely self-hosted everything even if Google sorts this out, and especially without any analytics or tracking).

### squidfunk commented May 31, 2018

 Can the font parameter be programmed to enable/disable CDN for Font Awesome, too? There may be developers who may decide not to disable CDN, for faster loading. That makes it more complicated so I would favor always including it. However, you could always override the theme.

### squidfunk commented May 31, 2018

 @justjanne: just disable Google Fonts and you are fine! No need to take it down.
reopened this May 31, 2018

### justjanne commented May 31, 2018 • edited

 @squidfunk If I disable Google Fonts, all icons will be missing and more. I already am running a heavily modified version here so I can get KaTeX support (instead of MathJax – ideally I’d even be able to get KaTeX at build time, but that’s a bit more work), and so I can change a few other minor details (e.g. making the icon at the top of the docs link back to the main site of the project instead of the docs home) So, I’ve taken it all down for now, and then I’ll wait until the fix, merge it into my version, and run that.

### Omeryl commented May 31, 2018

 Wouldn't having the information be available, albeit not pretty, be much preferred to unavailable completely? @justjanne

### squidfunk commented Jun 2, 2018

 My current plan to ensure GDPR compliance is the following: Bundle Material Icons with Material for self-hosting by default - Bundle Font Awesome 4 by default (upgrade to version 5 is another task) - Bundle Roboto 400 and 700, as well as Roboto Mono 400 with theme This should ensure GDPR compliance for the default configuration - meaning no custom fonts, no analytics – no third-party at all. I will also add documentation for this. If the user changes the fonts, Google Fonts will be used. This will also be noted in the docs. This will make the following option obsolete: theme: font: false  It will be deprecated with 3.0, as no fonts are loaded by default. Any thoughts?

### vbd commented Jun 5, 2018

 I think it would also be helpful to briefly explain how to include other fonts without using google fonts.

### squidfunk commented Jun 10, 2018 • edited

 So this is turning out harder than I thought. The problem is the way Google Fonts serves web fonts - they analyze the user agent and serve the ideal compatible web font format. For each requested font weight they serve 7 font face definitions for different charsets, e.g. latin, cyryllic, etc: /* cyrillic-ext */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xFIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F; } /* cyrillic */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xMIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116; } /* greek-ext */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xEIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+1F00-1FFF; } /* greek */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xLIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+0370-03FF; } /* vietnamese */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xHIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+0102-0103, U+0110-0111, U+1EA0-1EF9, U+20AB; } /* latin-ext */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xGIzIXKMnyrYk.woff2) format('woff2'); unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF; } /* latin */ @font-face { font-family: 'Roboto'; font-style: italic; font-weight: 400; src: local('Roboto Italic'), local('Roboto-Italic'), url(https://fonts.gstatic.com/s/roboto/v18/KFOkCnqEu92Fr1Mu51xIIzIXKMny.woff2) format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } As Material is a theme used in many different languages, we cannot possibly exclude any of the definitions. This means that for each weight, we would need to include 7 font face definitions. Additionally, this is only woff2 format - we would also need to serve woff and ttf at least (possibly eot if we want to support older IEs, but let's just forget about that). Material currently loads the weights 300, 400, 400i, 700 for Roboto and 400 for Roboto Mono, so 5 web fonts in total. The total amount of webfonts to be bundled with Material is: 5 (weights) x 7 (charsets) x 3 (formats) = 105 web font files. Impractical. I don't really know how we should proceed. I'm currently thinking of dropping Roboto for the default configuration (however still to be enabled via mkdocs.yml to use Google Fonts) and fall back to Helvetica or the respective system font. This would make Material GDPR compliant in its default configuration and still leave the possibility to use webfonts. Personally, I think, from a user perspective, it may be better to leave the Google Font loading as-is (to be disabled via theme.font: false) and bundle all icons fonts. This way GDPR compliance can be ensured with a single line, but the default user experience is not crippled as it would with falling back to system fonts. Any thoughts?

### squidfunk commented Jun 10, 2018

I think it would also be helpful to briefly explain how to include other fonts without using google fonts.

@vbd: you can just override the fonts block with your own link and style tags, see:
https://squidfunk.github.io/mkdocs-material/customization/#overriding-template-blocks

This is the default code generated by the block - you would have to provide your own definitions here:

Lines 116 to 138 in 2fbeb28

 {% block fonts %} {% if font != false %} {% endif %} {% endblock %}

### nikramakrishnan commented Jun 10, 2018

 That is a lot of font files! More discussion about Google Fonts Your idea of leaving the Google Fonts loading as-is makes much more sense now. Roboto is at the heart of Material Design, after all. If that is being done, clear warnings could be added to the docs, along with the directive required to disable it.

### squidfunk commented Jun 10, 2018

 Yes, I will provide an entire section on GDPR compliance and how to achieve it with Material

### squidfunk commented Jun 10, 2018

 2.8.0 was just released which bundles both icon fonts. This means that the font configuration option and GA and Disqus integration are the only things that break GDPR compliance. The first must be explicitly disabled, the latter both are disabled by default. See the new section on compliance and feel free to ask any questions so we can mark this topic as done.

### squidfunk commented Jun 12, 2018

 Closing this as fixed. In case any issues or problems arise, feel free to re-open.
closed this Jun 12, 2018

### sheldonhull commented Mar 16, 2019

 @squidfunk As a lurker just have to saw your communication and resolution was stellar. Thanks for this?

### dirkroorda commented Jun 28, 2019

 Thank goodness that you kept the Google Font config option. Whether laws are good or bad, too much respect for the letter of the law is the end of civil society.

### squidfunk commented Jun 28, 2019

 @dirkroorda one year after the advent of GDPR and we're still alive. There's a German article which sums it up pretty well. A few fines were imposed, but all-in-all pretty smooth.
This was referenced Jul 16, 2019