Jak chronić WebFonts

Question

Mam klienta, który chce hostować swoje webfonty na własnym serwerze. Mam konto font.com, na którym czcionka była hostowana do tej pory. Poszedłem prawdzie na fonts.com agreement (Punkt 18.) Tam, gdzie mówią, że możesz hostować pliki na własnym serwerze, ale musisz je chronić tak dobrze, jak to możliwe.

Jedyny sposób, w jaki mogę to zrobić, polega na ograniczaniu żądań tych plików za pomocą HTTP_REFERER w .htaccess.

Czy mogę zrobić więcej, aby chronić te czcionki? Czy jest sens robić więcej i czy uważasz, że jest to wystarczająca ochrona?

Osobiście nie wierzę w techniczną ochronę przed kopiowaniem, zawsze możesz skopiować to, co możesz zobaczyć w jakiś sposób. Ale nie chcę, aby mój klient wpadł w kłopoty prawne. Czy masz jakieś doświadczenie z tym?

edit

jestem zainteresowany w aspekcie prawnym, jak również. Co się może stać, jeśli ktoś może pobrać czcionkę i użyć jej ponownie? Czy oznacza to, że muszę chronić czcionkę tylko przez hot-linking lub pobieranie?

Answer 1

Znajdziesz tu kilka ciekawych metod w artykule typekit: "Serving and Protecting Fonts on the Web"

Wykorzystują one podobne metody HTTP Polecającego sprawdzenie, kodowanie base64, segmentacja. Jednak żadna z nich nie zapewnia pełnej ochrony i jedno zgadza się z tym stwierdzeniem z artykułu:

Faktem jest, że aby coś pojawiło się w przeglądarce, musi być w Internecie. Jeśli jest w sieci, nie można jej całkowicie zabezpieczyć ... Wyznaczyliśmy kilka własnych przeszkód. Naszym zamiarem jest jedynie zniechęcenie do przypadkowego niewłaściwego użycia i wyjaśnienie, że pobieranie czcionek z Typekit jest wyraźnym i zamierzonym działaniem.

Drugą rzeczą do zniesienia jest to, że licencjobiorca może zawsze pominąć umowy, i dlatego takie firmy jak Adobe, która produkuje jeden najbardziej doskonałych czcionek określa warunki użytkowania tym na internecie w Font licensing page.

Zobacz także Font Licensing Issues omówione w specyfikacji web3s CS3 W3 CSS.

Answer 2

HTTP_REFERER i USER_AGENT można łatwo sfałszować. Mówiąc w ten sposób, jeśli chcesz zapobiec hot linking, HTTP_REFERER jest dobrym początkiem, aby ograniczyć go do połączeń z własnej aplikacji.

z Apache mode_security

SecFilterSelective "HTTP_REFERER" "^[^\?]*mydomain\.com" 

Dodaj wyżej do katalogu z czcionkami odrzuci wszystkie wnioski niezgodne z innych witryn.

Dla dodatkowego bezpieczeństwa, gdy ktoś używa twojej aplikacji, dajesz im sesję na serwerze (na przykład PHP), i przechowujesz tam unikalny identyfikator.

<?PHP 
// #header.php - in the head of the page that uses the font 
// ... 
if(!isset($_SESSION['uniqueId'])) { 
    $_SESSION['uniqueId'] = rand(pow(2,16), pow(2,31)); 
} 
$uniqueId = $_SESSION['uniqueId']; 

echo '<script type="text/javascript" src="http://foo.com/getFont.php?u='.$uniqueId.'"></script>'; 
?> 

A to służy czcionce.

<?PHP 
// #getFont.php - serve your fonts from here 
// ... 
if(!isset($_GET['u']) || !isset($_SESSION['uniqueId']) || $_SESSION['uniqueId']!=$_GET['u']) { 
    die('Bad Request'); 
} 

// cat out the file contents here for the request font file 
?> 

Następnie należy odwołać się do dynamicznej strony dla czcionki (powiedzmy getFont.php? UniqueId = foo), a jedynie zwrócić plik czcionki, jeśli unqiueId odpowiada ich sesji, w przeciwnym razie można zakładać, że jest to fałszywe gorący link referer. Jest to zasadniczo takie samo, jak umieszczenie pliku w katalogu uwierzytelnionego użytkownika, ale działałoby to tylko wtedy, gdyby użytkownicy zalogowali się, podczas gdy powyższa metoda wymaga po prostu załadowania strony przed załadowaniem czcionki, aby zapobiec gorącym liniom .

Answer 3

To mieszany cel - zabezpieczyć plik przed kopiowaniem, jednocześnie dając wszystkim kopię pliku. Odpowiedź Twisted Pear jest prawdopodobnie najlepsza pod względem znalezienia średniego podłoża.

Aby zabezpieczyć plik, należy renderować tekst do obrazów na serwerze.

Zgodnie z prawem można odwoływać się do DMCA na stronach, na których znajduje się plik czcionki.

Answer 4

Zobacz https://bugzilla.mozilla.org/show_bug.cgi?id=540859

Widocznie zatwierdzony przez FontShop (ostatni komentarz) i sugeruje myfonts (http://twitter.com/#!/MyFonts/status/98767132321521664).

EDIT: Myślę, że to rozwiązanie wymienionych w comment 26:

RewriteCond "%{HTTP_HOST}_%{HTTP_REFERER}" "!\.?([^\.]+\.[^\.]+?)_https?://.*\1/.*$" 
RewriteRule \.(woff|eot)$ - [F,NC,L] 

Answer 5

Nie ekspertem w Apache, ale wykorzystaliśmy to i wydaje się działać wystarczająco dobrze:

Options -Indexes 
IndexIgnore *.woff *.eot 
RewriteEngine On 
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yoursite\.com/.* [NC] 
RewriteCond %{REQUEST_URI} !hotlink\.(woff|eot) [NC] 
RewriteRule .*\.(woff|eot)$ http://yoursite.com/ [NC,F,L] 

bezpośredni odsyłacz prowadzi do 403, ale pliki mogą być nadal dostępne za pośrednictwem CSS swojej własnej strony użytkownika.