TTF/OTF file encryption or protection

Muhammad Zeeshan Nasar

Hello!
can anyone help me how to encrypt/protect a ttf/otf font file so that it could not be copied or used. Actually I am Arabic/Urdu font developer, I had developed many fonts, now I want to sale my fonts, but I need a protection that my font will run only on that system, which is allowed by me. I want to apply protection to avoid piracy of my fonts. 
How it could be done? 
Some font foundries are using a technique. they encrypt font file, you can not access its OT tables, you will be able to see fonts glyphs only.  But the allow use of their font through their plugin which allows to run font only on that computer which is  the original buyer of that font. otherwise you will not be able to access that font file. 
How it could be done, Any body can help me in this regard?
Thanks.

Christopher Slye

Muhammad Zeeshan Nasar said:

Some font foundries are using a technique.

Which foundries?

Thomas Phinney

I do not know of any company that is currently offering this as a service to font vendors. It may be that there is, and as it is only for non-Latin fonts, and there have not been in-person type conferences lately, I just haven’t hear about it.

But, like Christopher, I worked at Adobe for a long time—11 years for me, twice that for him. One of the things we both lived through, from the foundry side, was Adobe’s flirtations with copy protection for East Asian fonts, done primarily to please their Japanese font partner Morisawa.

Adobe developed copy protection for fonts three times. Twice it implemented something, and later discontinued it. The third time it developed a technology, but never deployed it. Why not, you might ask?

Such techniques are effective against casual piracy, but will not prevent all possible piracy. Eventually people will decrypt your fonts and place them on servers.

The one thing copy protection does succeed at, is frustrating legitimate or reasonable usage which is incompatible in one way or another with your copy protection. And just making using your fonts more work.

Besides the hassle for the user, you are creating a major tech support burden for yourself. And you will have to either develop the technology or pay somebody else for it, as well.

Would you disallow embedding your fonts in PDF because they can be fairly trivially extracted from the PDF? (Although only the glyphs and font tables that are in the PDF can be extracted; depending on the embedding this may or may not be all glyphs and all font tables.)

Are you willing to be incompatible with a significant number of major design programs? Or force your users to have plug-ins for them? Unless things have changed (and I freely admit my knowledge of this area is old), many major design apps access installed font files fairly directly, not just through system APIs. That means that besides a system-level add-on, to work with apps such as Illustrator, Photoshop and InDesign you would need to have app-specific plug-ins. And your users would have to install them. And they would need to be updated periodically to work with new app versions. And you might have frustrated users during gaps when they have upgraded their app and the updated plug-in isn’t yet available.

In Adobe’s case, they had to reinvent copy protection when format changes made their old fonts obsolete. The thing that made Adobe stop doing copy protection? In the end, the the cost simply exceeded the value to Adobe and Morisawa, even though that cost was shouldered in substantial part by end users.

I am very sympathetic to type designers and foundries who are frustrated by piracy. I hate font piracy, too. But copy protection is a truly awful experience for everybody involved.

Simon Cozens

The problem with any kind of font encryption is that it must be breakable, or else it won't work!

What I mean is that if the font is to work with any application, then at some point the application must pass the complete, unencrypted font to a system font service (CoreText, Harfbuzz, DirectWrite, etc.). At which point a malicious application can simply write the unencrypted font file to disk.

Paul van der Laan

You might want to have a look at https://type.world/

Type.World is a distribution system for fonts developed by Jan Gerner (AKA Yanone) where the foundry can have pretty precise control about how many copies of a font a licensee can install. It can also notify the licensee of font updates, and many other things.

Oliver Weiss (Walden Font Co.)

Someone who goes through the trouble of stealing my font wasn't ever going to buy it anyway, so it's no loss to me. Someone who stumbled on a pirated copy of my font, liked it, and wants to use it in their work will seek me out and pay me. The history of DRM has shown that it doesn't stop pirates from ripping off your work, but does a great job of preventing legitimate sales. 

It's your choice, of course. Personally, I'd rather spend my time making more fonts. 

Muhammad Zeeshan Nasar

Christopher Slye said:

Muhammad Zeeshan Nasar said:

Some font foundries are using a technique.

Which foundries?

maryamsoft and axissoft for their plugin

Hin-Tak Leung

What Simon said above is essentially correct: unless your fonts are tied to quite specific usages / applications, they are always interceptable in the unencrypted form at the OS's renderer's entry point CoreText, DirectWrite/GDI, Harfbuzz/Freetype, etc. So it just cannot be done. I personally can modify freetype to dump what it receives - it is a useful debugging technique to inspect only the received data triggering a bug, for example.

Regarding specific usages/applications though, I have an impression that the Adobe typekit does that? Ie. Fonts are downloaded from Adobe servers etc and kept in some virtual disk location, and are tied to the user's creative cloud subscription. Such fonts are also only visible to Adobe family of applications, Illustrator, Photoshop, etc?

