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

Currently not GDPR compliant - reason external fonts #739

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

Currently not GDPR compliant - reason external fonts #739

DsrMedia opened this issue Mar 19, 2018 · 32 comments
Labels

Comments

@DsrMedia
Copy link

@DsrMedia DsrMedia commented Mar 19, 2018

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

This comment has been minimized.

Copy link

@wopian wopian commented Mar 19, 2018

Google Fonts don't use Cookies though?

@squidfunk

This comment has been minimized.

Copy link
Owner

@squidfunk squidfunk commented Mar 19, 2018

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

@nikramakrishnan nikramakrishnan commented Mar 21, 2018

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

This comment has been minimized.

Copy link
Owner

@squidfunk 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
@justjanne

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Owner

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

@nikramakrishnan

This comment has been minimized.

Copy link

@nikramakrishnan nikramakrishnan commented May 31, 2018

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Owner

@squidfunk squidfunk commented May 31, 2018

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

@squidfunk squidfunk reopened this May 31, 2018
@justjanne

This comment has been minimized.

Copy link

@justjanne justjanne commented May 31, 2018

@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

This comment has been minimized.

Copy link

@Omeryl Omeryl commented May 31, 2018

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

@squidfunk

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

@squidfunk squidfunk commented Jun 10, 2018

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

This comment has been minimized.

Copy link
Owner

@squidfunk 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:

<!-- Webfonts -->
{% block fonts %}
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin />
<!-- Load fonts from Google -->
{% if font != false %}
<link rel="stylesheet" type="text/css"
href="https://fonts.googleapis.com/css?family={{
font.text | replace(' ', '+') + ':300,400,400i,700|' +
font.code | replace(' ', '+')
}}" />
<style>
body, input {
font-family: "{{ font.text }}", "Helvetica Neue",
Helvetica, Arial, sans-serif;
}
pre, code, kbd {
font-family: "{{ font.code }}", "Courier New",
Courier, monospace;
}
</style>
{% endif %}
{% endblock %}

@nikramakrishnan

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

@squidfunk squidfunk commented Jun 10, 2018

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

@squidfunk

This comment has been minimized.

Copy link
Owner

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

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

@squidfunk

This comment has been minimized.

Copy link
Owner

@squidfunk squidfunk commented Jun 12, 2018

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

@squidfunk squidfunk closed this Jun 12, 2018
@sheldonhull

This comment has been minimized.

Copy link

@sheldonhull sheldonhull commented Mar 16, 2019

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

@dirkroorda

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

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

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

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.