Remove Google surveillance

[aral]

By default, mdbook includes tracking code from Google. See: https://github.com/rust-lang-nursery/mdBook/search?utf8=%E2%9C%93&q=google&type=

Can we please remove this so that books generated by mdbook do not expose the people who read them to surveillance by Google/Alphabet, Inc.

The toot that brought it to my attention: https://mastodon.host/@BartG95/101222458295737848 (after I hosted a render of The DAT Protocol book on my own site. (Thereby unknowingly exposing people to tracking from my personal site.)

Related issue on The DAT Protocol book’s issue tracker: dat-ecosystem-archive/book#20

[seanlynch]

This seems like it could potentially cause people to violate GDPR, possibly even the authors themselves.

[BartG95]

It seems to be caused by the inclusion of some fonts from G👀gle (fonts.googleapis.com, fonts.gstatic.com)

[joepie91]

The analytics tag exists directly in the templates, not as a result of Google Fonts usage.

[BartG95]

Well, this is what I mean:

[BartG95]

Ah, found the bug: https://github.com/rust-lang-nursery/mdBook/blob/42b87e0fbc6815ae2177a5fc4838dad11a33fe4f/src/theme/index.hbs#L20-L21

[BartG95]

Everything seems to render fine without this loaded. I suggest to either:

• Remove these lines; or
• Include the fonts directly in the repository.

[aral]

Related existing pull request that should resolve this issue if merged: #716

Please advise whether it would be preferable to serve Open Sans and Source Code Pro as first-party instead of via Google or whether the above pull request is the way to go.

[TerminusBot]

Google fonts is not available in China.
mkdocs/mkdocs#1138

Please don't use google fonts default.

[ddevault]

Hey guys, this is a serious problem. I'd apprecaite it if the maintainers took a moment to address it, rather than letting this issue continue to grow stale.

[Dylan-DPC-zz]

@ddevault sure will try and prioritise this and resolve it ASAP. Thanks

[ddevault]

Thanks @Dylan-DPC, I appreciate it.

[ehuss]

@Dylan-DPC I spent some time looking at #848 and it seems surprisingly complex. I'm also not sure how important non-latin fonts are, that PR does not include them. I think there would also be some licensing requirements for redistributing the fonts. I would also think there should be some consideration for theming. As-is, it unconditionally copies the fonts into the output, even if you don't use them.

Also of interest, rustdoc just updated its fonts in rust-lang/rust#60146. Would be curious to hear your opinion about which direction you would prefer to go. Just grabbing Open Sans locally seems like it would be the least disruptive. But I think there should be better control for changing which fonts are used. I'm willing to help, the delays caused by loading remote fonts while working locally can be a little frustrating.

[ddevault]

I think there would also be some licensing requirements for redistributing the fonts.

Google fonts use the Open Font License, which is a free (as in freedom) license that permits redistribution.

I'd suggest just using the system fonts and living with it if the user doesn't have them. It's not the end of the world.

[ehuss]

Google fonts use the Open Font License, which is a free (as in freedom) license that permits redistribution.

I'm pretty sure Open Sans is Apache 2.0. I just meant the license needs to be included with the fonts.

[Dylan-DPC-zz]

@aral or @ddevault are you open to sending a PR that makes this change? Thanks

[ddevault]

Sure, I'll see if I have some time tomorrow.

[ddevault]

Started looking at this, but it seems like #848 is on point. The only change would be adding the license. Right?

[ehuss]

I see two other minor issues with the PR:

• It doesn't support non-latin scripts. All other scripts will fall back to the system sans-serif.
• It forces all books to include a copy of open-sans, even if they use a theme that modifies the font.

I'm not sure if either of those issues matters much.

[ddevault]

@aral thoughts?

[kriskeillor]

With this issue having survived from #20 to #847 to now, why hasn't this serious security flaw been fixed?