Marc Oxborrow

@Hin-Tak Leung — On the Mac side, fonts activated via Adobe Fonts are visible to all applications, not just those in the Adobe Creative Cloud family. I don't have any experience with Adobe Fonts on Windows.

Florian Pircher

I agree with all of the above. Regarding the technical feasibility of protecting fonts: Adobe Fonts are also just OTF/TTF files stored in a folder. They are placed in a hidden folder and have cryptic names, but that’s it. My tool fontpath gives you the path of a font file on a Mac by its font or family name. I developed it for other, legitimate uses (mainly for use with the HarfBuzz shape tool). The tool is not complicated; two system-provided functions do practically all the work, the rest of the code just handles input/output and errors.

And for Adobe Fonts I can see why they want to hide and copy-protect their files: it’s a subscription. Once you are no longer a subscriber, you should lose access to the font files. But for any perpetual desktop license, I would not accept having to install a custom font provider for just a single font family. As @Paul van der Laan pointed out, type.world would at least aggregate multiple vendors and thus just require a single font provider app, but I can not imagine its font protection to be bulletproof either.

Erwin Denissen

On Windows any decent font manager is able to get access to fonts that are visible to all applications. Better put your time and effort into making and marketing your fonts.

Rob Barba

Arguably, filing DMCAs for piracy tends to be a better use of your time than coming up with or implementing DRM - and even that can be a chore.  The fact is, there are always going to be people who pirate stuff, even stuff they don't need, because they can.  That includes your fonts.

I recall that a friend of mine, years before I got into fontmaking, spent time hunting down all a well-known type foundry's fonts on the web, compiled them and then proceeded to pirate them like crazy.  Why?  Because she ran a photoshop blog designing business and hated the fact that she had to deal with the "stupid prices" of said fonts.  Hypocritical?  Yes.  But I point it out because that's one of the mentalities you have to deal with when dealing with pirates.  There are others.

Before I go too off-topic here, my point is what so many others have said here: you're far better off designing fonts and convincing potential purchasers that they want to buy it, than to put in DRM that might make them regret buying it.  Give me a reason to give you money, not a reason to say, "hey, I like this font, but that one over there isn't going to give me headaches while installing" - or worse, firing up Ye Olde Pirate Bay.

Simon Cozens

My go-to article on piracy versus DRM for creative media is "Piracy is Progressive Taxation":

Lesson 1: Obscurity is a far greater threat to authors and creative artists than piracy.

Lesson 2: Piracy is progressive taxation

For all of these creative artists, most laboring in obscurity, being well-enough known to be pirated would be a crowning achievement. Piracy is a kind of progressive taxation, which may shave a few percentage points off the sales of well-known artists (and I say “may” because even that point is not proven), in exchange for massive benefits to the far greater number for whom exposure may lead to increased revenues.

Lesson 3: Customers want to do the right thing, if they can.

Piracy is a loaded word, which we used to reserve for wholesale copying and resale of illegitimate product. The music and film industry usage, applying it to peer-to-peer file sharing, is a disservice to honest discussion...

The simplest way to get customers to stop trading illicit digital copies of music and movies is to give those customers a legitimate alternative, at a fair price.

Rob Barba

Christopher Slye said:

Muhammad Zeeshan Nasar said:

Some font foundries are using a technique.

Which foundries?

