Skip to content
This repository has been archived by the owner. It is now read-only.

Add popular Google Fonts to the bundle #34

Open
notatestuser opened this issue Feb 4, 2016 · 23 comments

Comments

Projects
None yet
10 participants
@notatestuser
Copy link

commented Feb 4, 2016

Plenty of sites use these. Could we mirror them in decentraleyes?

@Synzvato Synzvato added the request label Feb 6, 2016

@Synzvato

This comment has been minimized.

Copy link
Owner

commented Feb 6, 2016

Thanks for the suggestion!

In theory yes. As of now, Decentraleyes does not support non-script files (e.g. fonts or styles). Once it does, it might indeed be an idea to start serving some of the web's most popular fonts.

Semi-related issues (see answers): #32, #37

@Synzvato Synzvato closed this Feb 6, 2016

@heforfree

This comment has been minimized.

Copy link

commented Feb 6, 2016

@Synzvato

This comment has been minimized.

Copy link
Owner

commented Feb 6, 2016

@heforfree Thanks for sharing, will read!

@Gitoffthelawn

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2016

Downloading from Google fonts is probably the most rampant. At the same time, there are a few other common font CDN's that can be included as well.

@Gitoffthelawn

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2016

@Synzvato Do you want to re-open this issue since #60 indicates that this may be a new feature?

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.

Using javascript, it is trivial to detect some of the most commonly installed fonts.

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.

@Gitoffthelawn

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2016

I've been testing the idea proposed in the above comment, and so far, it is working quite well.

@notatestuser

This comment has been minimized.

Copy link
Author

commented May 1, 2016

Neat. Is there a clever way to deal with the fact that some custom font-faces use different names for system fonts? There can be subtle differences (missing spaces, added numbers, etc.) For example: HelveticaNeue

@Gitoffthelawn

This comment has been minimized.

Copy link
Contributor

commented May 1, 2016

@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. ;-)

@Synzvato Synzvato reopened this Oct 16, 2017

@Synzvato Synzvato changed the title Consider mirroring Google Fonts Add popular Google Fonts to the bundle Nov 26, 2017

@AshotN

This comment has been minimized.

Copy link

commented Dec 13, 2017

Any updates in regards to this?

@Synzvato

This comment has been minimized.

Copy link
Owner

commented Dec 13, 2017

@AshotN Resource additions are temporarily blocked by (1419459). Please see #16 for more details.

@henri98

This comment has been minimized.

Copy link

commented Apr 11, 2018

Any updates on this?

@CHEF-KOCH

This comment has been minimized.

Copy link

commented May 5, 2018

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)?

@ronjouch

This comment has been minimized.

Copy link

commented May 5, 2018

@CHEF-KOCH

"Google's fonts are already open source"
[...]
"they could already have changed the fonts so you would be forced to keep an eye on it"

That's unrelated to the present discussion.

"integrating it as an own resource only causes more resource been wasted"

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 🙂, same as Decentraleyes already packages a chosen subset of js libs.

"even if you allow them externaly I see no reason how it compromises your privacy, it's well explained here"

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.

"If you don't like fonts you can already block them permanently or temporarily within uBlock/AdGuard etc. "

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.

"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"

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 🙂.

@CHEF-KOCH

This comment has been minimized.

Copy link

commented May 5, 2018

That's unrelated to the present discussion.

It's relevant since the web changes frequently. Font rendering got improved already since the OP started this discussion here. Different fonts look different in the same browser.

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 🙂, same as Decentraleyes already packages a chosen subset of js libs..

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.

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.

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).

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.

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 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.

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.

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.

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'.

@crssi

This comment has been minimized.

Copy link

commented May 5, 2018

@CHEF-KOCH
Don't you think that people does might not see fonts as a security problem, but as a tracking problem.
I personally like Decentraleyes for de-tracking reasons.
What is really your intentions here exactly?

@Synzvato

This comment has been minimized.

Copy link
Owner

commented May 6, 2018

@henri98, @ronjouch

I hope it can land someday [...].

I'm happy to say that addressing the underlying technical issues is top priority. Once that is done, adding support for popular webfonts should not take too long. In short, this feature is still on the roadmap.

@Gitoffthelawn

This comment has been minimized.

Copy link
Contributor

commented May 7, 2018

BTW, according to Google itself, "Google Fonts logs records of the CSS and the font file requests..." each and every time a person requests an uncached font from a Google server.

@shellshocker

This comment has been minimized.

Copy link

commented May 12, 2018

@CHEF-KOCH
@ALL

Just ignore this CHEF-KOCH. Mostly he does not know what he is talking about. He just produces text walls in different projects.

@CHEF-KOCH

This comment has been minimized.

Copy link

commented May 12, 2018

".. but as a tracking problem."

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.

BTW, according to Google itself, "Google Fonts logs records of the CSS and the font file requests..." each and every time a person requests an uncached font from a Google server.

That's copy & paste from what I already linked, I already explains that the font's itself doesn't do anything. The log processing here comes (in this case) from google. Once Google Javascript is blocked or the domain locally loaded nothing will be logged.

From this comment here.

Just note that Decentraleyes focuses on privacy rather than saving bandwidth, so solving this issue will most likely have lower priority.

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.

Just ignore this CHEF-KOCH. Mostly he does not know what he is talking about. He just produces text walls in different projects.

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 ...

@shellshocker

This comment has been minimized.

Copy link

commented May 14, 2018

Once again: Just ignore this guy (@CHEF-KOCH). He does not know what he is talking about.

@CHEF-KOCH

This comment has been minimized.

Copy link

commented May 15, 2018

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.

The attack as we have designed it relies on client-side execution of JavaScript.
Simply disabling JavaScript is unlikely to be an effective defense, however. Hei-
derich et al. [11] show how to use CSS to measure the size of DOM elements, for
example by shrinking a container through animation and causing its contents to
reflow.
A simple idea to eliminate variation due to font file availability is to ship a
set of standard fonts with the web browser, and use only those (plus download-
able web fonts), at the exclusion of any other fonts that may be installed on
the system. This approach has been suggested by Mowery and Schacham [16,
Section 5] and on the bug trackers of Mozilla [22] and Tor [21]

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.

@notatestuser

This comment has been minimized.

Copy link
Author

commented May 15, 2018

Thanks for participating in my thread, but this is simple - your IP and browser fingerprint are exposed because the font file must be downloaded from their servers. We’re not talking about JS execution. That’s the end of the discussion about this.

@shellshocker

This comment has been minimized.

Copy link

commented May 15, 2018

I told you. He (@CHEF-KOCH) does not know what he is talking about. It's simple: Start ignoring his bullshit. In other projects he is doing the same. It's really bad. -.-

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.