Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add popular Google Fonts to the bundle #34
Regardless, I have an interesting idea. I've noticed that many times the font requested from a CDN may already be present on the system, yet is still downloaded by the browser.
As such, until decentraleyes explicitly supports fonts, it could simply force the browser to use it's own system's fonts instead of downloading practically duplicate copies (for fonts that are installed). Yes, the system's fonts may not be absolutely 100% identical to the CDN fonts, but they are probably close enough for 99% of situations.
@notatestuser I'm not yet sure whether there is an integrated translation table like with PDF files. From what I've read of the browser's source code (so far) and what I've tested (so far), there is not. However, writing one as an overlay is rather simple.
Fonts can also be edited with a hex editor to change their names.
Even with these tricks, it does not solve the subtle differences you mention. From what I've tested so far, the impact of these subtle differences, fortunately, is negligible. I haven't found any issues yet, but I've only tested a few hundred sites... and the web has a few more sites than that. ;-)
I'm against this implementation Google's fonts are already open source and integrating it as an own resource only causes more resource been wasted for no benefit. In the meantime they could already have changed the fonts so you would be forced to keep an eye on it but even if you allow them externaly I see no reason how it compromises your privacy, it's well explained here. I think if you read it and compare this against GitHub and other pages it doesn't collect more information, I also haven't found any evidence that tracking fonts have any impact on security - it's external CDN which supports the tracking code, a font by itself doesn't track anything. The recently holes which got discovered back in 2015 are compromised by a remote code execution. However. this techniques is in general a security problem and not only relevant to fonts.
If you don't like fonts you can already block them permanently or temporarily within uBlock/AdGuard etc. If you just want to obfuscate from which domain you're coming you can set like several years now the noreferrer tag which also works in HTML5.
The possible tracking which people are often refer too are not the fonts, it is the fact that the page you like to visit or coming from like to set the cookies. So I don't see here what are the privacy benefits. I personally don't know what is wrong with the fonts which the Browser already includes, should't that be prefered compared to any external (CDN/addon integrated ones)?
That's unrelated to the present discussion.
If you take this stance, then all Decentraleyes should go to the wastebasket. Decentraleyes already takes the trade-off of an initial cost of pre-packaged commonly-used web resources vs. fetching them on demand. Also, note the adjective contained in this issue's title: "Add popular Google Fonts to the bundle", nobody's asking for a 300MB xpi
That's purely Google's word, can change at any time, can be enforced by governement mandates, and many netizens simply don't trust it.
Strawman (you're criticizing something something different from what is being argued). I (and users interested in this feature) certainly don't want to block fonts. Of course we could if we wanted to. This feature is precisely about preserving webfont UX. I do like neat fonts and take the crisp serifs served by Gfonts rather than stock OS fonts. Also, some sites may depend on glyphs present in these fonts and not in my OS fonts, meaning the loss due to blocking would be more than just visual.
There are many more ways to track people on the internet (see EFF's panopticlick). The threat with fonts may be mild, but at the most fundamental level, I don't especially like the idea of me requesting resources (logged by Google servers/CDNs) on half the web.
And I'm done contradicting, now to a simple & short positive assertion: packaging GoogleFonts in Decentraleyes would be valuable for the same reasons as packaging js libs is: performance and privacy.
I hope it can land someday
The OP nor you mention 'which' fonts exactly, if you do as the OP says it would exactly ends-up with a resource wasting addon without benefit. I see no argument to globally disallow fonts in e.g. Firefox (again what's wrong with the Browser ones?) - or to block them with known extensions like uBo - you even can per-site basis allow/block them.
Bring evidence, there is none that fonts by default are a security risk, it's not possible. The mentioned example from me points to a weak font driver which got exposed by remote code execution, that also affects Browser by itself and isn't a proof at all that the fonts are somewhat a security issue at all. The possible request to it might could be MITM (in theory) but to stay on the topic, Google's ones are delivered via HTTPS by default (since years).
I not even talked to you but okay. I was referring to OP which is should be the matter here. If you don't want to block fonts why replace them with others which are locally used? Doesn't make much sense when the Browser (as said) already includes all necessary fonts by default. There is then same like you would block it no network bandwidth 'wasted' and the same benefit are given except that you need an extension/addon to do that.
It's nice that you tell me which fonts you prefer but doesn't have to do anything with 'Google fonts'.
There is no font threat at all and there never was as I already explained. EFF also not give any proof how font detection has an security impact, all they do is to tell people it might expose metadata, yes we know it already but no one came up worth POC to show that this exposes you. If I post my Browser fonts in GitHub in public without context you think I'm insecure? Wrong, posting a comment here exposes me more - as a matter of fact.
Packing tons of fonts into an extension doesn't result in better performance not any privacy improvement. Please bring evidence. And I bring the counter evidence that my debug console shows more memory consumption (which can also expose you according to the same EFF logic) and an article that CDN load the tracking scripts not the fonts by itself.
I only hope this extension will never integrate it, otherwise I stop using it or revert it with a patch, b'cause once this will be integrated the next guy cries for 'now let's block another font provider xxy'.
Front doesn't track it's Google and others. Google also explaines this very well, the collected data here doesn't expose you anyway. It's to see what browser loads which fonts etc.
From this comment here.
Indeed and the ones who have no clue are people without proper research. Fonts itself do nothing and there open source.
Please stop @ALL spreading FUD to scare people, cause you have no clue, once again this is about JS not front. If there is fear about this, then simply block it.
That's called effort, maybe one day you do research at your own and not believe everything what's on the Internet. I only can hope you grow up. You comment is helpful somehow? Right ...
From the research paper Fingerprinting web users through font metrics. Keep in mind that this document is already outdated. It should also be mentioned that this requies a domain/site which uses actievly an exploit/attack in order to identify you. It's like using Panopticlick to show hey I'm possible vulnerable ... It's same logic like driving against a tree to proof that this is possible dangerous. In my eyes that should't be the goal at all.
Once again disabling JS/Cookies etc is already enough. I already said that there is nothing wrong with using Browser integrated fonts or using uBO, both have same bits 8 (you need 8+ bits in order to reveal someones identify [according to EFF wrong paper] [[cause their mathematical explanation doesn't respect several aspects like false positive while spoofing]] so in reality you need 10 bits). Even if I enable it and allow JS I currently see max 9,2 bits which is noth enough to expose me.
It's same story like with favicons, they don't expose anything while downloading, it's the curcumstances like placing the cookies or trying to fingerprint the connection itselt.
Fighting metadata is simply a mission impossible since there exist no protocol (and never will) which doesn't exlucde metadata.