fontsampler-wordpress-plugin
fontsampler-wordpress-plugin copied to clipboard
Prevent possibility to download the font
Current plugin adding full url of woff-file into page code and every user can copy this url and download commercial fonts. Do you have any ideas, how make this plugin more secured for commercial fonts? Thank you.
Thanks for your input. This issue has been raised several times, but there is very little I can do about it. Webfont formats are compression formats, not digital rights formats. Any attempts I've seen at trying to prevent users from accessing webfonts (in general, not just this plugin) usually are through some kind of obfuscation. However, none truly prevent users from downloading the fonts, they just make it hard to various degrees.
I will leave this issue open here in the hope to collect possible approaches or hear suggestions from users.
One advice I have been giving to users that previously raised this issue is to use only a subset of their font for the Fontsamplers on their website. So even if someone downloads their font it is only an incomplete subset. What this appropriate subset is you have to define. With fonttools this can be automated to a degree. However, automatically compiling this server side requires access to python and pip, which I cannot reliably assume in a Wordpress plugin. Adding this as an option feature would be very nice to have, but it's not widely applicable, I assume.
Other approaches:
- Use base64 encoding; could be possibly made to work, but has performance implications, in particular no font caching; however, this too poses no problem for advanced users to download the fonts
- Use SVG images of the glyphs; unpractical for a type tester where you also want non-glyph-level features like kerning, opentype substritutions, etc to work
- Server side rendering and serving an image; possible, but would require loading a new image on each key stroke, so this is not viable in terms of end user performance
You could misencode the glyphs and have js translate input to the needed up encoding. I've seen Foundry specimen PDF made this way to annoy rippers.
Made up encoding
It's something I've considered. In fact, I'd go further and mangle the actual glyph data. If you just switch glyph order the recompiled woff is useless as such, but still exposes all the font data intact. This plugin uses opentype.js under the hood, so (reversing) glyph level transformations is possible. Either approach, two problems remain:
-
Even with a) obfuscated font file and b) a decoding key and c) a decoding script, all pieces are still exposed to potential attackers wanting to reverse engineer the scheme. Granted, this would be significantly more difficult to recompile the font into a working standalone woff, but still, it is no real security.
-
This plugin operates in PHP environments, often on shared hosts or with limited command line access. Any prior transformation of the font file server-side can't be easily automated due to these constraints. It is thinkable to code the same encoder using opentype.js in the backend when uploading the files. Considering this, I am not sure how much more advantages this offers over users using something like fonttools to subset and make a decompiled woff hard to use. Of course making something like that easier for users of this plugin would be helpful.
All in all this sound like an approach that would be best served in a separate project. If some kind of viable "woff uglification" library existed, I'd happily put it to use. Whatever time I spend on this project is missing from running my business, so it's not something I have the resources to work on, at least not right now.
A good suggestion though! 👍
Have you done something (I mean not recently) to the font paths? I usually see that all fonts are listed in Inspect Elements / Application / Frames / Fonts. Almost all type foundries. But in Fontsampler they are not there and only you can see them in the Elements tab.
@shahabsiavash Nope, not yet. Webfonts are loaded via Opentype.js and they are requested via Ajax. You can find them listed under Inspect Element / Network / XHR.
Is there any other solutions? Like with a ..htaccess?
@beppeartz .htaccess restricts access to the file altogether, which also means the browser cannot access it to render it, so unfortunately that is not an option.