Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Webfonts, the Spy Inside?

fontfeed.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Google Webfonts, the Spy Inside?

#71

Post by MichaelGG »

petercooper wrote: post #69
MichaelGG wrote: post #43

Earlier quoted context omitted.

A simple "noreferrer" (or referer if you like) tag on elements or in pages would solve a lot of this. 3rd parties would obviously still get the request, but they wouldn't know what page it comes from. Interesting that "norel" got adopted so quickly for spam. So it shouldn't be hard to have a "noreferrer" tag added, right? Yes, users can install addons to modify header behaviour, but site designers should be able to u…

So it shouldn't be hard to have a "noreferrer" tag added, right? It's so not hard that it's actually already a part of HTML5 and supported by several browsers :-) http://www.w3.org/TR/html5/links.html#rel-noreferrer

Seems like it isn't on link, image, or script elements though, which is the way most third party content gets loaded.

Re: Google Webfonts, the Spy Inside?

#72

Post by MichaelGG »

majika wrote: post #15

I use NoScript and Policeman on Firefox, with conservative settings (disallow all active content (scripts, fonts, WebGL), whitelist-only cross-site requests). I've also configured Firefox to block cookies by default; only permitted sites can store cookies for the session, and just a handful I allow permanent cookies. Web pages load much quicker, Firefox uses less resources, my browsing is significantly more secure (s…

The real quote there being:

" It really worries me that the FreeType font library is now being made to accept untrusted content from the web.

The library probably wasn't written under the assumption that it would be fed much more than local fonts from trusted vendors who are already installing arbitrary executable on a computer, and it's already had a handful of vulnerabilities found in it shortly after it first saw use in Firefox.

It is a very large library that actually includes a virtual machine that has been rewritten from pascal to single-threaded non-reentrant C to reentrant C... The code is extremely hairy and hard to review, especially for the VM.

"

FreeType's news page http://www.freetype.org/index.html#news - has something very curious. Two fixes for the same CVE, but the second fix 9 months later. A look at the CVEs[1] for it is also interesting that they're all memory safety issues (at least, from a quick glance). So in 2014, it's still difficult to read fonts without exposing yourself to code execution vulnerabilities, eh? I'd imagine better languages would help here.

1: http://web.nvd.nist.gov/view/vuln/search-results?adv_search=...

Re: Google Webfonts, the Spy Inside?

#73

Post by harryjo »

justcommenting wrote: post #34
lallysingh wrote: post #26

Earlier quoted context omitted.

(not talking for google) Two quick points: - The fonts have to be hosted somewhere. And the more common the hosting site is, the better the browser cache behavior is. - The cache behavior prevents requests from going out. If the font is cached, then there's no web request going back to google. And there's no web request on the wire for NSA/GCHQ/Verizon to sniff. As for the terminology, I personally think that there s…

It really depends on the relevant counterfactual; yours makes total sense from the vantage point of lots of developers, but I tend to prioritize privacy and autonomy. When I visit catphotos.wordpress.com, my intention is not to leak information to Google even though they have great fonts. My intention is just to visit the website. So the counterfactual I would frame the discussion with would be something more like se…

If you don't want Google to know about catphotos, you can download all the fonts from google every day, so they stay in your cache and don't relate at all to your browsing.

Re: Google Webfonts, the Spy Inside?

#74

Post by oxplot »

Throwaway90283 wrote: post #39
kbar13 wrote: post #8

Earlier quoted context omitted.

using font files from a popular public cdn like google fonts is a good idea as they are generally highly available and are generally already cached on the user's machine from use on other sites.

Keep in mind the Google CDN is blocked in countries such as China, so your web fonts are not going to render for those visitors, and if you rely on jQuery from the Google CDN, those visitors will experience a broken site. If you have a global reach, this is one reason to self host.

Steve Souders from Google goes through dealing with this [1] and I was surprised to see how Twitter approached this (basically encouraging putting sync javascript link at the top of the page)

