Can stolen fonts be found on the web based on Bezier data of their outlines?

2»

Comments

  • John SavardJohn Savard Posts: 465
    edited June 14
    Yes, that's bad.
    But I what I meant is if "nearly every recent release" is getting pirated, but yours doesn't, it must be a really bad design.  :-/
    However, the bot scraping MyFonts may not be sophisticated enough to tell good typefaces from bad ones.
    At best, I think the problem could be substantially mitigated, but not eliminated — at least not without a radical rethink of the way fonts are distributed, like, for example, the way that Adobe has done.
    Adobe has found a successful technical solution to font piracy? Tell me more!
  • Cory MaylettCory Maylett Posts: 158
    edited June 14
    I didn't mean to imply that Adobe has found a foolproof system — they haven't.

    However, having their rented fonts hidden on a user's computer and only residing there temporarily while tied directly to their active Creative Cloud software user account greatly inhibits casual sharing and uploading to a degree that I suspect is quite effective.

    In some ways it's similar to locking one's garage door instead of leaving it open. A dedicated and committed burglar can still break in, but the lock greatly deters casual theft (which most thievery is).

    Similarly, if someone wants to recreate a hacked version of a font by nabbing the Bezier outlines of the font, as the title of the thread suggests, that, to me, is equivalent to a dedicated thief breaking into a fully locked house. Nothing is fully secure, but finding ways to make something 90-plus percent more secure as opposed to having no security at all is a worthwhile objective.
  • Thomas PhinneyThomas Phinney Posts: 1,679
    With Adobe's approach, the main thing is that people are getting the fonts as part of the CC subscription. There is not much motivation for the subscribers to rip off the fonts, as they have many reasons to have a subscription. Successfully stealing the fonts would not change that.

    Yes, the apps could be pirated as well. But it's a pain, and hard to keep up-to-date, etc.
  • Adam JagoszAdam Jagosz Posts: 396
    edited June 14
    If you can manage a line that's over 128 units in length, you could encode 64 bits (unsigned) which would allow serials up to 18,446,744,073,709,551,615. I'm not confident that that number is correct!
    Cool idea! Within a line of 128 units, isn't it correct to more straightforwardly assume we can encode store 126 bits? (Point/no point).
  • Ray LarabieRay Larabie Posts: 922
    Yeah, you're right. Plus a few bits to indicate the start. Encoding serials directly in the glyphs could be a privacy concern. You write a ransom note as a PDF, @Thomas Phinney finds the hidden points in the underscore and your plan is foiled.
  • Dusan JelesijevicDusan Jelesijevic Posts: 33
    edited June 15

    1. get the font url from the html page. You'll need to parse the css @font_face rules
    2. download the font
    3. convert font
    4. open the font in fontTools
    5. make a hash for each glyph's outlines in the downloaded font
    6. Same as step 5 but for a local font you want to match
    7. compare the hashes between fonts

    Getting away from the topic, but need to answer on this – there is simple solution with htaccess file I'm using on last 2 versions of our website. You just need to define file extensions and/or folders with webfonts, restrict the access to them and that should will keep away any CSS @font_face parsing.
  • Thomas PhinneyThomas Phinney Posts: 1,679
    edited June 15
    I am concerned with @Ray Larabie's point, the fact that ones electronic documents then have additional user-specific watermarking in them, which could be used to identify the user.

    Of course this could be used to catch criminals and wrongdoers. But it could also be used by governments and corporations to suppress legitimate dissent. (And “arguably-legitimate” dissent—of course there are gray areas as well.)
  • Cory MaylettCory Maylett Posts: 158
    edited June 15
    You just need to define file extensions and/or folders with webfonts, restrict the access to them and that should will keep away any CSS @font_face parsing.
    I'm not sure how using .htaccess would amount to much more than a speed bump for a serious thief, but it might be a good tactic when combined with several other speed bumps. Here's a blog article on the general subject of protecting webfonts from being pirated: https://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/

    I am concerned with @Ray Larabie's point, the fact that ones electronic documents then have additional user-specific watermarking in them, which could be used to identify the user.
    Even if the identifying anomalous data were found in the file, that data would presumably contain nothing but an encrypted serial identifier lacking an obvious sequence of characters. Even obtaining this would require access to the file in which that information was contained — say, for example, the PDF from which it was printed (all non-rasterized, of course). Even then, the PDF (or whatever) would have to include the entire font rather than a subset of the font since some of the identifying data would likely be encoded into parts of the font not in the PDF or SVG or whatever. Even if a sequentially correct and complete serial number were obtained, it would mean nothing without the cooperation of the serial number's issuer. Lots of things would seemingly need to fall into place.

    I would never pretend to know more about this than you, but wouldn't this problem be a rather minor concern in all but the most exceptional of circumstances?
  • Thomas PhinneyThomas Phinney Posts: 1,679
    And then one compares the funky glyph from PDF "A" with PDF "B" that has a known origin, and bang, you have identified the user.

    Although to be fair, a computer user wanting to remain anonymous is very likely to use boring system fonts, not the kinds of designer fonts that are going to be watermarked.

    So while a theoretical concern, I think you are probably right not to worry, for the latter reason.
  • Vasil StanevVasil Stanev Posts: 432
    edited June 17
    @Thomas Phinney bit offtopic, but here goes: If memory serves, a pirate (now banned) bragged on some pirate board some time ago that he was able to open a font in a font editor, which font had a protection against editing. How? He manually renamed the file extention from OTF to TTF  :o

    Obviously files can become unstable after this rude intrusion, but that can't penetrate some people's mindsets.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,561
    Which font editor prevents editing?
  • Vasil StanevVasil Stanev Posts: 432
    At that time it was FontLab 5. 
  • AbrahamLeeAbrahamLee Posts: 245
    edited June 17
    Which font editor prevents editing?

    FontForge will warn the user about this restriction if the flag has been set in the font, but it allows you to proceed if you say you have permission to edit.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,561
    At that time it was FontLab 5. 
    Huh, that's what I use, but I had no idea. What fonts have that flag set? Anyway I'm glad there's an easy work-around, it's too protectionist.
  • Vasil StanevVasil Stanev Posts: 432
    edited June 17
    I didn't mean to imply that Adobe has found a foolproof system — they haven't.
    Sounds very much like the way video games make you pay for unfinished products and charge you for upgrades and trinkets. Heck, why not make CC functionality the same?? "Pay an added $2.50 to unlock the Photoshop Layer style option". "You are back some payments? Well too bad, menu items start disappearing." How is this different from ransomware?
    /joke

    We had a joke in the office about an "Adobe tax".
  • Thomas PhinneyThomas Phinney Posts: 1,679
    I am curious as to what this "do not edit this font" flag is? Because I for one do not remember having ever heard of such a thing.

    I am wondering if it might be somebody’s misunderstanding of the purpose of the fsType (font embedding bits) in the OS/2 table of an OpenType or TrueType font.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,561
    edited June 18
    Indeed, the only time I've ever heard of such a thing is John Downer (quelle surprise) many years ago pressuring font editors to totally prevent the opening of other people's fonts...
  • I don't recommend doing this. Most EULAs probably forbid downloading fonts locally.
    Reliably fingerprinting fonts (even when bezier data has changed) and staying within the webfont's EULA while doing so, didn't turn out to be the biggest problem. 
    How can a font EULA apply to someone visiting and/or scraping a website?
  • Roel NieskensRoel Nieskens Posts: 132
    How can a font EULA apply to someone visiting and/or scraping a website?
    Not sure. I avoided thinking about it by injecting the check into the source website in a headless browser. ¯\_(ツ)_/¯
  • Vasil StanevVasil Stanev Posts: 432
    edited June 19
    I am curious as to what this "do not edit this font" flag is? Because I for one do not remember having ever heard of such a thing.

    I am wondering if it might be somebody’s misunderstanding of the purpose of the fsType (font embedding bits) in the OS/2 table of an OpenType or TrueType font.
    I took the time to recreate the situation (hope nothing nasty nested itself in some nook on my PC)

    FontLab 5 gives this message:
     ERROR! Import failed for the following reason: Font file does not exist or is corrupted or is not accessible.

    And the OTF file itself is visible in the Windows 7 FontView window.

    The Beziers themselves are smooth and clean before and after the renaming, kerning pairs are intact. If the stolen file was screenshot from MyFonts, that does not seem to have affected its quality. But I have seen shabby Beziers on otherwise clean fonts. Meaning there may be more than one (types of) bot, or some busybody buys one copy and distributes it, or something else.
  • Thomas PhinneyThomas Phinney Posts: 1,679
    @Vasil Stanev
    I strongly suspect that was considered a bug, not a feature, on the FontLab side.
Sign In or Register to comment.