7 ms·

Wikimedia FontCDN – an anonymizing, privacy-first reverse proxy to Google Fonts

87 points by supercucumber 6y ago

SquareWheel 6y ago
As much as I hate to post a pessimistic "Just do X instead" comment... why not just serve the fonts locally? It's no more difficult than serving any other asset. And if you're worried about privacy, then serving files locally removes any dependency on a third-party server at all (or two in this case).
- hannob 6y ago
  Totally agree. Hosting assets like fonts or javascript on the same host is not only better for privacy, it's also more secure (no thirdparty can mess with your content) and contrary to popular belief also faster in a modern web environment.
- Jonnax 6y ago
  Bandwidth is a concern I assume. What percentage of the data transferred is a font or JavaScript library? If it's like 30% (I don't know, just guessing) then that's a portion of bandwidth that could have been used to serve users the site content.
- chrismorgan 6y ago
  There used to be advantage to using global CDNs: you would only need to download each font file once. But now, browsers don’t share caches between origins for privacy reasons (“hmm, judging by how fast these ten resources loaded (and how slowly these other thirty resources loaded), you had these ten in your cache; and such-and-such a sensitive site just happens to load those ten resources and none of the rest…”), so that reason has turned from a positive into a probable negative, because it’s having to look up another domain name and open a new TLS connection—though if you’re serving the resources with HTTP/1.1 it might still be faster coming from a different origin, if you’re loading enough resources. After that, the main advantage of Google Fonts doing the CSS serving is that it varies the CSS it serves by user-agent, to give you what your browser will cope with best, whether it be EOT, TTF, WOFF, WOFF2, maybe they vary the response in other ways as well, I’m not sure. In practice, I think that benefit has run its course: I recommend that people don’t even bother with the bulletproof web fonts formula for supporting all the formats, but just serve woff2: fonts are fundamentally supposed to be optional (icon fonts are generally bad), and users of such ancient browsers as IE, EdgeHTML < 14, Firefox < 39, Chrome < 36 and Safari < 10/12 don’t need the fonts anyway. So then, I say that the only thing that remains is the neat packaging of the font files, subsetting, &c. And I say copying the files and serving them yourself is overall probably a very wise idea.
  - SquareWheel 6y ago
    Good comment. That elaborates on the reasons I chose for self-hosting fonts. And because caches are no longer shared (unfortunately), I've started subsetting fonts myself to trim them down when possible.
    - social_quotient 6y ago
      How much time do you spend on this roughly? Also do you do it for icon fontS like don’t awesome? Thx!
      - SquareWheel 6y ago
        Most of the time investment was setting up the prerequisites for the various tools. Notable requirements were python, node+npm, Microsoft Build Tools, and Google's Brotli. I used glyphhanger[1] to apply the actual subsetting. Use the --spider flag to find a list of unicode ranges used on your site. Then you can generate files with something like: glyphhanger --whitelist="U+20,U+21,U+26-29,U+2C-3B,U+3F-57,U+59,U+61-7A,U+2013,U+2019,U+201C,U+201D,U+2026" --subset=SourceSansPro-Regular.ttf --formats=woff2,woff --css Then you would add that same unicode-range to your CSS. I haven't tried this on icon fonts. I tend towards SVGs instead. [1] https://github.com/filamentgroup/glyphhanger https://github.com/filamentgroup/glyphhanger
      - chrismorgan 6y ago
        I do really simple subsetting on my site: rather than trying to figure out which characters are used in which fonts, I just dump all of the site’s contents, and sort out all the characters in it. A very slightly simplified version of my Makefile, which depends on the original font files found in $(PATH_TO_FONTS): .font-subset: $(call rwildcard,,%.html %.md) find . -name *.md -or -name *.html -exec cat {} + | grep -o . | sort | uniq | tr -d '\n' > .font-subset define FONT = static/$(1).woff2: .font-subset pyftsubset "$(PATH_TO_FONTS)/$(2)/OpenType/$(3).otf" --text-file=.font-subset --output-file=static/$(1).woff2 $(4) --flavor=woff2 fonts: static/$(1).woff2 endef $(eval $(call FONT,eta,Equity,Equity Text A Regular)) $(eval $(call FONT,etab,Equity,Equity Text A Bold)) $(eval $(call FONT,etabi,Equity,Equity Text A Bold Italic)) $(eval $(call FONT,etai,Equity,Equity Text A Italic)) TRIPLICATE_FONT_FEATURES := --layout-features+=ss01,ss02 $(eval $(call FONT,tt4,Triplicate,Triplicate T4 Regular,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt4i,Triplicate,Triplicate T4 Italic,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt7,Triplicate,Triplicate T4 Bold,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt7i,Triplicate,Triplicate T4 Bold Italic,$(TRIPLICATE_FONT_FEATURES))) And with that, `make fonts` generates a new version of the fonts, trimming out all the unnecessary glyphs and features, while retaining ss01 and ss02 for Triplicate. On Arch Linux, this depends on the python-fonttools package for pyftsubset, and the python-brotli package for --flavor=woff2. It would be possible to do much better: to identify which characters are rendered in which fonts, which sequences of characters are employed (so that you can trim kerning and ligature tables), things like that; but this does a good enough job for me. (We’re talking about differences of probably less than half a kilobyte in a <20KB file.) I use only English text on my site and I control all the content, so I don’t need to worry about unicode-range splitting. Concerning icon fonts: this technique would work for it, but for myself I refuse to use icon fonts because they’re fundamentally moderately bad: you can’t trust fonts to load at least in part because quite a few users simply have them disabled for performance or accessibility. There do exist icon fonts that have an almost tolerable fallback, where they use ligatures so that the sequence of letters “envelope” becomes an envelope, “twitter” becomes a Twitter logo, &c. so that screen readers will read the name of the icon without you needing to worry about aria-label and other related properties, but the icon name is normally not the text you should have there, so it’s kind of a waste after all that. Your options are better with something like inline SVG icons or the the inline SVG sprite technique. (See https://icons.getbootstrap.com/ https://icons.getbootstrap.com/ for an example.) Also avoid using just icons with no labels, humans perform enormously better when there are labels on their buttons.
- mmarx 6y ago
  It's primarily _meant_ to be used locally, by all the other tools hosted on Wikimedia Toolforge, which just recently moved to toolforge.org, a service that allows community members to host their own tools for working with and editing Wikimedia projects.
- dt3ft 6y ago
  At last I see someone else recommending this, I was starting to think I'm the only one opposed to 3rd party hosted "free" fonts. I chose to host the fonts myself for my 20-things.com side project. It was a hassle to set up, but I wouldn't have it any other way.
KayL 6y ago
But this is too slow to me. 400ms vs 23ms. I'm in Asia and it redirects me to new zealand. other wiki site redirected to US server. where can I find the wiki CDN network map?
- raxxorrax 6y ago
  Still think this is a nice idea in theory. In practice I often vendor stuff like this, meaning I just don't use CDNs and deploy "local" copies. I could write a few pages about why this is a bad idea, but there are also some advantages.
- est31 6y ago
  This has a map of the Wikipedia colocation sites: https://wikitech.wikimedia.org/wiki/Clusters https://wikitech.wikimedia.org/wiki/Clusters I'm wondering a bit about your new zealand redirect, as there is no colocation site in new zealand on that map at least.
  - KayL 6y ago
    my bad. that's Netherlands
- ryan_lane 6y ago
  This isn't going through the Wikimedia CDN network. It's on wikimedia cloud services, which is a free computing infrastructure (OpenStack/K8s) for community members to build community maintained tooling for Wikimedia.
adrianN 6y ago
I just set browser.display.use_document_fonts=0 and don't worry about the privacy implications of font loading anymore.
- GoblinSlayer 6y ago
  I do it primarily because google fonts are so hideous, it's impossible to read.
whoopdedo 6y ago
My idea, a browser extension that downloads a mirror of the most popular fonts and intercepts requests to google inserting device local CSS instead. Might not be desirable for mobile devices, but with ample storage you get faster page loading and no telemetry sent to anyone.
- mada360 6y ago
  That sound exactly like what decentraleyes does https://decentraleyes.org/ https://decentraleyes.org/
  - gruez 6y ago
    AFAIK it only caches js files, not fonts.
- WorldMaker 6y ago
  All browser font systems already prefer locally installed fonts to CSS @font-face lookups. The tool SkyFonts (from Monotype foundry and recommended by stores like MyFonts.com) as one of several features as a "cloud font updater" includes a "download the top X Google Fonts" option. It's an easy way to get a faster page load experience on the web. The problem to watch out for, and it is why it's not generally recommended, is that font loading times are already in the wild a privacy issue (there are fingerprinting tools out there that try to download fonts and draw them in an off-screen CANVAS, using "too fast" as a deanonymization vector). The best bet to generally help the web at large would be a browser or OS vendor to start installing the Top X fonts from Google Fonts out of the box.
forty 6y ago
Why are people adding external fonts everywhere? Aren't there enough fonts built in browsers to make most people happy?
- Doxin 6y ago
  There are exactly 0 fonts built in to browsers. You could try using fonts installed on the system but that tends to devolve in a cross-platform compatibility mess.
  - WorldMaker 6y ago
    There is a set of 7 fonts widely distributed enough to be considered "web safe" if not built in to browsers (and at one point most browsers installed them if they were not already supported by the OS, but today almost all OSes support them directly so most browsers no longer ship them directly), but it's not a particularly great set: Verdana, Trebuchet, Arial, Comic Sans, Georgia, Times New Roman, and Courier New. Even if those were somehow the 7 "best" fonts in all of the world, there's still a need to support external fonts because fonts are a tool for creative expression. Creative expression might not always be what you want from the web, but as a 90s Web fan, a web without creative expression would be a terrible web.
    - Doxin 6y ago
      Notably that set of fonts excludes most linux installs, given their licenses.
      - GoblinSlayer 6y ago
        YC uses font-family:Verdana, Geneva, sans-serif; and it works fine.
      - WorldMaker 6y ago
        Fair point, many distros don't bundle by default the fonts because they disagree with the free as in beer but not free as in speech nature of the fonts. Though many distros still make them available for those that want them. For instance, in Ubuntu they are included in the "Restricted Extras" meta-package, or specifically in the ttf-mscorefonts-installer package.
ryan_lane 6y ago
This is on toolforge, so while it's technically on Wikimedia run infrastructure (Wikimedia cloud services), the tool itself is maintained by a community member. If you use this outside of the Wikimedia cloud services environment (toolforge and Cloud VPS), then you're asking for trouble. My guess is someone added this tool for other tools to use. There's no way this is being used on the production wikis.
- mmarx 6y ago
  > My guess is someone added this tool for other tools to use. That's precisely what it's for; and there's a cdnjs mirror as well, for the same reason.
floatingatoll 6y ago
The same objections that apply to Cloudflare in various other “anonymization via CDN” posts apply here as well: it’s only anonymizing the data Google sees, but the operator of the proxy can still harvest and profit from non-anonymous data. Be sure you trust the operator of this proxy^ to act in your best interest when evaluating whether to use this. ^ https://news.ycombinator.com/item?id=23780853 https://news.ycombinator.com/item?id=23780853

87 points by supercucumber 6y ago

As much as I hate to post a pessimistic "Just do X instead" comment... why not just serve the fonts locally? It's no more difficult than serving any other asset. And if you're worried about privacy, then serving files locally removes any dependency on a third-party server at all (or two in this case).

hannob 6y ago
Totally agree. Hosting assets like fonts or javascript on the same host is not only better for privacy, it's also more secure (no thirdparty can mess with your content) and contrary to popular belief also faster in a modern web environment.
Jonnax 6y ago
Bandwidth is a concern I assume. What percentage of the data transferred is a font or JavaScript library? If it's like 30% (I don't know, just guessing) then that's a portion of bandwidth that could have been used to serve users the site content.
chrismorgan 6y ago
There used to be advantage to using global CDNs: you would only need to download each font file once. But now, browsers don’t share caches between origins for privacy reasons (“hmm, judging by how fast these ten resources loaded (and how slowly these other thirty resources loaded), you had these ten in your cache; and such-and-such a sensitive site just happens to load those ten resources and none of the rest…”), so that reason has turned from a positive into a probable negative, because it’s having to look up another domain name and open a new TLS connection—though if you’re serving the resources with HTTP/1.1 it might still be faster coming from a different origin, if you’re loading enough resources. After that, the main advantage of Google Fonts doing the CSS serving is that it varies the CSS it serves by user-agent, to give you what your browser will cope with best, whether it be EOT, TTF, WOFF, WOFF2, maybe they vary the response in other ways as well, I’m not sure. In practice, I think that benefit has run its course: I recommend that people don’t even bother with the bulletproof web fonts formula for supporting all the formats, but just serve woff2: fonts are fundamentally supposed to be optional (icon fonts are generally bad), and users of such ancient browsers as IE, EdgeHTML < 14, Firefox < 39, Chrome < 36 and Safari < 10/12 don’t need the fonts anyway. So then, I say that the only thing that remains is the neat packaging of the font files, subsetting, &c. And I say copying the files and serving them yourself is overall probably a very wise idea.
- SquareWheel 6y ago
  Good comment. That elaborates on the reasons I chose for self-hosting fonts. And because caches are no longer shared (unfortunately), I've started subsetting fonts myself to trim them down when possible.
  - social_quotient 6y ago
    How much time do you spend on this roughly? Also do you do it for icon fontS like don’t awesome? Thx!
    - SquareWheel 6y ago
      Most of the time investment was setting up the prerequisites for the various tools. Notable requirements were python, node+npm, Microsoft Build Tools, and Google's Brotli. I used glyphhanger[1] to apply the actual subsetting. Use the --spider flag to find a list of unicode ranges used on your site. Then you can generate files with something like: glyphhanger --whitelist="U+20,U+21,U+26-29,U+2C-3B,U+3F-57,U+59,U+61-7A,U+2013,U+2019,U+201C,U+201D,U+2026" --subset=SourceSansPro-Regular.ttf --formats=woff2,woff --css Then you would add that same unicode-range to your CSS. I haven't tried this on icon fonts. I tend towards SVGs instead. [1] https://github.com/filamentgroup/glyphhanger https://github.com/filamentgroup/glyphhanger
    - chrismorgan 6y ago
      I do really simple subsetting on my site: rather than trying to figure out which characters are used in which fonts, I just dump all of the site’s contents, and sort out all the characters in it. A very slightly simplified version of my Makefile, which depends on the original font files found in $(PATH_TO_FONTS): .font-subset: $(call rwildcard,,%.html %.md) find . -name *.md -or -name *.html -exec cat {} + | grep -o . | sort | uniq | tr -d '\n' > .font-subset define FONT = static/$(1).woff2: .font-subset pyftsubset "$(PATH_TO_FONTS)/$(2)/OpenType/$(3).otf" --text-file=.font-subset --output-file=static/$(1).woff2 $(4) --flavor=woff2 fonts: static/$(1).woff2 endef $(eval $(call FONT,eta,Equity,Equity Text A Regular)) $(eval $(call FONT,etab,Equity,Equity Text A Bold)) $(eval $(call FONT,etabi,Equity,Equity Text A Bold Italic)) $(eval $(call FONT,etai,Equity,Equity Text A Italic)) TRIPLICATE_FONT_FEATURES := --layout-features+=ss01,ss02 $(eval $(call FONT,tt4,Triplicate,Triplicate T4 Regular,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt4i,Triplicate,Triplicate T4 Italic,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt7,Triplicate,Triplicate T4 Bold,$(TRIPLICATE_FONT_FEATURES))) $(eval $(call FONT,tt7i,Triplicate,Triplicate T4 Bold Italic,$(TRIPLICATE_FONT_FEATURES))) And with that, `make fonts` generates a new version of the fonts, trimming out all the unnecessary glyphs and features, while retaining ss01 and ss02 for Triplicate. On Arch Linux, this depends on the python-fonttools package for pyftsubset, and the python-brotli package for --flavor=woff2. It would be possible to do much better: to identify which characters are rendered in which fonts, which sequences of characters are employed (so that you can trim kerning and ligature tables), things like that; but this does a good enough job for me. (We’re talking about differences of probably less than half a kilobyte in a <20KB file.) I use only English text on my site and I control all the content, so I don’t need to worry about unicode-range splitting. Concerning icon fonts: this technique would work for it, but for myself I refuse to use icon fonts because they’re fundamentally moderately bad: you can’t trust fonts to load at least in part because quite a few users simply have them disabled for performance or accessibility. There do exist icon fonts that have an almost tolerable fallback, where they use ligatures so that the sequence of letters “envelope” becomes an envelope, “twitter” becomes a Twitter logo, &c. so that screen readers will read the name of the icon without you needing to worry about aria-label and other related properties, but the icon name is normally not the text you should have there, so it’s kind of a waste after all that. Your options are better with something like inline SVG icons or the the inline SVG sprite technique. (See https://icons.getbootstrap.com/ https://icons.getbootstrap.com/ for an example.) Also avoid using just icons with no labels, humans perform enormously better when there are labels on their buttons.
mmarx 6y ago
It's primarily _meant_ to be used locally, by all the other tools hosted on Wikimedia Toolforge, which just recently moved to toolforge.org, a service that allows community members to host their own tools for working with and editing Wikimedia projects.
dt3ft 6y ago
At last I see someone else recommending this, I was starting to think I'm the only one opposed to 3rd party hosted "free" fonts. I chose to host the fonts myself for my 20-things.com side project. It was a hassle to set up, but I wouldn't have it any other way.

KayL 6y ago

But this is too slow to me. 400ms vs 23ms. I'm in Asia and it redirects me to new zealand. other wiki site redirected to US server. where can I find the wiki CDN network map?

raxxorrax 6y ago
Still think this is a nice idea in theory. In practice I often vendor stuff like this, meaning I just don't use CDNs and deploy "local" copies. I could write a few pages about why this is a bad idea, but there are also some advantages.
est31 6y ago
This has a map of the Wikipedia colocation sites: https://wikitech.wikimedia.org/wiki/Clusters https://wikitech.wikimedia.org/wiki/Clusters I'm wondering a bit about your new zealand redirect, as there is no colocation site in new zealand on that map at least.
- KayL 6y ago
  my bad. that's Netherlands
ryan_lane 6y ago
This isn't going through the Wikimedia CDN network. It's on wikimedia cloud services, which is a free computing infrastructure (OpenStack/K8s) for community members to build community maintained tooling for Wikimedia.

adrianN 6y ago

I just set browser.display.use_document_fonts=0 and don't worry about the privacy implications of font loading anymore.

GoblinSlayer 6y ago
I do it primarily because google fonts are so hideous, it's impossible to read.

whoopdedo 6y ago

My idea, a browser extension that downloads a mirror of the most popular fonts and intercepts requests to google inserting device local CSS instead. Might not be desirable for mobile devices, but with ample storage you get faster page loading and no telemetry sent to anyone.

mada360 6y ago
That sound exactly like what decentraleyes does https://decentraleyes.org/ https://decentraleyes.org/
- gruez 6y ago
  AFAIK it only caches js files, not fonts.
WorldMaker 6y ago
All browser font systems already prefer locally installed fonts to CSS @font-face lookups. The tool SkyFonts (from Monotype foundry and recommended by stores like MyFonts.com) as one of several features as a "cloud font updater" includes a "download the top X Google Fonts" option. It's an easy way to get a faster page load experience on the web. The problem to watch out for, and it is why it's not generally recommended, is that font loading times are already in the wild a privacy issue (there are fingerprinting tools out there that try to download fonts and draw them in an off-screen CANVAS, using "too fast" as a deanonymization vector). The best bet to generally help the web at large would be a browser or OS vendor to start installing the Top X fonts from Google Fonts out of the box.

forty 6y ago

Why are people adding external fonts everywhere? Aren't there enough fonts built in browsers to make most people happy?

Doxin 6y ago
There are exactly 0 fonts built in to browsers. You could try using fonts installed on the system but that tends to devolve in a cross-platform compatibility mess.
- WorldMaker 6y ago
  There is a set of 7 fonts widely distributed enough to be considered "web safe" if not built in to browsers (and at one point most browsers installed them if they were not already supported by the OS, but today almost all OSes support them directly so most browsers no longer ship them directly), but it's not a particularly great set: Verdana, Trebuchet, Arial, Comic Sans, Georgia, Times New Roman, and Courier New. Even if those were somehow the 7 "best" fonts in all of the world, there's still a need to support external fonts because fonts are a tool for creative expression. Creative expression might not always be what you want from the web, but as a 90s Web fan, a web without creative expression would be a terrible web.
  - Doxin 6y ago
    Notably that set of fonts excludes most linux installs, given their licenses.
    - GoblinSlayer 6y ago
      YC uses font-family:Verdana, Geneva, sans-serif; and it works fine.
    - WorldMaker 6y ago
      Fair point, many distros don't bundle by default the fonts because they disagree with the free as in beer but not free as in speech nature of the fonts. Though many distros still make them available for those that want them. For instance, in Ubuntu they are included in the "Restricted Extras" meta-package, or specifically in the ttf-mscorefonts-installer package.

ryan_lane 6y ago

This is on toolforge, so while it's technically on Wikimedia run infrastructure (Wikimedia cloud services), the tool itself is maintained by a community member. If you use this outside of the Wikimedia cloud services environment (toolforge and Cloud VPS), then you're asking for trouble. My guess is someone added this tool for other tools to use. There's no way this is being used on the production wikis.

mmarx 6y ago
> My guess is someone added this tool for other tools to use. That's precisely what it's for; and there's a cdnjs mirror as well, for the same reason.

floatingatoll 6y ago

The same objections that apply to Cloudflare in various other “anonymization via CDN” posts apply here as well: it’s only anonymizing the data Google sees, but the operator of the proxy can still harvest and profit from non-anonymous data. Be sure you trust the operator of this proxy^ to act in your best interest when evaluating whether to use this. ^ https://news.ycombinator.com/item?id=23780853 https://news.ycombinator.com/item?id=23780853