I just removed the google font dependence from my book.js. There's no font issue on mobile or desktop. Any web browser has fall-back fonts suitable for their users these days.

[ghost]

I am also curious as to this rationale or any maintainer feedback. Seems to be important to many people.

[ehuss]

@evitalis Someone just needs to do the work. I would like to see a solution that is relatively easy to maintain, retains the default use of Open Sans and Source Code Pro, properly deals with licensing, doesn't force the inclusion of a lot of heavy-weight font files for books that have custom themes, maintains broad browser compatibility, and generally avoids too much disruption. I'd be willing to drop support of extended unicode blocks if it is easy to specify ones own fonts. This also bumps against some of the problems with the current theme system which makes it difficult to customize or make incremental changes. This will all take some design work. Can you help with that?

[ghost]

@ehuss see #848 someone seems to have done this work already but is pending a merge or more feedback/additional help.

[ehuss]

@evitalis the feedback is listed above. The PR author is the same as this issue.

[ghost]

Noticed this was linked over in the mkdocs repo for a similar issue. Perhaps both projects could resolve the problems in a similar way or help brainstorm a reasonable solution?

[t1anchen]

Is it viable to consider removing Google Font online dependencies first? Every time when the book is generated by mdbook build, opening page will cause the browser to raise an attamption to connect to Google services, which might be extremely painful (it has to wait until the connection timeout) under the restricted network circumstances. Can we make content visible first and then consider decorations/styles?

Anyway, if the online dependencies are removed, it might come up the consequent possibilities such as packing into epub or other portable ways to pack HTMLs ...

IMHO Open Sans and Source Code Pro can never cover all cases (i.e. non-latin characters, symbols). It would be better to handle the compatibilities to HTML reader (i.e. browsers, ebook readers or etc.)

[ghost]

Been looking to revisit this application but this is still a blocker for me. Just curious, what is everyone else in the thread doing to avoid the Google fonts pending an official fix?

[ddevault]

I've been porting my book to a custom software which is not maintained by people who care more about aesthetics than the confidentiality of their reader's personal information.

[kriskeillor]

I just deleted the google font imports from my index.hbs file.

Every browser ships with default fonts. No need to go to google. Or to rag on mdbook's team for their valid motivations (that I disagree with) to keep the google reference in.

[blastur]

+1 for getting this fixed; Google surveillance is one thing, but for me the book is completely broken because I'm in a special network environment where domains resolve but all network access is permitted. So the book just won't load as long as these Google references are in the file.

I did what krisradio did, edited index.hbs and recompiled mdBook, but this is not a good solution longterm.

[rendeko]

Is there something I can add to my additional-js in the meantime until this is added as an option? Without an option to not call Google API's, I'd prefer to use other software.

[ivilata]

I know this is very spartan and not a solution but it may help work around the issue for simple books:

#!/bin/sh
set -e
mdbook build
# [Remove Google surveillance](https://github.com/rust-lang/mdBook/issues/847).
find book -name '*.html' | xargs sed -i '/<link href="[^"]*\bfonts\.googleapis\.com\b/d'

(It just shoots whole lines with head links to Google APIs out of HTML pages.)

[simonrepp]

Looking through the PRs I'd say @aral and @pheki did a thorough job of adressing all concerns brought up so far (great work 👍 very thankful!).

I've recently adopted mdBook for a project and I was rather astonished to learn today that google fonts API calls were put into mdBook at all, I'd really have thought this would be an obvious no-go, but apparently that is not so. In any case I would kindly ask the maintainers to review and merge this soon. If this grows stale again now after a lot of work has been put in by people to adress all issues, I'll definitely migrate to another static generator, no hard feelings, but these things matter and should be given attention.

[stappersg]

Pull Request #848 Serve fonts locally and #1188 _ Remove google fonts by serving them locally_ were already mentioned. Now adding PR #1189 Self-host fonts, add option to not copy to directory to this issue. I hope it helps to get it solved.