Web Font Security

Josh Nychuk
Josh Nychuk Posts: 28
in Events
I'm wondering if there are industry standard security measures for protecting self-hosted web fonts?

I've designed the font myself, and would like to use it on my website without someone having the ability to pirate it. From what I've read even the biggest web font providers cannot completely prevent font piracy, so I'm hoping to make it as bullet-proof as possible.
Tagged:
«1

Comments

  • Lars Schwarz
    Lars Schwarz Posts: 114
    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.
  • Jens Kutilek
    Jens Kutilek Posts: 364
    Use a subset of your font that just contains the glyphs actually needed for your site. Of course, this is hard if you have dynamic content.
  • Josh Nychuk
    Josh Nychuk Posts: 28
    Thanks Lars and Jens.

    @Lars Schwarz could you point me to a well-explained tutorial covering font obfuscation and properly configuring CDN?

    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?

    Thanks!

  • Roel Nieskens
    Roel Nieskens Posts: 188
    Serving your webfonts only in the WOFF and WOFF2 formats is maybe your best bet. As with all other options, people who know their stuff will be able to pirate them anyway, but the Average Joe won't be able to simply download and install them.
  • Josh Nychuk
    Josh Nychuk Posts: 28
    Thanks @Thierry Blancpain and @Roel Nieskens this sounds like good advice. 
  • Luke Freeman
    Luke Freeman Posts: 61
    Now days font converting can be done online, whats stopping a user converting a WOFF or WOFF2 into a otf or ttf.

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

    Site examples:
    http://www.filipmatejicek.info/
  • Peter Constable
    Peter Constable Posts: 161
    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.
  • Grzegorz Luk (gluk)
    Grzegorz Luk (gluk) Posts: 161
    Luke Freeman said:

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

    Advanced user can download embedded as Base64 Data-URI font too.

  • Thierry Blancpain
    Thierry Blancpain Posts: 210
    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.
  • Luke Freeman
    Luke Freeman Posts: 61
    edited February 2017
    All make valid points. Not many advanced users out there, at least the method makes it harder "prevention is better than cure".

    Another site I suggest just for type testing
    http://www.aisforapple.fr/fonts/david


  • Johannes Neumeier
    Johannes Neumeier Posts: 380
    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.
  • AbrahamLee
    AbrahamLee Posts: 262
    edited February 2017
    gluk said:
    Luke Freeman said:

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

    Advanced user can download embedded as Base64 Data-URI font too.

    ... or just copy+paste the text data directly into a text editor and use some basic programming to re-encode it as a usable binary file. I've done it just to prove it can be done. It's a nice idea that *most* people won't know what to do with, but it's not that hard to make a real font out of the data, unfortunately.
  • Thierry Blancpain
    Thierry Blancpain Posts: 210
    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.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    Is this a real problem? How often do people, who would otherwise purchase a font, rip it from a website instead?
  • Peter Constable
    Peter Constable Posts: 161
    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 

  • Jack Jennings
    Jack Jennings Posts: 151
    And worth noting that CORS is only something that is implemented in browsers, and is mostly for preventing reuse of some asset directly on another website, but is not an IP protection method. At best it's use in this context is a hack, and can be easily circumvented using basic tools like curl.
  • Jack Jennings
    Jack Jennings Posts: 151
    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
    Justin Penner Posts: 65
    Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;`. I noticed it once when one of the fonts didn't load properly and all the text was a random mix of an H&Co font and a system font.

    Of course, finding a pirated copy of Gotham is as easy as Googling "gotham font" and clicking one of the first links that come up. Piracy on its own doesn't bother me too much, but since Google prioritizes pirate font sites, there are also an enormous number of font users who are downloading pirated fonts unintentionally, because the site told them it's a free font, and Google told them it's a trustworthy site by putting it (and 5 or 6 other pirate sites) in the first 10 search results.

    Should we be lobbying Google to improve their search results? If you search for any popular movies, books, or music, you don't generally find the top 10 results filled with pirate links.
  • jeremy tribby
    jeremy tribby Posts: 251
    edited January 20
    the hoefler method was clever; I think that + CORS is probably a reasonably effective deterrent even though it’s ultimately circumventable and the fonts could be found elsewhere. anti-piracy efforts can have negative consequences though. @Thierry Blancpain made a good point in another thread on this topic which is that pirates may one day become your customer. in the meantime, you haven’t lost a sale, because they were never going to pay in the first place. what is actually gained by locking things down?
  • Michael Rafailyk
    Michael Rafailyk Posts: 146
    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.
  • Enrico Sogari
    Enrico Sogari Posts: 47
    edited January 20
    Justin Penner said:
    Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;.
    Pretty smart approach.

    Should we be lobbying Google to improve their search results? If you search for any popular movies, books, or music, you don't generally find the top 10 results filled with pirate links.
    YES absolutely.

  • John Hudson
    John Hudson Posts: 3,227
    edited January 20
    Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;.
    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?]
  • Michael Rafailyk
    Michael Rafailyk Posts: 146
    edited January 21
    .
  • Christopher Slye
    Christopher Slye Posts: 152
    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
    Johannes Neumeier Posts: 380

    Seems not to be the case any more. Weirdly enough though there is a distinct file for every "space" of a style, yet the counterpart contains everything*. Not to mention using a single file for every style, and woff instead of woff2, ending up with a whopping 7.5MB and 200 individual http requests for fonts alone on a family page. Hardly a positive benchmark in any technical regard.

    *of course this is speculative conjecture and I would not in my wildest dream dare inspecting the unlicensed intellectual property of our monopoly overlords.



  • Michael Rafailyk
    Michael Rafailyk Posts: 146
    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.
  • John Butler
    John Butler Posts: 297
    We have the bandwidth now to return to bitmap fonts, an idea promoted by Letterror for decades. Is there an existing way to do it on a website?

Categories