If you embed a font hosted somewhere else you expose some of your user data to them. Now with fonts there's a really simple solution: Just don't. As an added bonus, hosting fonts on your own server is faster as it goes through the same HTTP connection.
There are situations where you can't completely avoid privacy issues, and then you can try to do better than others. But if you can completely get rid of a privacy issue then obviously that's what you should do.
I never quite understood the debate around fonts. You could use the CSS/Link import that Google provides, but that's never the optimal solution. Like you I always download the fonts and use them directly via @font-face.
The only advantage I see to using Google Fonts / some privacy respecting font service like this one, is when you are first prototyping an app and want to either test fonts, or want to move quickly and not worry about setting up fonts properly. We also used in a places like Storybook where having correctly set fonts is not as important.
But even if you did use it in prototyping, it's best practice to pull down those fonts and store them locally before going to production (at least in my mind).
Am I missing something?
For reasons I am sure I will never fathom, browsers on mobile provide all the same settings options, and religiously ignore them.
The best solution here is to use standard fonts that are available in all browsers, of course.
Yes, just serving up your own fonts is better, but this is an improvement that seems to work with only a minor change.
But with HTTP2+, serving from your own domain has no performance impact unless you're limited by bandwidth or extreme latency, and often can improve things by avoiding another DNS/TLS/TCP connection.
I've been down this road. I don't know what it is, but many web developers are extremely adverse to doing it. Even once you've convinced people to let you do it, the first PR from a new hire is a fix for this "bug".
Years ago, when I worked at MSP serving quite a big federal customer... We received a ticket what $companysite.tld isn't working. Pretty unusual, but the first things first, so I just type $companysite.tld in the browser. It works fine.
Okay, ignore then.
But, no, 15 minutes later we receive an email with a tons of people in CC and a lot of !!!!s in the subject and body what the site is still down.
I again check it from my machine (which of course was in the MSP office, not on customer premises), it works fine, DNS, tracert, yada-yada.
Our network team replies what $companysite.tld responds to ping so everything works fine from their POV. Duuuh.
Okay, I hop to the management station located in the customer's DC, test the site there... and it doesn't work there. Just a blank screen, no errors, nothing. Which is pretty strange because the site is hosted in the same DC. DNS resolves to the proper records, ICMP works including traceroute...
Well, long story short, after 30 minutes of head scratching and dozens of emails with ever longer list of people in CC it occurs to me to hit F12.
I open the developer console, switch to Network tab, type in $companysite.tld and I see what the traffic is starting to flow just fine, only to stall to a halt at... googlefonts.com (or whatever TLD they used).
At this point I just calmly sent an email explaining what the site was working just fine, it just wasn't able to properly load from the customer premises because of the block of Google services.
To summarize:
somebody from the customer ordered to block Google services on the network level (don't even ask);
network team (certified Cisco CC** folks!) implemented it by dropping traffic instead of denying - so the firewall would notify the client station about that and the browser would abort the request to googlefonts.com and wouldn't wait a full timeout for each request (don't forget DNS records resolved just fine, if they sent NXDOMAIN for it there wouldn't habe been even an attempt to connect);
network team diagnoses the availability of the web-sites by using ICMP ping... but that wasn't the first or the last time when I was quite... disappointed of their qualification.
While it is very rare for major CDNs to go down, it happens, and even more shenanigans can happen on a network level between some client and your website (and proliferation of DPI by various countries, agencies and enterprises doesn't help here too).
So if you are on the payroll just host the fonts (and honestly - all assets, if applicable) with the web-site and sleep soundly. Of course if you are paid for each "incident", then Web3.0 is all yours. *grin*
any decent browser, i mostly use firefox, have a checkbox in the font screen that prevents sites from changing the page font.
i set all sites to user Ubuntu Mono. always. all the time. everywhere.
the only downside are sites that use winding-like fontawesome. you will get "S" instead of the magnifyingglass icon... i got used to things like that. Google meet screen is particularly weird. meh.
but after you are past the initial shock, having the same font everywhere is the ideal usability hack. faster reading. less distraction. it's perfect.
and as a bonus i don't even care (as i block referrer headers xdomain), not a single request ever goes to googlefont and the likes.
eg: https://opendyslexic.org / https://github.com/antijingoist/opendyslexic
Ubuntu Mono coverage is only 1200 glyphs as per its website, that's very very few.
If I self-host my fonts, the people I have to trust are only those people I have no choice but to trust: those who get my site into the user's browser. Every additional cross-domain request I add is an extra party I have to trust.
$ whois bunny.net (...) Registrant Name: Registration Private Registrant Organization: Domains By Proxy, LLC Registrant Street: DomainsByProxy.com Registrant Street: 2155 E Warner Rd Registrant City: Tempe Registrant State/Province: Arizona Registrant Postal Code: 85284 Registrant Country: US (...)
> we're in a country with better privacy laws"
...it appears that the domain registrant is not, so you will just have to trust that the company is not in the US or not owned by a US entity (mostly relevant for the rest of the world, probably).
> with fonts there's a really simple solution: Just don't
This was worth repeating :)
This isn't an advertisement, I had a very specific use-case, but it follows into this:
Of course, just like with Google, we are the product here. Google Fonts is an analytics data collection platform, Bunny Fonts is an advertisement for their CDN services.
I'm going to stick with a /fonts/ directory, I think, despite being one of their current users. It's really not very much bandwidth for the fonts, it's not 2010 anymore, and I prefer the control (and the local development environment being the same, I don't always have internet and I don't want a dev toggle for something as silly as fonts).
Their web-site is located in the UK[0]
Their fonts CDN is originating from AS60068 which is registered in UK too[1][2]
[0] https://bgp.he.net/dns/bunny.net#_ipinfo
Well, this is what all the fuss is about: respecting the law. I'm not saying the laws are good or bad, just that it is the only thing that most companies really care about.
Anyone who is a bunny.net customer would have an idea. Unlike many of the myriad wesbites using Google fonts, they would also have an agreement with Bunny they could potentially enforce.
Anyone doing internet research who peruses publicly available scans of DNS ports in the last five years would likely be familiar with bunny.net as they are a large enough CDN to have many thousands of subdomains for customer IPs. It is seemingly impossible to miss this company's presence toward the beginning of the scan.
The founder of bunny.net recently posted a question in an nginx forum. This is not AWS or Google. Amazon sells goods. Google sells online advertising services. Both are primarily intermediaries (middlemen) who try to prioritise their own competing goods/services. All the data those companies collect may feed into other business that strives to study and understand consumer behaviour, e.g., placing internet-connected microphones (referred to only as "speakers") in people's homes or internet-cnnected GPS trackers in their pockets. There are strong incentives for those companies to conduct extensive surveillance. Bunny sells CDN services. At present, that's all, AFAICT.
1. https://bunny.net/our-story
This HN submission purports to mirror the recent announcement of fonts on the bunny.net blog on 16 June however it currently points to an "About" page, not the blog entry. The blog entry discloses in more detail the rationale for the decision to offer fonts.
https://bunny.net/blog/bringing-privacy-back-into-your-own-h...
There is an argument supported by legal decisions in Austria, Denmark and Germany that neither Google Fonts nor Google Analytics are GDPR-compliant.
https://www.theregister.com/2022/01/31/website_fine_google_f...
But true, I doubt Google is more nefarious than other resource provider. I am 99.9% sure that Google is not abusing cookies to extract end user data through their fonts service.
I believe you might be legally obliged to inform the user about them setting a cookie though. Alternatively, and this might be the better solution is to simply "vendor" the fonts (supplying them from your own server).
Not using fonts is not always an option
The silliness of this is that someone is going through the effort to set up hosting for a website but hosting the fonts is just too difficult and has to be delegated to a third party. The laziness of webdevs never fails to astound.
Do you have an example where doing something in an external font is not possible in one that's built into the browser?
This is the important part. Laws are not about trust.
Self-hosting is probably a better habit to acquire anyway, the only alternative being explicitly contracting with a company that offers edge CDN.
https://google-webfonts-helper.herokuapp.com/fonts
is great for quick self hosted local Google Webfonts
I thought the whole point is that using a common resource your chances of a cache hit are much higher such that they don't need to download. Having said that, if you are worried about GDPR you are probably way better off hosting them yourself anyways
Speaking as a European: I think this is a very important topic for us. I don't think Americans and American companies understand how little trust rest of us have for the American government. Working with a company that is not subject to the whims of the American government is a huge privacy win. If a company pitches me a product, they start 1 points ahead if they are based on Switzerland, Netherlands or somewhere similar.
European countries do the same for USA gov on US citizens.
What is important here, and why these laws matter, is how trivial it is to get access to your data, or for companies to sell your data. That’s why I appreciate the European’s effort to have better laws for our privacy.
If you really want to be government proof, then you better host everything in a server in a remote secret location out of their reach.
At this point we're supposed to believe what amounts to feel-good talk.
But I keep asking: "How do we know for sure?"
I haven't done anything illegal nor do I need to protect some mega-important knowledge but I still dislike giving easy access to my data so I automated parts of my workflow to double-encrypt my most important data and send it to several off-sites plus an own self-hosted server.
Sure, they likely know remote Linux network zero-days but the odds of them wanting to target me in particular are minuscule so... ¯\_(ツ)_/¯
You are trusting them just as much as a server in any other country. Saying "Switzerland" is all marketing for privacy enthusiasts who aren't going to do anything on their own.
Have you... have you seen our politics? What makes you think that we think other people trust our government? We don't trust our government. Hell, it's trusted so little that one of our large political parties is basically entirely devoted to making sure that the government can't get anything done.
But when it comes to surveillance on this quotidian level, I think private/corporate surveillance it’s far more relevant and problematic. In that regard, I’d slightly prefer a European country with good privacy laws like those you listed, because (probably) Bunny is not itself at the level of a panopticon such as Google, and the likelihood it has or would avail of avenues for resale to panopticon capable data brokers is less than it would be for US companies.
But even there, it does seem like a quite incremental improvement. The door is still wedged open, but now probably less wide, and probably with a stronger doorstop. It would be nice to not leave the door open at all.
You can only trust services like signal which make it impossible for the operators to access your data
GDPR is mainly against corporations making money out of knowing who you are across the web, it won't save you from a government actor
So you're safer from the USG inside the US.
Then again, they don't have a great track record of following those restrictions, so I doubt it really matters.
Crypto AG was based out of switzerland.
or any government, especially our own, for that matter. Some just have a better track record at being bound by the rules they give themselves than others.
So no, this is not one of those examples, this is a great example of someone setting up a service to remove all those free, extra data points that Google harvests. Today it's fonts. Maybe tomorrow, it's the rest of their "it's not explicitly Google Analytics" offerings.
> The quick brown bunny jumps over the lazy dog.
While the site is trying to be quirky and cute, replacing 'fox' with 'bunny' doesn't showcase what 'f' and 'x' look like.
- The quick brown bunny jumps over the lazy podgy fox.
If you want to do it with one word you can do:
- The quick brown bunny jumps over the oversexualized dragonfly.
- The quick brown bunny jumps the oversexualized dragonfly.
The quick brown bunny jumps over the lazy dog, here, fixed.
> Two driven jocks help fax my big quiz. Pack my box with five dozen liquor jugs. The five boxing wizards jump quickly. Bright vixens jump; dozy fowl quack. Jackdaws love my big sphinx of quartz. John quickly extemporized five tow bags. Waltz, nymph, for quick jigs vex Bud
The quick brown fox jumps over the glazed bunny.
I would scrap at least Avenir Next, Avenir, Helvetica Neue, Helvetica, Ubuntu, Roboto, Noto, Arial, Apple Garamond, Times New Roman, Droid Serif, Times, Source Serif Pro, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Monaco, Liberation Mono and Lucida Console, and probably a couple more, for one of three reasons: that the family is superfluous, for an obsolete platform, or inferior.
```
font-family: -apple-system, BlinkMacSystemFont, avenir next, avenir, segoe ui, helvetica neue, helvetica, Cantarell, Ubuntu, roboto, noto, arial, sans-serif;
```
Am I doing it wrong by declaring it just like `font-family: sans-serif`?
So, you're "doing it wrong" in the sense that you're not actually doing the same thing, but you're not wrong in some kind of cosmic sense. :)
(This does make me wonder for the first time why, when system font stacks started to become popular, browsers didn't just make the system fonts the defaults, though. Sure, it would mean that web pages that only specified "sans-serif" would change appearance between the old and new browser versions, but if they only specified "sans-serif" they were declaring "I don't care what font you give me as long as it's sans serif" anyway.)
Use `font-family: sans-serif` for your everything on your website except code blocks and inline code elements, which should use `font-family: monospace, monospace`. Yeah, you have to specify `monospace` twice. If you don't, monospace fonts will be unnaturally smaller than sans-serif fonts.
Please don't use serif fonts on your website, ever. Most people on the planet don't have a high resolution display and serif fonts look chipped and broken on those displays. Serif fonts make sense if you're using them inside a media query for print.
Google Fonts lets you download fonts for desktop use, in the form of .ttf or .otf rather than the .woff[2] with one file per Latin/Greek/Vietnamese/etc. script served by Google Fonts itself. If you want the same font-embedding CSS as Google Fonts itself, you can use https://google-webfonts-helper.herokuapp.com/fonts (a font browser, outdated, doesn't support font-display: swap), or https://nextgenthemes.com/google-webfont-downloader/ (a converter from Google Fonts CSS URLs to downloadable font packs, supports font-display: swap, it works well but I chose to not host the large CSS files with embedded fonts in base64 format).
As a technical curiosity, the second site can suffer a race condition resulting in partial or broken file downloads (I never tested what happens), if two people request the same font bundle at the same time, and they overwrite each other: https://github.com/nextgenthemes/open-webfonts#bug-reports-a...
I wish browsers would give users an option to set the default font-display policy to swap.
Additionally, a CDN will let that content be closer to your customer, so even if it wasn't cached with the magic of CDNs it should be faster than one origin server.
Correct. The last major browser stopped in early 2021.
> I think browsers still cache content from request to request for a domain.
Definitely! A cache still provides substantial speedup. Modern browsers fragment the cache on a per-site basis: www.example.com and www.example.org don't share, but www.example.com and forums.example.com do share.
That's pretty much always faster than a new TLS handshake, regardless of roundtrip.
PDF won the text presentation format war because among other things, PDF embedded the user's font.
for consistency, and if you care about not using google's CDN, just self-host your fonts.
Self host (supported by Google Fonts but not by this service): - Better privacy - Better performance (no extra DNS lookups, TLS connection)
Their default embed code is a CSS @import directive. These must never be used in production code (It's fine as a directive for the compiler for local files but not with remote URLs). Leads to FOUC and FOIT.
Also, next step in amateur hour: They serve their CSS and fonts on the same domain as their marketing website. Cookies galore.
What are those acronyms?
* FOUC: when you see content in the wrong font, then it switches to the correct font, sometimes leading to page layout jumps.
* FOIT: when you see _no_ text content because the desired font is missing with no fallbacks/the CSS directed not to use fallbacks. Once the font loads, page layout might jump.
Counterbalanced by the fact that if you just throw any old random font file on your server, it'll quite possibly be larger (in some cases considerably so) than necessary. So now you need to subset/split up the font files yourself, which takes some extra work (and the various online subsetting tools I've found often don't allow proper control over which OpenType typographic features to keep, sometimes mangle ligatures, etc., so I had to hack something together myself based on the Python fontTools), especially if subsetting a single file isn't enough and you actually need to split the fonts into multiple files.
sudo bash -c 'echo ":: fonts.googleapis.com" >> /etc/hosts'
sudo bash -c 'echo "0.0.0.0 fonts.googleapis.com" >> /etc/hosts'
I just prefer having pages load quickly and don't generally think custom fonts improve the experience.
Uncheck "Allow pages to choose their own fonts, instead of your selections above"
No remote fonts anywhere.
But pages are fast to load, I get a consistent chosen font across all sites and my privacy (at least for font loading) is respected.
url("https://fonts.googleapis.com/comic-sans", sha="abcd1234")
- If my browser has comic-sans cached, no request is made
- Caching works even if the same resource is sourced from multiple places (e.g. I can host comic-sans locally, but if they got it from a CDN, they don't need to get it again)
- If a malicious site replaces a resource, that's flagged
I think the trick would be to make this optional (but bandwidth/privacy-saving), and gradually to make this increasingly mandatory for different types of resources. AJAX calls obviously can't have SHA hashes, but JavaScript libraries can.
One issue with cross-site caching, though, is that it may enable timing-based attacks on privacy.
1) Mandating it for certain types of resources
2) Extending caching to cover the cross-site case.
Can you please explain the proposed timing-based attack?
- The end user could have the option to enable/disable caching, and to clear the cache. Further configuration is also possible, e.g. to enable same-origin caching only.
- The end user could have the option to replace resources with their own regardless of where the files come from; there is one table keyed by hash and the value is the file to use instead, which might or might not be the same file (so the hash does not necessarily need to match the file that is being used instead).
- Features specific to the browser to make it more efficient could also be used when the user configures replacement of resources, e.g. if it can somehow implement jQuery in native code, or uses a different font format which is more efficient on the computer that it is running on.
- If archived copies of parts of web sites are being made, it can efficiently check if it already has some file which is being used in such a way.
However, requiring a hash probably should not be made mandatory.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co... https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
This is exactly what a FBI/CIA/GCHQ/FSB front company would say. They love to set up fronts in good-reputation countries, like Switzerland, or Slovenia in this case.
As a Slovenian, thanks for the laugh.
If I had to choose I'd take the unknown evil rather than the 100% known evil, though in this case it's dumb to use either option when you can trivially self-host.
$ dog A AAAA fonts.bunny.net
CNAME fonts.bunny.net. 10s "bunnyfonts.b-cdn.net."
A bunnyfonts.b-cdn.net. 10s 195.181.164.130
CNAME fonts.bunny.net. 9s "bunnyfonts.b-cdn.net."
A bunnyfonts.b-cdn.net. 9s + 195.181.164.130The license is non-standard too, something called SIL. I'm not gonna bother looking up what that weird thing permits when I can get thousands of CC0 fonts from like a dozen sites.
It's the same as Google Fonts (because they're the same fonts). Most of the fonts are released under the terms of the SIL Open Font License 1.1, and a handful of them released under the terms of the Apache License 2.0.
Most free fonts are OFL'd.
Is that damn, or down, or something else? Why astreisk it out?
One would expect this to be at the top of their FAQ.
Bunny is an extremely affordable CDN. The business they'd get from medium to large sites that already trust them enough to serve fonts over them should easily make up for it.
Behold exhibit A: https://i.imgur.com/6F7fZVm.png
Time is money, and it's expensive to pay people to mess with things if they don't have to.
I might not choose to make the same tradeoffs, but I can understand why others might.
Bunny Fonts: "1429 families"
Presumably Bunny Fonts is, essentially, just a pass through to Google Fonts.
Yeah, sure.
Or maybe just host your own fonts. 350KB traffic per unique visitor per month isn't going to kill your bill unless you serve millions of visitors a day.
This is in contrast with the behavior on fonts.google.com where missing characters are rendered with an inline image to explicitly show the missing glyph.
I prefer the fonts.google.com behavior here, which makes it easier to find fonts that have all the glyphs I need.
https://developers.google.com/fonts/faq#what_does_using_the_... was updated today, confirming Google Fonts doesn't log IP addresses.
Given that, it's unclear to me personally what the difference is between Bunny Fonts and Google Fonts.
I wondered if it supports fonts out of the box, but not currently.
If your origin is already fast and/or fronted with your own CDN the self-host and serve the fonts directly under you own domain. Trivial work with better security and performance.
As a www user, unless I am filing GDPR complaints against websites using Google Fonts under default configuration, i.e., served from Google computers, , I have no reason to care what fonts a website is using.
