Mkdocs-material: Currently not GDPR compliant - reason external fonts

[DsrMedia]

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.

Actual behavior

It's loaded from a CDN.

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.

[wopian]

Google Fonts don't use Cookies though?

[squidfunk]

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]

@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]

@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?

[max-ci]

@squidfunk FYI http://michaelboeke.com/blog/2013/09/10/Self-hosting-Google-web-fonts/

[squidfunk]

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

[nikramakrishnan]

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.

1. Google Fonts FAQ Section on Privacy

2. Discussion on GDPR Compliance on the Google Fonts GitHub Repository

3. 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.

[squidfunk]

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

[justjanne]

@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]

@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]

@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]

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]

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

[nikramakrishnan]

There's been a lot of debate about this on the Google Fonts repository issue that I linked before. Although Google has issued several official statements (prefixed to the first comment), but these statements do not directly address the problem, and do not make it clear as to whether we can use Fonts in projects.

This discussion on CIDRAM proposes to disable use of Google Fonts by default and add a clause to the Privacy Policy about enabling it.

Again, this is not legal advice, and we need to be careful!

[squidfunk]

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]

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]

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]

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]

@justjanne: just disable Google Fonts and you are fine! No need to take it down.

[justjanne]

@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]

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

[squidfunk]

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]

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

[squidfunk]

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]

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:

https://github.com/squidfunk/mkdocs-material/blob/2fbeb28d9dbda3e27fbe78dfa7cd53e76db8dab2/src/base.html#L116-L138

[nikramakrishnan]

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]

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

[squidfunk]

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.

See https://squidfunk.github.io/mkdocs-material/compliance/

[squidfunk]

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

[sheldonhull]

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

[dirkroorda]

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]

@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.

[seekM]

If I'm not mistaken it was said in this discussion that material bundles font files for GDPR compliance.

However, using this simple configuration

site_name: Test
nav:
    - Test: index.md

theme:
  name: material

I noticed that it seems that requests at fonts.googleapis.com and fonts.gstatic.com are made:

I didn't expect this to happen - am I missing something here?

Note that https://squidfunk.github.io/mkdocs-material/compliance/ isn't working anymore.

[martinbira]

@seekM Please check this page: https://squidfunk.github.io/mkdocs-material/data-privacy/