[1]: https://www.youtube.com/watch?v=aHDNmTpqi7w

Re: Google Webfonts, the Spy Inside?

#75

Post by kbar13 »

a3_nm wrote: post #25
kbar13 wrote: post #8

Earlier quoted context omitted.

using font files from a popular public cdn like google fonts is a good idea as they are generally highly available and are generally already cached on the user's machine from use on other sites.

It's a pity that there isn't currently a way to leverage cached resources with different URLs for the same content. In fact this would not be hard: if you could indicate, with the resource URL, the hash of the resource content, the browser could just use the resource with that hash if it has it in cache (no matter from which URL), and otherwise retrieve it, check the hash, and add it to the cache.

to be fair, what happens if there's a hash collision?

Re: Google Webfonts, the Spy Inside?

#76

Post by oldmanjay »

cpeterso wrote: post #55
GeneralMayhem wrote: post #40

Earlier quoted context omitted.

If sites are reliably hitting a major CDN (like Google) for jQuery, then you get that advantage through caching anyway. The problem is that they don't, and if they're hosting their own jquery.js, there's no way to know before you download it that the script can safely be replaced with the known jQuery. I can imagine a scheme where the browser sends a hash of what it thinks the file is and the server only sends new co…

You've just reinvented HTTP Etags. :) It's a cookie-like resource caching mechanism where the server can return an arbitrary value (usually a hash or timestamp). https://en.wikipedia.org/wiki/HTTP_ETag

Well, no. There is no requirement in the standard for how Etags are implemented, so there is no way to use them outside of treating them as server-specific opaque tokens. They are useless for the parent's concept.

Re: Google Webfonts, the Spy Inside?

#77

Post by sitkack »

majika wrote: post #54
cromwellian wrote: post #47

Earlier quoted context omitted.

I've held this basic view of the Web far longer than I've been a Google employee ( http://timepedia.blogspot.com/2008/05/decentralizing-web.htm... ) I wrote one of the first anonymizing proxy servers for the Web ( http://cypherpunks.venona.com/archive/1996/02/msg00885.html ) which was later referenced by others (Ian Goldberg references it here: http://www.cs.berkeley.edu/~daw/papers/privacy-compcon97-www... ) In the…

Aside your abstract commentary here is a defense of your argument that the web will lose something valuable if more sites stop directing their visitors' browsers to send requests to advertizing companies and CDNs for resources. I think that's baloney - the web will be better off for it, because it will be faster, more private, and simpler. No semantic information is lost (except for the semantic information in Google…

Your argument has analogous parallels between static and dynamic linking. That using 3rd party fonts, particularly those of a known personal metadata horder makes the web brittle both in structure and unduly trades the visitors metadata with a 3rd party. Pages are only faster, not semantically better by serving content from a third party.

I too prefer my pages to be statically linked.

Re: Google Webfonts, the Spy Inside?

#78

Post by ncza »

AceJohnny2 wrote: post #19
ncza wrote: post #3

Thank you for making me aware of this insanity. I'll make sure to block those on my sites. The thoughtless denial of privacy is so weird, no one seems to mind letting third parties spy on their visitors. Yes, you, Google, jquery, cloudflare, typekit, gravatar, disqus and whatever your names might be.

You don't know what a CDN is, do you?

I do know what a CDN is.

Re: Google Webfonts, the Spy Inside?

#79

Post by a3_nm »

kbar13 wrote: post #75
a3_nm wrote: post #25

Earlier quoted context omitted.

It's a pity that there isn't currently a way to leverage cached resources with different URLs for the same content. In fact this would not be hard: if you could indicate, with the resource URL, the hash of the resource content, the browser could just use the resource with that hash if it has it in cache (no matter from which URL), and otherwise retrieve it, check the hash, and add it to the cache.

to be fair, what happens if there's a hash collision?

Use a cryptographic hash function, and there will be no collisions. There are a lot of things that rely on the assumption that hash collisions do not happen.
Post reply on HN