Web Font Security

Simple answer: There is none. Even with so called obfuscation or using CDNs that only serve to specific requests, it's still pretty easy to grab any font. If the browser can use and render it, everyone else can, too. However this 2 features (obfuscation and a properly configured CDN) is something you should consider of course.

Luke Freeman said:

...
I have came across some sites that have very good protection preventing a user ripping a webfont. 

Site examples:
http://www.filipmatejicek.info/

That site is embedding WOFF data directly within the @font-face rule definition, using base64 encoding --- which will expand the size of the data probably by a factor of 4.

Additionally, all your regular users won’t be able to benefit from caching and will have to re-download the Base64 data every time they visit, making your site slower to load to repeat visitors. 

There’s situations where this is warranted and useful, but not very often.

Joshnychuk said:

Lastly, I've purchased web fonts with rights for self-hosting and they involved configuring an .htaccess file. Does anyone recommend that method and can provide a tutorial for setup?

Not sure what this is referring to, but from my technical understanding this sounds like you are maybe confusing or misremember something - if the fonts render as webfonts in a browser anybody can rip them, no matter what your server configuration. A .htaccess might be used to properly configure webfont mime types, for example.

In case I am mistaken, I would be very curious about what this setup achieves and how.

My guess is this (and any other method of obfuscation) mostly provides headaches to paying clients.

Johannes Neumeier said:

Joshnychuk said:

Lastly, I've purchased web fonts with rights for self-hosting and they involved configuring an .htaccess file. Does anyone recommend that method and can provide a tutorial for setup?

Not sure what this is referring to, but from my technical understanding this sounds like you are maybe confusing or misremember something - if the fonts render as webfonts in a browser anybody can rip them, no matter what your server configuration. A .htaccess might be used to properly configure webfont mime types, for example.

In case I am mistaken, I would be very curious about what this setup achieves and how.

My guess is this (and any other method of obfuscation) mostly provides headaches to paying clients.

Certain foundries require this, because ¯\_(ツ)_/¯

It hinders cross-domain font usage and (somewhat) makes downloading them harder because it restricts access to local referrers. But again, the people who download them from websites can do so anyway, and everyone else can just go to Google and get them from there.

Re .htaccess files, I'm guessing that's related to this:

"For font loads, user agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for URL's defined within @font-face rules. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet's URL and set the origin to the URL of the containing document.

"The implications of this for authors are that fonts will typically not be loaded cross-origin unless authors specifically takes steps to permit cross-origin loads. Sites can explicitly allow cross-site loading of font data using the Access-Control-Allow-Origin HTTP header."

http://www.w3.org/TR/css-fonts-3/#font-fetching-requirements 

An parallel example is all of the websites from the aughts that would display an alternate image if you tried to directly link to an image hosted on their server from another domain. There was still nothing that would stop you from downloading the image, uploading it to your own server, and linking to that version. Nothing more special happening for fonts today.

Justin Penner said:
split into two separate font files, with half the glyphs in each

This approach requires care in which glyphs go into first file or second, because it can break OpenType features related to glyphs if those glyphs are missing. Although for sure, all these exclusions can be automated during export.

That implies no interaction between the two glyph sets: no kerning, no GSUB contextual crossover, no anchoring of marks in one font with bases in the other.

I suspect this sort of technique is feasible with pretty basic Latin fonts, if the two sets are carefully selected to minimise the impact of lack of kerning, but it isn’t a viable option for any complex script or for fonts making even moderately sophisticated use of OTL layout features.

[Also, I believe this was in context of H&Co’s webfont service, i.e. it was within a delivery system controlled by H&Co, so not dependent on the licensee understanding what they needed to do to get the fonts to work. Or was this technique also imposed on self-hosting licensees?]

FWIW Typekit also employed split-font delivery, at least in some cases. Even now I have an active kit with “myriad-pro-1” and “myriad-pro-2”. A subsetting thing? I forget.

Johannes Neumeier said:

200 individual http requests for fonts alone on a family page. Hardly a positive benchmark in any technical regard.

In that particular case (with a files of such a small size), it would be much more efficient to convert all woff to base64 strings (it should be automated, of course) and store it in several css files (let's say 100-500 kb each), which will significantly reduce the number of requests.