I wonder if he's referring to Letterhead Fonts' DRM system (and I use that term loosely as it's not really DRM as just encryption).  I mention this as I found out about it when I bought one of their fonts earlier this year.

Thomas Phinney

Although it is a kind of encryption, Letterhead’s FontGuard system is not what most people would think of, in that regard. The font is not encrypted: additional information about the purchaser is hidden (and presumably encrypted) in the font file.

(I have kicked around ideas for how to do this with other people in the past, thought of numerous approaches to doing it. Anybody on the foundry side of the fence who wants some ideas, feel free to approach me privately.)

Hin-Tak Leung

I had a quick thought about how to hide purchaser info in a font, and still think it cannot be done.

The easiest way is to add a new custom opentype table, like a DSIG, but for purchaser info. A harder one would be some steganographic technique spreading the info across tiny repositioning of the glyph nodes, or an unused glyph.

However, any such technique has one problem: it makes two copies of the font different. As the change must not affect the font's functioning, such technique can always be beaten by comparing two copies of the font, and just removing the differing parts. Yes, the pirate needs to buy two copies instead of one; that only makes it more costly for them, just not particularly hard to break.

Florian Pircher

Pirates don’t buy licenses. Even if, I cannot imagine a pirate (at least most) comparing e.g. the glyph order of two fonts and changing it manually to escape fingerprinting. However, such fingerprinting techniques may break compatibility if multiple designers with their own font files collaborate.

Hin-Tak Leung

I disagree with both statements. Not fonts, but I have heard stories of sharing licenses, where website makes a real purchases then charges a subscription fees for his clients for sharing his collections of software. If fingerprinting is used, fingerprinting is to be applied at the point of distribution, ie when the distribution channel generates a fingerprinted copy of the font from combining a master copy and purchaser's info. That's way way after font designers finish designing and collaborating. How the designer(s) collaborate is irrelevant, as fingerprinting is implemented at purchase/distribution side. If you are talking about designers each having their own different font files working on the same project, maybe you don't understand steganography - glyphs visually the same can still contain subtle identifying info.

But these are all intellectual exercises - fonts, to be usable system-wide, are interceptable at the OS's renderer; finger-printing techniques trying to identify and ban bad buy-once-resale-many customers are breakable by getting two copies and strip away the difference. You can write a little python script wrapping ttx fonttools to do that, for example.

Florian Pircher

Hin-Tak Leung said:

If you are talking about designers each having their own different font files working on the same project, maybe you don't understand steganography - glyphs visually the same can still contain subtle identifying info.

That is what I mean by glyph order. Two font files can contain the exact same tables with only the glyph order differing. That way, you can encode the fingerprint as a unique glyph order. First buyer gets the glyph order A J T Q G …, next buyer gets a glyph order of E C J S L …, and so on. Store the random glyph order in a database for each purchase. Randomizing parts of the glyph order are just an example of fingerprinting. One can also, as you suggested, add superfluous nodes to glyph paths, or add a signature table, or add zero width spaces to the glyph description field, etc. Each method has its own benefits and drawbacks. Randomizing the glyph order bloats the cmap table and breaks software storing glyph ids, but keeps outlines equal.

Once somebody TTXs your font files, its game over. But at that point they are unlikely to be a potential buyer, even with improved file protection.

Hin-Tak Leung

Hmm, you need to read up on steganography. Messing with glyph order is stupid - many programs use glyph id directly instead of going via charmap. There is no need to store any thing (let alone glyph order...) on any external database. Just hashing the transaction / purchase number would do. You need to read up on hashing functions. The typical designers are unlikely to have more than 4 billion customers, so a 32-bit hash function (or even 16) to hide 32-bit is sufficient.

As for where one hides the hashed bitstream - even tiny zero-width user-invisible contours on the .notdef glyph, for example, is far less obvious and less detectable (and breaking) than glyph order. Let's try another example: just shaking/jittering the O shape (which has at least 16 control points, or 32 co-ordinates) by 1 or 0, which is 1 part in 2048, and invisible at any reasonable rasterization (how often do you ask for point size 256?) due to hinting and fit-to-grid.

And that goes to another area of hiding: it is also possible to hide 32-bit of information in hinting instructions which are present but totally used by any glyph at any resolution, in the form of garbage-filled user-defined routines, for example. Since it is not used, it can contain arbitrary stuff.

Glyph order is just too visible and too breaking.

Florian Pircher

The glyph order is just an example; I am not advising its usage as a fingerprint. I pointed out its drawbacks. Messing with outlines in every delivered file also has drawbacks. If e.g. a software assumes glyph outlines to never change for the same font and a document of such a software is shared between designers, the software may break.

Hin-Tak Leung said:

Messing with glyph order is stupid […] You need to read up on hashing functions.

Please avoid such a tone. It’s neither productive nor inviting.

Hin-Tak Leung

There are a million ways of doing a task, in this case, trying to combat piracy, poorly, badly and stupidly. I thought the discussion is on why even some of the cleverer ideas do not and cannot work, and not why some of the poor and stupid ones do not.

In fact quite the opposite: keep talking about silly and stupid ways of DRM, gives the wrong impression that one is cleverer than those silly and stupid ideas... Being cleverer than silly and stupid is not exactly a productive thing.

Nick Curtis

The subject of the discussion was IF encryption were possible, not WHY, clever or not. It appears that your intent is to appear to be clever; however, please be advised that there is nothing in the least clever about ill manners. Your cooperation in this regard would be greatly appreciated.

Hin-Tak Leung

I would say the concensus has reached quite early on in this thread, that encryption is "possible" (but "not worth the trouble"). And moved onto how much effort one needs to spend on increasing level of encryption, versus how easy/hard it is to break such encryption. About the "not worth the trouble" part.

So, some people want to stay talking about easily breakable encryption; okay...

Hin-Tak Leung

On using user-defined functions (the FDEF instruction) in the hinting instruction table, many autohinting programs, at least AFAIK ttfautohint, and possibly Microsoft's visual truetypes too, inserts stock template functions into the prep table, and some of them end up unused. And I think Google's fontbakery or some other font optimizing tool has an option to strip unused FDEF functions out to cut file size (by a mere few bytes... Most people don't bother, given the very little size saving). So hiding hashed serial numbers in FDEF in the prep table is not too noticeable.