Web Font Security

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.

Comments

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

  • SiDanielsSiDaniels Posts: 213
    Security through obfuscation requires obfuscating the obfuscation techniques.
  • 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.
  • Thanks @Thierry Blancpain and @Roel Nieskens this sounds like good advice. 
  • 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/
  • ...
    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.
  • glukgluk Posts: 27
    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.

  • 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 FreemanLuke Freeman Posts: 47
    edited February 27
    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


  • 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.
  • AbrahamLeeAbrahamLee Posts: 60
    edited February 27
    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.
  • 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.
  • Is this a real problem? How often do people, who would otherwise purchase a font, rip it from a website instead?
  • 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 

  • 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.
  • 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.
Sign In or Register to comment.