I find it really strange where some privacy debates have gone wrong, and this is a perfect example. It's basically a form of "don't trust them, better trust us, also we're in a country with better privacy laws". Which is an imperfect solution at best, and given that I have no idea who bunny.net is it's a questionable one at best.
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.
> 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.
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).
I used to do this, but it broke a lot of websites, especially those that use custom fonts to display symbols.
Nowadays, what I do (and recommend to others) is to set Firefox to never send a referer cross-origin, so google fonts and similar don't get to see what website I'm on. I've found that very few websites break with this.
Font icons is another one of these things that some web developers tend to do and should probably stop. SVG icons are superior in every way—at least all the ways I can think of.
A growing number of websites support dark mode theming, but not all of them. When I open a page in reader mode and switch to dark theme, I don't expect logos in the text to fade into the background. Svg is also often much larger than a font file, especially one that's subset.
While it's not svg or on the open web, I have a particular hate for sborn.jpeg in ebooks, as I read my ebooks in dark mode at night and having occasional section break symbols (ornaments) white on black is particularly irritating. Other unnecessary images often found in ebooks include bullets, chapter titles flourishes, letters with accents, and even the chapter title itself.
I was manly talking about icons, but not logos. Icons usually only have one color—which is often the same color as the surrounding font color. If your icon is only a single <path> (most good icons are) then you can color them with:
I don’t know about the size, but I suspect that if any the difference is negligible. Most of my icons are a few hundred bytes uncompressed. And I usually put them in a sprite which is usually well under 50 KiB uncompressed. I don’t know how large font icon files are, but I suspect they are not that much smaller that it makes a difference.
> Svg is also often much larger than a font file, especially one that's subset.
Subsetting is where SVG shines, though.
For icon fonts, you can much more easily subset SVG icons than a font file. Font file subsetting needs dedicated tools like font editors (with Icomoon being a common choice these days) and often manual maintenance/upkeep, whereas SVG tree shaking is a natural part of any web bundler (webpack, etc) and automatically adapts to your icon usage and tools in your web bundler such as bundle splitting/lazy loading.
The Fort Awesome JS libraries behind Font Awesome's SVG icon fonts reduce things further from SVG XML files to tree-shakeable ESM files [EcmaScript Modules] that include just a few pieces of metadata and the lone important path text (sticking to a single SVG path per icon), then build the SVG DOM at runtime (as VDOM in the case of the React library), including making sure it follows fill: currentColor to pick up the text color. Minified and tree-shaken by most web bundlers the ESM files are very competitive with any other font format and the convenience wins of automatic subsetting by web bundler are hard to match.
I use Calibre for font subsetting, usually for use in ebooks, but I've used it for a website as well. The only gotcha I've found is that Calibre doesn't recognize css content attributes (`div.icon{content:"source:"}`), and that font names need to be correct. This is pretty trivial to get around, and generally only needs to be done once.
I've never used webpack or any other bundler on any personal website I've written, nor have I ever used react or other heavy frameworks (I used jQuery when I was in school). Perhaps these are useful on larger websites, but I prefer to avoid scripts in general, with the sole exception being scripts that parse a data source to generate a page client-side (most pages on my system are static, so I don't even have php or such installed). To me, automation means I make changes to the html on my server and reload the page.
SVGs are still often better subsetted raw ("unbundled") in that case both for local development and on HTTP/2+ servers. Things are slowly moving back away from bundlers/bundles which were mostly about getting the most out of HTTP/1.x tradeoffs most of which either no longer apply (because changes in browser caching rules for privacy reasons) or are mostly obsolete concerns (with HTTP/2+).
You aren't going to get easier subsetting in a modern browser than a folder full of SVGs and the browser only pulling the URLs it needs as it needs them rather than an entire bloated icon font format all at once up front. No need to double check that Calibre has got the right font subset from your CSS or to open Calibre at all, just upload the folder of SVGs and let the browser "subset" it, in the classic ways of HTML going back to its origins. Even less "automation" than Calibre.
> I don't expect logos in the text to fade into the background.
You can use @media (prefers-color-scheme: dark) { ... } in the style inside the .svg and browsers render it accordingly in dark/light mode. But yes, not being able to set the color from the page CSS is annoying.
Not advocating for font icons but one advantage is that their color can be styled form the page CSS - for SVG that only works if the SVG is embedded in the HTML, not if it is loaded externally or from data URLs.
If the font is already in your browser cache (which it might be if they're hosting it on a common CDN) web pages should load with the correct font right away instead of either loading blank areas or a default fallback font before switching to the correct font, causing jank.
The best solution here is to use standard fonts that are available in all browsers, of course.
And it's such a niche privacy issue too. I would gladly take a shared cache over cache isolation. Especially for something used on as many sites as Google Fonts is.
You may be interested in the LocalCDN extension [1] which tries to solve the privacy vs speed issue for common resources by intercepting known remote resource requests and returning a local copy.
It seems okay to me for the case of google. Since Google-owned sites, Adsense, Gmail, and Google Analytics are so ubiquitous, things like a font download are trivially easy for Google to correlate to your other activity. There's much less value for BunnyCDN to abuse it, because they don't have the critical mass of your other activity.
Yes, just serving up your own fonts is better, but this is an improvement that seems to work with only a minor change.
For both bunny.net and Google Fonts, using a CDN is useless with the advent of timing attacks related to the browser cache https://news.ycombinator.com/item?id=24894135. Storing fonts on the same domain avoids a DNS lookup and extra TCP connection.
I see this completely the opposite. There’s much more risk to Google to be lying about the privacy agreement applicable to Google Fonts (https://developers.google.com/fonts/faq#what_does_using_the_...) than there is to some unknown company that won’t be a target for regulators and won’t make any news for casually violating your privacy through shoddy engineering work or incompetence let alone maliciousness.
I perceive exactly zero risk to Google in lying about literally anything at all. Have you ever heard about them being even slightly inconvenienced in response to any abuse?
The GDPR went into effect in 2018 and gave companies 4 years to prepare for it. The GDPR has strict guidelines as to how data processing consent flows should be presented, including the fact that it should be as easy to decline as it is to accept.
Yet, Google initially implemented a malicious consent form where accepting is easy and declining is impossible. They only very recently implemented a compliant consent flow which gives you an easy option to decline.
Google has already proven their bad faith and successfully got away with it, along with plenty of other companies.
Can someone point out a good reason for not downloading the font files and serving them directly from your CDN or servers, without any calls to third-parties in your HTML?
No great reason. Google occasionally optimizes the CSS delivery along with browser features (like in Chrome releases) where only certain files (and now only parts of files) are downloaded for the fonts.
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".
As I understood the answer, the expanded version would be "the only disadvantage is having to spend an unreasonable amount of time arguing about this issue, which will drag on forever since it is relatively minor."
Google Fonts does serve a different font based on the user agent. Depending on things like hinting and stuff. Bunny fonts would help solve that problem.
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*
Wouldn't initial page load be affected? On the user side this only really happens on the very first load when the font isn't cache'd but this might affect SEO bots more?
It makes no difference other than download/parse performance. You have to weigh the latency/bandwidth of your origin vs that of Google's CDN and the extra connections.
you won't believe this, but as the end user you can solve this in your life once and for all, and also improve your life! something rare for online annoyances nowadays.
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.
I used to disable font overrides altogether. Another failure mode of that mode is that the omnipresent Material Icons displays words (the font contains ligatures replacing words with icons) instead of icons.
Alternatively people can use uBlock Origin and simply block all remote web fonts. It'll break some sites which use fonts to replace icons, but the add-on can easily be disabled for those specific sites.
And that I don't get to see the site as the original designer intended. It's of course perfectly fine for others to not care about that, but I enjoy it.
I also configure it to prevent sites from changing the page font. However, if a fix pitch font is requested, then it should always use a fix pitch font to display the text (even if it is not the same font as was requested), and I would want PDF and SVG to support loading fonts, but not HTML. However, there does not seem to be a setting for that.
Icon fonts that use the Private Use Area code points do still work when you just instruct the browser to not let pages override your choices. This is the way almost all icon fonts work. In the last few months I think I’ve observed only three fonts not doing so; DuckDuckGo is one, the second was some small business’s site using a style from many years ago, and the third is Google’s Material Icons font, distressingly widely used, which uses a ligation technique the implications of which really weren’t thought through properly. (It was supposed to improve accessibility in case of the font not loading, but in practice it makes it disastrously bad much more often, as can be seen on a number of Google properties, like their docs sites and Google Translate which are both significantly mangled by it.)
If you're requesting data over a network, ultimately you have to trust someone. Fwiw bunny.net is pretty well respected. I view them as one level "below" the mega-enterprise CDNs like Cloudfront/Akamai, the same way Digital Ocean is one level "below" AWS/GCP/Azure
> If you're requesting data over a network, ultimately you have to trust someone.
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 is run by BunnyCDN, I've been one of their smaller users for a few years now (live video hosting and delivery, mostly .m3u8, mpegts, HTTP Live Streaming type of stuff) and I've always found their service reliable and cheap. One of the primary reasons I liked them was that their API is REALLY fast at making changes to the files (you make the call and 100ms later the file attributes / content have been updated throughout all their delivery locations) and the interface is pretty easy to use.
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).
Is privacy in the UK really going to be that much better over the coming years in comparison to the US? For company based in the EU I would've said so, for the UK I'm not too sure.
Up until now, theoretically they had the GDPR which is a strong privacy regulation. Enforcement of it has been significantly lacking though (but frankly, so is everywhere else) so in practice the effect of it was dubious.
Now since they are no longer in the EU they want to use this opportunity to deviate from the GDPR and relax the rules even more (not that they've been enforced to begin with). Ironically, the justification for relaxing the rules is that the GDPR didn't have the expected effects - well of course if won't have any effect if you don't enforce it.
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.
"Which is an imperfect solution at best, and given I have no idea who bunny.net is it's a questionable solution at best."
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.
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.
The thing is that if you have resources on google.com, they may be allowed to set a cookie. And large companies like Google can far more effectively aggregate the data because of their reach.
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).
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.
I don't think it's laziness. My conscious brain knows that it's anachronistic, but I still have the instinct to use a CDN for the shared caching between sites. Obviously, browser privacy changes mean that isn't a valid reason any more, but for me the instinct is still there.
I'm not talking about setting up a CDN for custom assets, I'm talking about using something like jsdelivr or Google Fonts. Back in the day using those was a "best practice" because most people would (in theory) already have whatever font/library you're using cached. A lot of people, myself included, still have that as a habit that takes conscious effort to avoid falling into.
Sure, not all sites need them custom fonts; I hate when I’m reading a page and it reflows because the font changed, but there’s legitimate uses for fonts. Case in point: icon fonts that work using the “private use area” in Unicode.
I always opt for self-hosting, be it fonts or other assets.
Sometimes I am briefly envious of the ability to use things like Google Fonts, Unpkg or polyfill.io when setting up a project.
But I started doing web dev in 2018 when GDPR was introduced here, and I always was kind of paranoid regarding that.
Self-hosting is probably a better habit to acquire anyway, the only alternative being explicitly contracting with a company that offers edge CDN.
> As an added bonus, hosting fonts on your own server is faster as it goes through the same HTTP connection.
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.
I'm an American and I have next to zero trust for governments in general. "Absolute power corrupts absolutely" and humanity has given too few entirely too much "absolute power". I feel much the same about most of the massive corporate entities as well.
The difference is Europe is better at restricting corporate overreach than the US is, regardless of how similar their governments have become. That said, I'd take almost any European government over any US government of my entire lifetime, especially when it comes to actually enacting privacy legislation.
I couldn't care less about web fonts though. I'm not downloading them from Google or "bunny.net" or anywhere else. My computer has some of the nicest-looking fonts around as system defaults, and websites can either work with that or get put into reader mode.
Yep, and also the whole EU... Every few months, they either want to make encrpytion illegal, scan more private data, scan files on end user devices, outright ban e2e encryption, or worse.
And we can thank EU for the extremely annoying cookie pop-up’s on every website. Every site has a slightly different UI and the options/button labels always vary. Declining is always a multi-step process with various checkboxes.
They are never geo-filtered either so everyone is forced to see them.
I’m usually a big advocate for privacy and this was obviously done with good intentions but there were so many better ways to do it and I doubt 99% of people do anything but click okay without reading it.
At least if the browsers did it the UI would be standardized and you could have default persistent settings.
Now that there has been a massive effort to implement it I doubt it will ever get fixed or go away. Even though the decline of supercookies and Firefox’s new 3rd party policy has largely made it obsolete.
>And we can thank EU for the extremely annoying cookie pop-up’s on every website. Every site has a slightly different UI and the options/button labels always vary. Declining is always a multi-step process with various checkboxes.
No we can't. We can think of scummy adtech companies who feel entitled to their business model.
The GDPR very specifically says that the option to decline tracking must be at least as easily accessible as the option to accept.
The only way the EU is to blame for the pop-ups is that the regulation hasn't been enforced strictly enough.
In this case the problem with GDPR is not how it's written but how it's enforced (or rather, how little it's enforced). Most of the cookie popups that appear while browsing are already blatant violations of the law, but the violators get away with them because the relevant authorities are overwhelmed/underfunded/dysfunctional.
>If they asked anyone with atleast a minimal technical knowledge, they'd get a lot better solutions.
This sentence implies that: (1) Nobody with even minimal technical knowledge was consulted when writing GDPR. (2) The problem of websites tracking their users can be solved through technical means. (3) One or more of the solutions are so trivial anyone with minimal technical knowledge could come up with them.
> And we can thank EU for the extremely annoying cookie pop-up’s on every website. Every site has a slightly different UI and the options/button labels always vary. Declining is always a multi-step process with various checkboxes.
I don't understand this line of thinking. You are declining the cookies, so obviously you prefer not to be tracked. And it's obvious that it's not the EU who made the varying, annoying, and often purposely misleading dialog boxes to decline the cookies, but the companies who want to force their tracking on you. Without the EU law, they would just do it without asking for permission. So why blame the EU?
Of course the outcome of random unfriendly and annoying UIs is the only predictable outcome... so why wouldn't the EU responsible? Who else would be?
Would some design guidelines be helpful? Maybe but it's still fundamentally flawed and I doubt it'd be enforced.
As I said the only possible option where there could be design cohesion is via the browsers (or maybe a EU-controlled open source JS plugin but that's even worse).
I don't ever use the cookie popups because fine-tune control of cookies doesn't have much privacy ROI. I want to use cookies on most sites and ublock does the rest.
I highly, highly doubt the tiny percentage of people not using an adblocker but are still technical enough to uses cookie popups regularly and effectively is really worth the cost.
I get the impression people want this to be a good idea, because it sounds like one, instead of considering whether it is.
Has the ever been a study that shows the real-world utility of forcing sites to use cookie popups?
> Of course the outcome of random unfriendly and annoying UIs is the only predictable outcome... so why wouldn't the EU responsible? Who else would be?
"Of course burglars choosing less protected houses is the only predictable outcome... so why wouldn't the makers of security systems be responsible? Who else would be?"
I still don't get it. Without the EU laws, it wouldn't be magically easier to block tracking cookies, they wouldn't offer a choice at all? What are you arguing for?
> As I said the only possible option where there could be design cohesion is via the browsers (or maybe a EU-controlled open source JS plugin but that's even worse).
> I don't ever use the cookie popups because fine-tune control of cookies doesn't have much privacy ROI. I want to use cookies on most sites and ublock does the rest.
The cookies for functionality/session are not affected by the cookie popup.
> I highly, highly doubt the tiny percentage of people not using an adblocker but are still technical enough to uses cookie popups regularly and effectively is really worth the cost.
I use an adblocker and still decline on the cookie popups. I assume you are doing, too, otherwise you wouldn't complain about popups you don't see?
> Has the ever been a study that shows the real-world utility of forcing sites to use cookie popups?
Me able to decline them is real-world utility. If a majority or at least significant portion of users is successfully tricked into accepting the cookies, then that calls for a refinement of the law along with better enforcement, not for retraction of the law. "Let them have it", what a bleak, defeatist thing to suggest.
You are blaming the makers of the law for what is very obviously the fault of the perpetrators, who are trying to get around the law in profoundly shady and just downright shitty ways.
I am glad the EU law exists, without it there wouldn't even be the option.
Client side blocking (by that I mean removing them after the tab/page close)? First for third party cookies, then for all of them, and add a "button" next to the url bar, to enable cookies for that specific site (to allow logins).
This breaks multiple desirable uses of cookies, unless they're explicitly allowed on a per-site basis. It doesn't help if a site uses cookies for both desirable and undesirable purposes. If this solution became ubiquitous, I'd predict websites would start showing popup banners nagging you to click the "enable cookies" button from next to the URL bar. Finally, even if this did work to stop websites from tracking users via cookies, the data harvesters would simply keep using non-cookie tracking methods like browser fingerprinting.
In contrast, the GDPR does not place requirements for cookies if they're not used for storing or processing personal data (the ePrivacy directive which I'm less familiar with might require a notification about them). It does not even require a popup or user's confirmation if personal data is processed on a legal basis other than consent (though these uses may need to be listed in some kind of available privacy policy document). Finally, as GDPR is mostly technology agnostic, its requirements remain the same regardless of whether the data collection is done using cookies or any other means.
Feigning ignorance. People in or adjacent to the tech surveillance industry (either working in it or having a substantial portion of their net worth invested in the industry) whine about cookie consents constantly, but nobody else gives a shit.
Are you telling me that you have no financial or professional stake in the matter? You haven't worked for or invested in a company that profits from tracking people online? Nor any of your friends or family?
My understanding of privacy international privacy stuff is if a European gov wants to spy on their own citizens, but the law prevents them, they phone up the USA and have the USA do the spying(hacking?) and get the data from them.
European countries do the same for USA gov on US citizens.
> In the US at least, any spying is illegal when both parties are within the US
And no doubt it must be even more illegal to then perjure yourself in front of congress about not having engaged in such illegal spying, when in fact you have.
And, who ever got executed for spying domestically? Who ever got a prison sentence in line with the rough prison sentences the US happily gives out for much lesser offenses? Wo ever got so much as a bad performance review?
People are talking about the possibility of being spied on by governments. I think if you’re targeted by government or intelligence agencies, then even self hosting most likely won’t save you from them.
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.
Goverments and intelligence agencies can't target everyone. But they can gather data for future use. So if you don't give them your data you won't be targeted in the future.
This goes both ways, the lack of the usual amount of data about you is a data point in itself.
`SELECT * from citizens where data_points < 50;`
And then somebody aims a botnet armed with zero-days in your direction. But yeah, that requires dedicated adversaries that actually notice you -- which is not a given, I'll agree.
This is a good point. I would say we shouldn’t make it easy for the governments to access the data as well as private interest or companies. These are not mutually exclusive.
EU privacy laws are a step in the right direction. It’s progress. We can build on it.
Surely you realize that if a modern sophisticated government wants to see your data, they are going to be able to access it, even if it’s stored in the Netherlands? What threat are you protecting yourself against?
If the government wants to go after you in specific? You might be screwed. If the government wants to identify "criminals/degenerates" by checking against sexualPreference="gay", semitic="yes", numAbortions > 0. Then you at least wont turn up because that would require a lot more effort.
> What threat are you protecting yourself against?
Against modern sophisticated governments who are busy, lazy, distracted to ask Netherlands to give them my data. I'm not exactly a high priority target. All I have to do is to make it a little harder for them to access my data.
Why not? Make encrypted backups with `borg` and use `rclone` to distribute them to a number of free cloud storage services -- this is what I and many others do. One of my destinations is Yandex Disk. They all only see an encrypted Borg repo. And in the next few weeks or months I'll make sure they won't even be seeing that. Just a few opaque files several tens of megabytes big each. I wish them luck cracking it, lol.
What are they going to do, fly to my fringe country, knock on my door and politely ask me to stop storing encrypted blobs on their servers? No, they will not. First, their TOC does not forbid it and second, they are way too lazy to scope me out of the crowd, and third, they will only start shutting users down if their free plan starts costing them too much. I've been doing this for years and nobody seems to give a frak (Google included).
And I am just a regular guy who wants to make sure his code and passion projects (and personal / family photos) are never going to get lost even in a case of disaster. I never in my life did anything to warrant government attention.
Contrary to the weird Cold War sensibilities that rule a lot of HN's collective mindset for some reason, to me using Yandex Mail is no worse than using GMail.
Let's be honest: all those big players sing all our data to whoever they like, any moment they like. Pretending one is better than another is dishonest.
Have you considered that Switzerland and Netherlands might just, you know, hand other agencies your data without telling you?
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... ¯\_(ツ)_/¯
The internet culture's understanding of Swiss privacy laws are laughable at best. Switzerland has existing laws to any and everything for records.
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.
Between the joke of an energy policy in Germany this year and Douglas Murray’s books I have no confidence in European governments either. I used to feel Europe’s system was more competent but the illusion has been shattered.
To add to that now every other website has an annoying and useless cookie dialog I have to dismiss, as if that's forward progress in privacy protection.
That is the website owners implementing the rules in the worst way possible, either through incompetence or through deliberately trying to annoy (or fool) you into accepting everything.
Can I be angry at both? Legislation is only required to regulate bad behavior by some set of entities. As such, legislation should be written assuming that those entities will exploit any loopholes. Malicious compliance is exactly what the EU should have expected and planned for.
Well, not quite. They are forced to stop hiding what they were doing. They could make everything opt-in, and it could be simple single checkbox or button, they are not forced to do any of what they are currently doing.
And if it makes people angry at the legislation, the lying back-stabbing “your privacy matters to us” arseholes in marketing are successfully making that goal backfire.
> Malicious compliance is exactly what the EU should have expected and planned for.
It usually isn't compliance, malicious or otherwise.
It is malicious “we know we are breaking both the letter and the intent, but we know they don't have resources to properly enforce against everyone, so we are going to chance it for as long as we can”. The vast majority of these consent systems are not compliant with any of the relevant regulations (ePrivacy Directive, GDPR, CCPA, …). They will fix it when they get a slap on the wrist. If they get anything it will be a slap or a warning because while anyone in their right mind is pretty sure that the non-compliance is deliberate, that is nigh-on impossible to conclusively prove.
> I don't think Americans and American companies understand how little trust rest of us have for the American government.
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.
That political party's actions are about weakening the federal government so as to make it easier for large corporations to behave abusively, not because of trust. States have less resources, and can be played against each other.
The public-facing excuse for Joe Q Public is "they can't be trusted!", "less taxes on your hard-earned money" (when corporate share of taxes has plunged from the 50-50 split it used to be, increasing individual taxes), "the government is not efficient" (usually because of lots of onerous regulations and reporting and oversight that, ahem, a certain political party insisted on to fight "abuse")
> That political party's actions are about weakening the federal government so as to make it easier for large corporations to behave abusively, not because of trust.
Can you think of a reason people would do that if they didn't trust those corporations more than the federal government?
... and, at the same time, to radically increasing government spending literally everywhere except where there might be a possibility of benefit for an individual who needs help (just because said individual could possibly be ("a") black).
I’m surprised you emphasized government wrt. privacy here. Sure, despite the fact that the US government institutions have more mechanisms for oversight and transparency after 20 or 40 years, etc., they are certainly the most profligate in their use of surveillance and hacking, etc., and US three letter agencies are the most adept at completely side-stepping those publicized limitations — so it’s not like the government isn’t an issue, and the US government most of all.
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.
Fair enough, and in a sense I don't even really disagree, but my point is essentially that self-hosting eliminates the class of problems almost entirely, meaning there would be no need to rely on this kind of 2nd order competition at all.
I always had the suspicion that the (seemingly higher) interest in privacy/FOSS in Europeans is fueled partly by anti-Americanism. In America, even if you don't trust the government, at least it's your government, so I don't feel like that plays as big a role, and any interest in privacy/FOSS (like mine) is untempered by the anxiety of an alien government's interference. :p Regardless, I love how much more Europeans seem to value privacy.
> I always had the suspicion that the (seemingly higher) interest in privacy/FOSS in Europeans is fueled partly by anti-Americanism.
Of course it is. After American Wars in the Middle East killed and displaced millions, there is good reason to be wary of Americans and the American government.
How do the laws play out in practice? If bunny.net started storing user agent and IP address information indefinitely, and someone complained, how likely is it enforcement action is actually enacted on them? It seems such a low-impact privacy violation would be a waste of time for a GDPR/etc agency to focus on compared to things like ad companies selling location data.
I think this is important to consider. In practice, it's difficult to have any recourse with an American company. In Europe it's more expected and common that government and consumer orgs take an active role. Both legal culture and culture-culture (?) are just very different, leading people to preferring to steer clear of this expensive and adversarial (compared to EU climes) environment.
That's the exact scentiment the parent to my comment is suggesting; I'm saying that GDPR agencies probably aren't going to care at all about the type of data sent to a web host when all they're doing is serving fonts for 3p websites.
Unless you're under a totalitarian government, spies aren't really interested in most people's data. Data brokers, on the other hand, are willing to sell anything they can profit from.
You can't use the internet without risk. All you can do is measure relative risks and decide which are acceptable. Means, motive, and opportunity matter. Someone who is missing the motive portion is less of a concern than someone who has all three.
No one expects zero risk, it's about reducing risk. I choose to avoid American companies in favour of non-American competitors because the American government is hostile to privacy and is a warmonger.
90%+ of governments are more hostile to privacy than the US. It might make sense to prefer countries with GDPR, but the vast majority of "non-American countries" have even worse protections for your data.
> and is a warmonger.
This is flamebait unrelated to data privacy risk. If you don't want to use American companies because you have an political opposition to supporting US companies, that's also a valid opinion. You don't have to twist it into a data privacy argument.
> This is flamebait unrelated to data privacy risk.
It's not flamebait, it's a legitimate reason. A country who has been killing people in various wars/invasions is unlikely to behave ethically when it comes to privacy.
If you behave unethically in one area, I have every reason to assume that you'll also behave unethically in another area.
The number of governments that have not had to deal with ethics concerns is exactly zero.
Rather than drawing a broad hand-wavy link between ethics concerns and respect for privacy, you'd be much more accurate in measuring privacy by directly considering their practical legal frameworks that protect privacy.
> A country who has been killing people in various wars/invasions is unlikely to behave ethically when it comes to privacy.
This doesn't hold up. There are many countries that will straight up man-in-the-middle internet traffic with no oversight that have been at peace longer than Germany.
This is simply not factual, it is an information availability bias. America is one of the most publicized nations, and sunlight is one of the best disinfectants. By any academically rigorous measure, the US ranks high in ethics, along with most other western style democratic systems.
Tell that to the people that were killed by American military in Iraq, Afganistan, Libya, Syria, Pakistan, Yemen and probably other places I am forgetting.
A country like America that has been murdering people in many wars around the world without hesitation is unlikely to take my privacy seriously. They don't respect my right to live, do you think they will respect my right to privacy?
Maybe, but that doesn’t have any relation to the state of data privacy in a particular country. Most of the countries with almost no data protection at all (or laws that require your data to be compromised) don’t even have drones.
Can you please stop posting unsubstantive and/or flamebait comments to HN? You've unfortunately been doing it a lot lately. It's not what this site is for, and it destroys what it is for.
I can understand why people have strongly held views about foreign policy but this sort of political flamewar is repetitive and predictable, and therefore off topic here. It has veered particularly extremely off topic in a "Bunny fonts" thread. And I'm afraid you've been posting flamebaity/unsubstantive comments in other threads too.
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.
We can reasonably assume that bunny.net doesn't also correlate, cross-link, and permanently store which sites our IPs visit, for the purposes of enhanced ad delivery. Which Google does: that's literally what every single service they offer does in addition to "the thing you need that service for". Even sites that don't offer Google ads or Google analytics _still provide Google with behavioural data linked to you_ by using Google fonts.
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.
I don't think we can reasonably assume either of those things. You're speculating about both Google Fonts and Bunny fonts based on very little information.
No, and yes, respectively. If you consider "Google recording and monteizing on CORS URL requests" speculation, I'm not sure you know much about the company we're talking about here. They've been sued and fined over tracking quite a number of times.
Do we know whether bunny.net is any better? In the abstract, no we don't, but we're not dealing in abstracts, so we actually do because of where they operate. A real European operation (not an international company with EU presence but an HQ outside of direct EU jurisdiction) is by default quite a bit better at not violating GDPR, and runs the actual risk of being fined into financial insolvency (rather than getting a few hundred million slap on wrist that a multibillion dollar company goes "pff, whatever, let legal sort it out" to).
By virtue of Google's track record, and by virtue of where this new service is located, and the track record of EU based services with regards to privacy compared to their US counterparts:
Yes, we can _very_ reasonably assume both of those things.
I never cease to be amazed at the number of people who make self-validating proclamations about what Google does or doesn't do, without having any information to support their positions.
I guess I'll say what I always say: Look at the public privacy statements for Google, or for a particular Google product. If you have any evidence that Google does anything different from what's in that statement, contact Google and there will definitely be people interested in figuring out what's going on and fixing it.
Do not use this, use Google Fonts, just self-host them. This site claims better privacy, but does so using the wrong solution since you still have to trust them.
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.
Flash of Unstyled Content and Flash of Invisible Text.
* 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.
It's super trivial to outsource the sub setting to Google Fonts. Just request their CSS and curl the font files referenced in it. If that is too tedious, build a small proxy.
Fair enough, if you only want to avoid Google for the hosting you could just copy their fonts and be done with it, yes.
(And in my case that whole effort wasn't actually so much for philosophical reasons, i.e. to try avoiding to use Google at all costs, but rather because Google Fonts was serving an outdated version of the font I was wanting to use, and was missing either some additional characters or bug fixes that were only added in a more recent version.)
> 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
Perhaps the dog had cornered the fox, but in an a location that the dog couldn't reach. So it decided to wait the fox out, but then fell asleep because it is lazy.
This is a great project, but I learned to use a system font stack[0] instead to address latency issues on my sites. I run an e-commerce site and every millisecond in rendering time is potentially a lost sale. It needs to be fast, especially for those on 3G (or 2G?) connections.
The particular stacks advocated by that site aren’t particularly good (though they’re not all that bad either). It was discussed at https://news.ycombinator.com/item?id=31543054 a few weeks ago.
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.
Superfluous: it’s there for Android, but I believe that sans-serif will normally resolve to that anyway.
(I’m not certain about that, and can’t confirm it as I don’t have ready access to Chrome on Android but I got the impression some years ago that Chrome on Android uses the system font, which is Roboto. But even apart from that, the general idea is “stop specifying specific fonts and let the browser do its thing and the user get their chosen fonts, unless what the browser does by default is too bad, like Courier New for monospace”.)
Including its name doesn’t mean it’s available. Or that it should necessarily be used even if it is—when the purpose of including Roboto was to get a default font, you probably shouldn’t complain when you get a default font.
I suppose the reasoning behind having it might be that Android devices typically also have one of the fonts that appears lower in the stack, but before sans-serif... though that's not as likely if you're using a much smaller stack (also it's already quite near the end so... not sure why its typically used... could indeed be just trying to opt out of some manufacturers' undesirable alternative defaults, maybe).
I have a question about system fonts. Whenever I declare system fonts I always use: `serif`, `sans-serif`, or `monospaced` rather than the actual fonts like:
The system font stacks are trying to target the fonts that the operating system uses by default (e.g., using San Francisco as the sans serif font on a Mac). If you just use "serif", "sans-serif", and "monospaced", you're targeting the fonts that the browser uses by default, which probably aren't the same fonts.
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.)
Browsers "fixed" the problem by adding system-ui, ui-sans-serif and ui-serif.
I guess displaying an ugly font was important for backwards compatibility so instead of fixing millions of existing wrbsites they created new keywords that you need to opt into.
No, you're not doing anything wrong. In fact, you're giving users choice to use the fonts that they want, if they customize their fonts in their web browser. However, this choice comes at the cost of potentially ugly default fonts out of the box. Courier New, Times New Roman, Arial, for example. Of course, this is completely subjective.
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.
No, it's a matter of preference. The default fonts in some browsers are pretty ugly, so if you want at least a chance of getting a better font, you can use a stack like this. But it's fine if you don't.
> The default fonts in some browsers are pretty ugly
Is this really the case anymore these days? I think Firefox uses Courier New on Windows as the default monospaced font, but other than that I'm not aware of popular browsers using terrible fonts by default.
A nice aspect of using just serif or sans-serif is that users who configured their browser's font options get what they chose.
I'm still not entirely sure why anyone would load fonts from a 3rd party link that's bound to break sometime. Just add it to your assets like a normal person and Cloudflare will cache it for you anyway.
The 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.
> The license is non-standard too, something called SIL. I'm not gonna bother looking up what that weird thing permits
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.
It’s also good because Google almost certainly uses data from Fonts for selling ads. I’m much more concerned about that than the theoretical uses by the US Govt, though I’m not a fan of those either.
Thank you for saying this. Memory suggested that this was the case; I think one problem that happens on this site is that people distrust Google so much that they will trust some completely unknown organization that they've never heard of before over one (Google) that has presumably made themselves legally liable if they use your data to track you.
(I would also note to everyone that you can simply disable sending referrers third party, which means that even if Google is using this data to track you, they won't know what sites you are visiting unless those sites use very specific combinations of fonts.)
The Google Fonts API is designed to limit the collection, storage, and use of end-user data to only what is needed to serve fonts efficiently.
There's an awful lot of weasel words in there.
If it was a simple "The Google Fonts API doesn't collect or store any user data" that would be good. But there's so much hidden language in that one sentence.
- "Designed" — Well, it was designed to do that, but it doesn't. After we're caught, we'll put out a press release saying We Can Do Better™.
- "Limit" - It limits the collection. It doesn't prevent the collection. It doesn't not collect any data. It just collects "limited" data. And "limited" is defined by us and can be revised whenever we want.
- "collection, storage, and use of end-user data" has so many ways to be abused.
- "efficiently" — Efficient for who? Google? Google's advertising department? Google's profiling department? What if there's an inefficient way? What if there's a more efficient way, but it gives Google less data?
All this may seem unkind, but Google has earned the planet's distrust. In the early years, Google didn't believe that reputation matters. It does. And that's why the legal departments of billion-dollar companies like the one I work for don't allow us to use Google products.
There is no such thing as absolute privacy. By virtue of being a web-hosted service, you will need to interact with the end server, and that already has the potential to expose details like IP, referer, user-agent, etc.
The wording around designing and limiting collection is acknowledging this inherent problem and letting the user know that they’ve done their best to prevent malice.
It’s not weasel wording except for anons who like hating on the internet.
Are you talking about the x-client-data header (which isn't unique, but is relatively high entropy at <= 13-bits)? [1] that is used for evaluating the effect of experiments that Chrome is running on other Google services, which does include ads. But it is not used for personalization (I wish they would say that publicly).
For example, when I look at a Google Fonts request in Chrome developer tools I see:
Each of those numbers represents an experimental treatment that is currently active for my Chrome instance. (It looks like more entropy because it's multiple values, but they're all derived from a single 13-bit per-instance seed.)
That is only true if-and-only-if we pretend those 13 bits are the only identifying information being sent to Google when requesting a font. The HTTP request is almost certainly being sent to Google wrapped inside an IP protocol packet. For most[1] requests, there are at least 24 additional bits (why 24? see: [3]) of very-identifying data in the IPv4 Source Address field. More fingerprinting can be probably done on other protocol fields, and IPv6 obviously adds an additional 96 bits. Yes, IP addresses are not unique, but ~13 bits is easily sufficient to disambiguate most hosts on a private network behind a typical NAT. Correlating the tuple {IPv4 Src Addr, x-client-data} received on a font request is trivial: it only requires a user to login to any Google webpage that includes a font request.
>> re: your [1]
A given Chrome installation may be participating in a number
of different variations (for different features) at the
same time. These fall into two categories:
Low entropy variations, which are randomized based
on a number from 0 to 7999 (13 bits) that's randomly
generated by each Chrome installation on the first run.
High entropy variations, which are randomized using
the usage statistics token for Chrome installations
that have usage statistics reporting enabled.
How many users have 'usage statistics reporting' enabled, and are there for a "High entropy variation"? Is it enabled by default and thus will only be disabled by the minority of people that know how to opt-out?
[1] Google reports[2] they currently see about a 60%/40% ratio of IPv4/IPv6.
leads me to believe that Google has PI when people visit sites using google fonts.
Even if they don't use it for advertising purposes long term log keeping is not required to serve fonts.
It doesn't really matter what the service is doing, they didn't ask for consent to log the IP of people downloading fonts.
To be perfectly clear: it wouldn't keep me from sleeping at night and fonts permissions should be bundled with cookie consent or there should be a permission prompt (just like when asking for youtube vid.).
"by including Google-Fonts-hosted font on its pages, passed the unidentified plaintiff's IP address to Google without authorization and without a legitimate reason for doing so"
It isn't about whether the IP address was logged, but about whether it was sent. Which is an unavoidable aspect of loading a resource from a server.
Secure from whom? The mob? China? The US government? Google?
I'm more worried about the last two than the first two. It'd be illegal for them to secure it against US law enforcement, and they don't claim they're secure the data they log against access from themselves.
Why wouldn't I just self-host the fonts on my server?
What are the benefits of such CDN? Years ago I could understand it because it may reduce latency (cache), but since browsers don't cache from 3rd party servers anymore, also this is argument is obsolet.
I just went through the process of self-hosting Google Fonts. The process is actually surprisingly tricky.
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.
Browsers don't use cross-site cache anymore (so if 2 sites are both using google fonts you don't get the speedup) but I think browsers still cache content from request to request for a domain.
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.
True that there's no 3rd party caching benefit anymore, but it's still just very convenient – select fonts a'la carte, copy the CSS/HTML snippet, paste it in, and that's it. All for free, no licensing considerations with Google Fonts.
Actually, it's only Google's sites I've seen it cause problems on, because some of their documentation makes use of icon fonts served from that CDN. Other sites have no problems in my experience. The font fallback works fine.
A CDN for this? Sorry, but just store the fonts on the same d**n server you're serving the site from. Files are tiny, it's not 1080p video we're talking.
Won’t that cause the fonts to download again if they were loaded by Google fonts? I thought the reason to use something like Google fonts was to have the fonts download only once.
That hasn’t worked for a while. Browsers will NOT use cached resources loaded for foo.com when loading bar.com, even if they are the same resource from the same CDN.
Web fonts are pretty small and only load if used, and loaded only if they're not cached. It's definitely added requests, but those can be deferred intelligently.
Reflowing is preventable using modern techniques, but honestly it doesn't seem like that big of a deal. The tradeoff is you get access to lots of different type options. More type options means more you can convey with type, which is a good thing for people who need to communicate on the web. It's more than just marketing sometimes.
Don't trust Google, trust us, a 30 person company.
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.
Google has a proven track record of being malicious and a business model that relies on it.
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.
Interesting and cool, although apparently no variable fonts[0] as yet. While it’s best to self-host whenever possible, this appears to be a great alternative to GFs if one isn’t willing or able to do that.
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.
- 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.
Websites can use whether or not a resource is cached (one way to measure that is how long it takes to load) to uniquely identify your browser and track you across the internet.
Another attack is to determine if you visited $popularWebsite by checking if resources it uses are cached (this could be useful to, for example, the Chinese government for surveillance on its citizens).
Thank you. I've been thinking about your comment for 3 days, believe it or not.
It seems like:
- Only standard resources ought to be cached (e.g. D3, common fonts, etc.). Perhaps these could be a free registration with the browser maker (e.g. I can always get them from cdn.mozilla.org or something), with some constraints (e.g. minimum number of users, some delay, or similar). As a user, I ought to have the option to cache *all* of these (which is helpful in bandwidth-constrained settings), either on my machine or on a proxy. If I'm at caltech, I can repoint my browser to grab these from localbox.caltech.edu.
- These shouldn't offer a unique fingerprint, since it only works once. If I needed to load comic-sans.ttf, I won't need to load it next time.
- I might be able to set a fingerprint (e.g. ask you to load 25 resources, and check if they're cached), but that's really for cross-site tracking (for which there are easier mechanisms), and it only works once. Once you've cached a resource, it's cached nearly forever. Your fingerprint changes each time, so it's not really traceable.
I had a similar idea. In addition to caching and detecting if it has been unexpectedly changed, there are other benefits:
- 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.
I'd suggest stop using 3rd party font hosting altogether and adopt something like Fontsource [1]. That way, no reliance on 3rd parties, full privacy, and full control over font file changes (yeah, apparently, fonts are changed from time to time).
And I am supposed to believe a semi-pretty marketing site that they don't do server statistics gathering that they periodically sell to Google, Facebook and any other data brokers?
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.
How many fonts do people use on their websites? 2-3? Just host them on your server. It will add 2-3 more requests when user first loads you websites but after that fonts are cached so no more additional requests.
After changing the sample text on fonts.bunny.net to something that is non-English, all missing characters are all rendered with the same font. Chrome inspector will show the actual font being used under "Rendered fonts", and it appears to be whatever the locally configured fallback is.
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.
While we're talking about privacy and CDN delivery, check out Decentraleyes. It's a browser extension which keeps a local cache of common CDN-delivered files.
Pointless to move from one CDN to another for this. Also their performance is rather poor and about 10x higher latency compared to Google fonts.
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.
Tangentially related -- I just want bloggers to think twice before choosing (mis|ab)used Google Fonts just because they look "fancier" at first sight. Lato and Merriweather have become Arial and Times New Roman of our time.
I wonder if browser manufacturers could do a better job of this by just keeping a list of junk that > 99% of web browsers will eventually download anyway, and then just prefetching it all at initial install.
One of the numerous advantages of of text-only www, as seen through a text-only browser, is that CSS and Javascript do not matter.
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.
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.