Kommerzielle OpenType-Fonts in Webseiten?
Die Schrifteinbettung in Webseiten steht wieder auf der Tagesordnung. Nein, ich spreche nicht von Technologien wie WEFT, TrueDoc oder sIFR, sondern von von OpenType-Schriften (TT/PS), die per CSS in jede beliebige Webseite eingebunden werden können.Die aktuelle Entwicklerversion des WebKit (“Safari”) kann es schon, Opera steht in den Startlöchern.Die Sache hat allerdings auch einen Haken. Von »Schrifteinbettung« kann man nämlich leider gar nicht sprechen. Die Fonts stehen in keinerlei Beziehung zu der Webseite, die sie benutzt, sondern sie werden lediglich per URL verlinkt. Der Font muss also auf einem Server zum öffentlichen Download zur Verfügung stehen und die Adresse ist für jedermann im Quelltext der Seite einzusehen. Dies mag für Freeware-Fonts unerheblich sein, aber kommerzielle Fonts scheiden somit gänzlich aus, denn diese dürfen keinesfalls zum Download für jedermann zur Verfügung gestellt werden.Um kommerzielle Schriften mit »font-face« benutzen zu können, würde man ein Lizenzierungssystem benötigen, das die dafür präparierten Fonts nur für bestimmte Domains freigibt. Dafür müssten sich allerdings Schriftentwickler, Browserentwicklung und das W3C an einen Tisch setzen und eine Lösung erarbeiten.Da dies ziemlich utopisch erscheint, habe ich versucht, ein Test-System zu entwickeln, das mit den bestehenden Technologien funktioniert. Mit dem aktuellen NightlyBuild des WebKits kann man es bereits ausprobieren.
Auf der Webseite http://www.fonts.info/webfonts/ wurden zwei Schriften »eingebettet«. Die »CuttyFrutty« lässt sich problemlos herunterladen, die Kaffeesatz dagegen, ist über verschiedene Sicherungsmechanismen geschützt. Eine einfach zu kopierende Download-Adresse gibt es nicht.Das System ist so aufgesetzt, dass der Font auf dem Server des Schriftherstellers verbleiben würde, und eine lizenzierte Webseite kann den Font über ein auf der Webseite einzufügenden Kode-Schnippsel anfordern.Weiter Links zu Thema:Praegnanz.deTypoWiki
Genial und pragmatisch, Ralf. Die Download-Adresse des Fonts wird verschleiert und ist wahrscheinlich nur durch übles Gehacke herauszufinden (kenne mich nicht so aus), und trotzdem klappt die Darstellung. Sehr schön. Und wert, mal beim W3C und vielleicht noch besser, der WHATWG-Gruppe vorgestellt zu werden.
Danke! Die Download-Adresse ist nicht nur verschleiert, sie ist auch dynamisch und verfällt sofort wieder. Zumindest auf diesem Wege ist also für den Hacker kein durchkommen.
Endlich macht es mal einer. Das spukt mir schon seit Jahren im Kopf rum. Nun muss nur noch alle User davon überzeugen, das WebKit zu installieren oder - vielleicht einfacher - alle wesentlichen Browser/Betriebssystem-Anbieter davon überzeugen, das WebKit standardmäßig zu integrieren.
Die Argumentelage: Wenn es eine Freigabe für eine Domain gibt, könnte ich man doch ein Produktionssystem auf dieser Domain aufsetzen, denn im Prinzip könnte ich doch auch wieder von der Seite ein PDF schreiben und also auch Druckvorlagen erstellen, oder? Also könnte ich auf der Domain beispielsweise einen Visitenkartengenerator laufen lassen? Ob das den Inhabern der Schriftlizenzen so schmeckt? Schon jetzt werden für solche Server-Lizenzen gutes Geld verlangt. Aber: Mit so einem Mechanismus habe ich ein echtes Zählwerk in der Hand. Einmal kucken 1 Cent. Oder so. Denn für jeden Abruf wird ja eine neue dynamische Adresse generiert, ist das Konto leer, erscheint wieder Verdana (oder so).
Trotzdem - langfristig denke ich, dass eine echte nutzungsabhängige Lizenzgebührenberechnung kommen muss. Diese Nuss ist mit dieser Fingerübung noch nicht geknackt. Aber in diese Richtung kann es gehen.
hallo,
also ich hab die kaffeesatz jetzt bei mir auf dem desktop.
die spanne, in der der token verfällt scheint noch etwas groß zu sein.
vielleicht versteh ich auch irgendwas falsch, dann bitte ich um aufklärung
Und was “beweist” dieser PoC — außer, dass das Konzept wie alle DRM-Versuche bescheuert ist?
Ein Grabberscript zu schreiben, das den Font holt, kostet keine zehn Minuten. Auch ablaufende Tokens würden daran nichts ändern.
“Dafür sind 99% der User aber zu blöd” ist kein Argument: Es reicht ja *einer*, der schlau genug ist, ein Tool zu schreiben. Der Rest muss nur noch auf Start klicken.
Auch eine Firefox-Extension wäre easy: Ähnlich wie es AdBlock macht in alle HTTP Requests einklinken und immer, wenn OpenType-Daten fließen, eine Kopie in irgendeinen Ordner werfen. Da können die URLs verwirbelt sein, wie sie wollen.
Ich glaube, du missverstehst, was ich mit “bescheuert” sagen will. Dass es eine extrem lästige Bevormundung des Anwenders ist, ist zwar auch wahr, aber nicht mein Punkt. Viel wichtiger ist: ES FUNKTIONIERT NICHT.
Ich habe zwei Möglichkeiten: Ich kann dem Anwender bestimmte Daten geben. Oder nicht.
Wenn ich sie ihm gebe, dann kann er damit aber (in der Praxis, nicht unbedingt rechtlich) machen, was er will. Es gibt keinen technischen Weg und es kann schon theoretisch keinen technischen Weg geben, ihn daran zu hindern. Ich kann ihn allenfalls durch irgendwelche Tricks wie URL Obfuscation ein wenig ärgern. Mehr als “ein wenig ärgern” schaffe ich aber einfach nicht, egal, wie ich mich anstrenge.
Darum ist es bescheuert, über DRM zu diskutieren. Anstatt “nur mit sicherem Zugriffsschutz!” könnten die Hersteller genausogut fordern: “Aber erst, wenn zwei plus zwei fünf ist!”
Man kann es nicht oft genug sagen: Funktionierendes DRM ist UNMÖGLICH. Wer in der Diskussion Zeit auf DRM verschwendet, setzt sich nicht für eine beide Seiten befriedigende Lösung ein. Er behindert bloß den Fortschritt durch Schwachsinn.
Momentan verfällt der Token nicht, wenn man mit einem anderen Browser als WebKit kommt. Wie gesagt: Ist nur ein Proof of Concept. Wer sich die Mühe macht, darf die Trophäe behalten.
Am schlimmsten wäre es doch, wenn die Foundries sich auf derlei einlassen und jemand auf die geheime Formel kommt, mit dem man derlei überlisten kann (wget -U “AppleWebKit/522″ -m http://www.fonts.info/webfonts/). Schwupps fühlen die sich geprellt und misstrauen den Usern NOCH mehr. Keine gute Idee.
>>>Und was “beweist” dieser PoC — außer, dass das Konzept wie alle DRM-Versuche bescheuert ist?
Dass man über eine Lösung nachdenken sollte. Wenn die Anwender sagen ”DRM ist bescheuert« und die Schriftanbieter aus Angst um ihre Fonts nicht mitspielen, dann wird es eben keine Lösung geben und die Webseiten nur um tolle Freeware-Grunge-Fonts »reicher«. Ich wäre dafür, dass man sich irgendwo in der Mitte trifft.
>>>Man kann es nicht oft genug sagen: Funktionierendes DRM ist UNMÖGLICH.
Klar. Darüber müssen wir nicht diskutieren.
Die Frage ist: Was ist die Alternative?
Die Alternative ist, dass die Hersteller entweder die Fonts ohne DRM rausgeben, oder es einfach lassen.
Wenn sie entscheiden, es zu lassen (ihr gutes Recht), dann muss die Gemeinschaft die Lücke eben mit freien Schriften füllen. Die müssen nicht automatisch schlecht sein.
Ist es ein Verlust fürs Internet, dass viele großartige Schriften praktisch nicht zur Verfügung stehen? Aber sicher. Es wäre aber ein größerer Verlust, wenn alle das Hirn ausschalten und gemeinschaftlich so tun, als könnte man die Fonts “schützen,” nur auf die theoretische Chance hin, dass irgendeine Foundry einem dafür die enorme Gnade erweist, für absurd viel Geld die Fonts kaufen zu dürfen.
Die einzig richtige Antwort auf “ich geb das aber nicht ungeschützt raus” ist und bleibt: Dann behalt deinen Scheiß halt!