Google fonts

[pythonmobile]

I saw this issue closed, and wanted to bring your attention to it once agian:

Requesting stuff from https://fonts.googleapis.com/ is very slow, especially with SSL enabled - perhaps we should consider adding the fonts into the Git repo so that they can be served from the local server?

Its not just that, its also a security hazard, as far as I understand.

Can you perhaps post a howto for newbies on how to get rid of google's fonts and serve them locally?

Thanks.

[thomaspark]

Here's a StackOverflow post on how you might host Google web fonts yourself: http://stackoverflow.com/questions/8966740/what-is-the-correct-way-of-hosting-google-web-fonts-on-my-own-server

My take is that in most cases, the performance and convenience of using Google will outweigh any benefits (and complications) of hosting it yourself. As far as I know, there isn't a significant security hazard there.

If you're not serving anything else over https, you can always improve performance by editing Google Web Font imports in the CSS to use http or go protocol-relative. It's only set to https by default to avoid mixed content warnings: http://msdn.microsoft.com/en-us/library/ee264315(v=vs.85).aspx.

[rwe]

@thomaspark, @pythonmobile Pull request #60 should resolve this—there's no reason I'm aware of that the imports shouldn't all be protocol-relative in the stylesheets. Making them so fixes the mixed-content warnings when served over SSL and improves performance otherwise.

[pythonmobile]

I am a newbie to security. I am making a website for a client that has money involved (assume a bank's website). Is it safe to let google serve its fonts to such a website? Couldn't google run any JS from their end on the site I create?

[rwe]

@pythonmobile

There do exist some CSS XSS attack vectors. You should only embed resources from hosts you trust, which means either (1) trust the host (Google, NetDNA, etc.), (2) host it yourself, or (3) deem it an acceptable risk.

If you're really doing a bank's website in which actual banking is involved, you'll at least want (1) a security expert on your team and (2) an external security audit. Basically, if you need to ask this question you should involve someone else who already knows.

[chrismalek]

See this article.

http://www.amixa.com/blog/2012/06/06/how-to-use-google-fonts-under-both-ssl-and-non-ssl-without-ssl-insecure-messages/

I had to tweak the awesome bootswatch themes for my ssl pages

[rwe]

@chrismalek If I'm not mistaken, that's exactly the change that was made in #60.

[chrismalek]

o…maybe i don't have the latest

[thomaspark]

Yup, protocol relative URLs have been implemented. What this issue is requesting though is to add Google web fonts to the repo itself. I don't think I wanna get in the web font business.

[sergeychernyshev]

There are performance and cross-browser compatibility reasons why using Google Fonts from Google's servers is a good idea, similar to JQuery CDN hosting and etc. Here's the video about this: https://www.youtube.com/watch?v=sqesm0euf9M

At the same time, relying on 3rd party hosts is indeed a problem for some cases, like local development without network support, for example, so giving users an option to use local fonts while keeping Google-hosted option is still a good idea.

[pythonmobile]

I agree Sergey. How hard is it to let users decide if they want to serve
the font from local machine vs google? That is what Thomas is afraid of -
too much work to handle localhost fonts.

On Wed, Jan 23, 2013 at 10:35 AM, Sergey Chernyshev <
notifications@github.com> wrote:

There are performance and cross-browser compatibility reasons why using
Google Fonts from Google's servers is a good idea, similar to JQuery CDN
hosting and etc. Here's the video about this:
https://www.youtube.com/watch?v=sqesm0euf9M

At the same time, relying on 3rd party hosts is indeed a problem for some
cases, like local development without network support, for example, so
giving users an option to use local fonts while keeping Google-hosted
option is still a good idea.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-12600638.

[sergeychernyshev]

@pythonmobile - not sure about all the details, clearly your server will not optimize as effectively as Google's, but configuring Apache with simple .htaccess and having a pack of font file is a relatively simple thing to do.

I'm not saying that local fonts should be a default, but an option for those who want their fonts in their control (even if only for development without connectivity)

[bui]

I believe protocol-relative font imports are a bad idea. If someone is developing locally, Bootswatch CSS will try to request file://fonts.googleapis.com/css?family=Ubuntu (or another font).

If you add the HTTP protocol, pages served through HTTPS would get get warnings, so HTTPS would pretty much be the only choice.

[thomaspark]

One of the downsides of the protocol relative url. But you can get around it by running a local server during development, e.g. MAMP or this command:

python -m SimpleHTTPServer

[ibell]

I'd like to ping this issue again. I ran into exactly this issue, it is not nice to HAVE to have internet access to use the generated HTML pages.

[thomaspark]

For themes that use a custom font, @web-path-font variable was added a little while back, which you can set to a local copy in LESS or SASS (#507).

You could combine this with something like grunt-local-googlefont to get what you need.

[bioteck]

And if you don't want to import any font? I use "Arial" so I don't need this import. But Bootswatch does not leave the choice:

@web-font-path: "https://fonts.googleapis.com/css?family=Lato:400,700,400italic";

.web-font(@path) {
  @import url("@{path}");
}
.web-font(@web-font-path);

So I did this to clear the import:

@web-font-path: '/empty.css';

But this is not a clean solution...

[ARS81]

Same problem here :( A fix for this situation could be something like this:

//.web-font(@path) {
.web-font (@path) when (isstring(@path)) {
  @import url("@{path}");
}
.web-font(@web-font-path);

than we could use as:

@import "theme/bootswatch.less";
@web-font-path: false;

This way we have the option to use another font or disable importing the font by css, instead link our font(s) in the html head.

[thomaspark]

That's a nice solution. Works great in LESS, but something equivalent should also be supported in SASS through the convert_less grunt task, which might be tricky.

[ofbeaton]

I ran into this problem as well. I use bootswatch on internal network without internet. I didn't really want to have to compile the less/sass myself, or edit the .css file to remove the import... but that's what I ended up doing.

[alex-sherwin]

When using the bootswatch npm package, it's not really desirable to modify the sources to prevent loading of assets from external CDNs

The best I could come up with, when using a sass theme, was to change the import url to an empty data url before loading the theme. This seemed to do the trick for me without needing to modify the upstream sources and prevents the browser from making any HTTP requests at all.

$web-font-path: 'data:text/css;base64,';
@import '~bootswatch/paper/bootswatch';