Die technische Seite des Jugendschutzkonzeptes ist nicht uninteressant - wenn man denn Interesse daran hat.
[p}
Um es vorweg zu nehmen: Die Spezifikation ist ungenügend, für große oder häufig aktualisierte Websites unzureichend, enthält einige Sicherheitslücken in Größe von Scheunentoren, und wird der Realität des Webs im Jahre 2012 in keiner Weise gerecht.
Ich habe lange mit mir gerungen, ob ich einige Formulierungen in diesem Text freundlicher umschreiben soll, aber das Gesamturteil ist und bleibt verheerend. Daran ändert auch Freundlichkeit nichts, und Deutlichkeit ist hier einfach wichtig.
{h2]Einführung
Die Durchführung des Jugendschutzes obliegt dem sogenannten
Jugendschutzprogramm - das mag ein Browserplugin sein, ein Proxy-Server,
oder ein wie ein typischer Virenscanner ins System eingreifendes Programm,
der den Browser nur "gute" Inhalte sehen läßt.
Das Jugendschutzprogramm entscheidet anhand von Daten, die der Server
mitteilt, darüber, ob eine Seite angezeigt werden darf (hoffentlich mit -
öffentlich bekannt gemachten und kontrollierbaren - Ausnahemregeln für
bekannterweise falsche Daten liefernde Server).
Um diese Daten geht es hier. Wie sie auszusehen haben und übertragen werden, findet man
auf http://www.online‐management‐kontor.de/jugendschutz/altersklassifizierung.html. Grundlage für diesen Text ist Version 3.0g.
Was sollte das Datenformat leisten?
Ich trage mal, in keiner besonderen Reihenfolge, ein paar Gedanken zusammen. Mit Sicherheit wird es für einige Anwendungen noch andere Anforderungen geben.
- Interoperabel: jedes Jugendschutzprogramm muß jede gültige Altersangabe auch verstehen müssen. Weder darf es vorkommen, daß eine Seite, die als "ab 16" gekennzeichnet ist, irrtümlich als "ab 6" angesehen wird, noch sollte es vorkommen, daß eine "ab 6" Seite als "ab 16" angesehen wird.
- Sicher: es dürfen keine fragwürdigen, leicht auszuhebelnden Sicherheitskonzepte verwendet werden. Das heißt insbesondere, daß triviale Modifikationen des HTMLs oder von URLs nicht helfen dürfen, an etwaige verboten Inhalte zu kommen.
- Skalierbar: Auch große Websites mit komplexe Strukturen müssen passend gekennzeichnet werden können.
- Aktuell: Die Alterskennzeichnung muß sofort beachtet werden. Eine Seite sollte nicht erst einen Tag später als "ab 6" verstanden werden, obwohl sie sofort so gekennzeichnet wird (das gilt auch umgekehrt - wenn sich beispielsweise der Inhalt einer Seite ändert).
- Granular: Es muß möglich sein, einzelne Seitenelemente anders zu kennzeichnen. Das würde beispielsweise der Bild-Zeitung ermöglichen, ihr schlüpfriges Bild auf Seite 2 als "ab 16" zu kennzeichnen, die restliche Seite aber als "ab 6" (Zeitungen sind aber aus mir unverständlichen Gründen gar nicht erst vom Jugendschutz betroffen).
- International: Insellösungen machen keinen Sinn.
- Begründet: Last, but not least: Schlußendlich sollte ein Grund mitgeteilt werden können, warum eine Seite nicht erreichbar ist.
So könnte das aussehen:
Etwaige Fehler bitte ich zu entschuldigen, ebenso wie die unelegante Doppelverwendung von Kürzeln für Sprache und Land. Ich habe mit das im Vorfeld des Schreibens dieses Textes überlegt, und nicht allzu viel Zeit hinein investiert:
.
<html restrict='basic'>
<head>
<!-- ersatzweise auch: <link rel='restrictions' href='/restrictions.txt' /> -->
<!-- ersatzweise auch: <link rel='restrictions' href='/restrictions-20120221191706.txt' /> -->
<restrict>
* { // Vorgabe: wenn gar nichts anderes zutrifft, vielleicht wegen irgendwelcher Fehler im HTML.
age: 6;
}
restrict-basic {
age: 6;
}
restrict-hardcoreporn {
age: 18;
reason: "hardcore porn";
}
restrict-de-fsk-12: {
age[de]:12;
}
restrict-de-crime-18: {
age:18;
reason: "Enthält Anleitung zu kriminellem Verhalten.";
}
restrict-us-any-18: {
age:18;
reason[en]: "One szene might conflict with someones religious or sexual believes.";
reason[es]: "Ich-kann-kein-spanisch";
}
restrict-unknown: {
age[de]:18;
age[somewhere]:16; // ein Land mit Frühreifen.
reason[de]: "Unbekannter Inhalt";
reason[en]: "Unknown Content";
}
// reason[xx]: Sprachkürzel.
// age[xx]: Länderkürzel.
// age[us-me]: US-Bundesstaat maine.
</restrict>
</head>
<body>
<nav>
...
<a href='index.py?href=hardcoreporn' class='restrict-hardcoreporn'>...</a>
</nav>
<article>
<h1>Ein Besuch im Disneyland</h2>
</article>
<article class='restrict-basic restrict-de-fsk-12 restrict-us-any-18>
<h1>Mein erster FSK-12-Film</h1>
</article>
<article class='restrict-basic restrict-de-crime'>
<h1>Wie man sich an Alterskontrollen vorbei mogelt.</h1>
</article>
<iframe class='restrict-unknown'
src='http://tolles-ding-mit-zufälligen-inhalten.de/'>;
</iframe>
</body>
</html>
Das Datenformat sieht es bischen schwierig aus, und ist es auch, ist
aber nichts, womit nicht klarzukommen wäre - es ist an das Format für
cascading style sheets (CSS) angelehnt, und daher den mit dem Web
arbeitenden halbwegs vertraut.
Im Grunde genommen sagt der ganze Sermon: "Die Seite ist ab 6, der
Link zu den Hardcore-Pornos ab 18, die Filmbesprechnung ab 12 (außer
den den USA, wo es vielleicht irgendwelche Leute gibt, die sich an der
Kussszene im Abspann des Filmes stören könnten), und die Anleitung,
wie man an Alterskontrollen vorbei kommt, darf in Deutschland erst ab
18 Jahren gelesen werden. Der Besuch in Disneyland ist 'ab 6'.
Das zufällige tolle Ding (extern eingebunden) ist als ab 18 oder 16
einzustufen".
Erfüllt das alle Anforderungen? Sicher: Ja - so lange als Default "ab 18" gilt (das gilt allerdings auch für alle anderen Schemata). Interoperabel: So lange alle verwendeten Konstrukte durch alle beteiligten Programme verstanden werden: Ja. Skalierbar: So gut wie CSS, und damit kann das Web leben. Aktuell: ja, so wie die Seite selbst. Granular: Ja. International: Ja. Begründet: ja.
Und als zusätzliches Bonbon können die Beschränkungsklassen auch beim Styling mitverwendet werden - das heißt, der Browser kann auch Leuten, die den Hardcoreporno-Link sehen können, mit einer Warnung unterlegen - ohne zusätzlichen Aufwand.
Warum so und nicht anders?
Grund 1: Das Schema ist den meisten Leuten, die "am Web" arbeiten, vertraut, und der Lernaufwand ist gering.
Grund 2: Das Schema läßt sich recht schön in die normalen Konzepte einer Seite integrieren.
Grund 3: Man hat wenigstens den Ansatz einer Chance, das international standardisieren zu können.
Letzteres ist sehr wichtig - will man eine Insellösung vermeiden. Und ich denke, das sollte man.
Die Realität
Die Spezifikation beschreibt ein Dateiformat, und verschiedene "Types" (Methoden), mit denen der Anbieter dem Jugendschutzprogramm mitteilen kann, wie die Seite einzustufen ist.
Sie erfüllt also nicht die Anforderung Granular.
In Anhang 2 ist eine Methode geschildert, einzelne Inhalte zu klassifizieren (Bilder, Flash, ...), aber weder ist zu erwarten, daß sie in nennenswertem Umfang implementiert wird, noch kann man damit Elemente der Seite klassifizieren - nur extern geladene Sachen.
age-de.xml
Der erste Type ist diese Datei, die im Wurzelverzeichnis des Webauftritts (auch bekannt als DOCUMENT_ROOT, htdocs-Verzeichnis, ...) abgelegt werden muß.
Die Beschreibung des Formats ist mehr als 40 Seiten lang. Zum Glück ist das meiste heiße Luft. Für den Zweck des Forums würde das hier reichen:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<age-declaration>
<ageblock-basic>
<age-issuer>www.fsm.de</age-issuer>;
<last-change>2012-02-20</last-change>
<country>de</country>
<label-version>1.0</label-version>
<revisit-after>1days</revisit-after>
</ageblock-basic>
<ageblock-labeltype>
<xmlfile>true</xmlfile>
<default-age>16</default-age>
</ageblock-labeltype>
<ageblock-labeltype-definition>
<labeltype-xmlfile>
<label class="default">
<min-age>0</min-age>
<default-age>16</default-age>
</label>
<label class="Forum">
<age>16</age>
<min-age>0</min-age>
<default-age>16</default-age>
<scope>*.naturfotografen-forum.de/*</scope>
</label>
</labeltype-xmlfile>
</ageblock-labeltype-definition>
</age-declaration>
(ein paar Zeilen weggekürzt). Das ist nicht schön, aber damit kann man leben.
Allerdings schrillt schon die erste Alarmglocke: XML ohne DTD (Document Type Definition, ohne die Definition, was was bedeutet). Schade - damit wird die Möglichkeit genommen, die XML-Datei mit den üblichen Mitteln auf strukturelle Fehler zu prüfen. Was schreibt die Definition dazu:
Zitat von Kapitel 22::
Naturgemäß ist eine DTD oder XSD nicht Teil der Standard‐Definition. Es wird
Klassifizierungssystemen, die das age‐de.xml‐Labelformat generieren, jedoch empfohlen, eine
Möglichkeit zur Prüfung von age‐de.xml‐Dateien mittels einer DTD oder XSD anzubieten.
Verschiedene Anbieter von Klassifizierungssystemen sollten sich möglichst bzgl. eines Formates
abstimmen.
Ich bin nicht überzeugt, daß das
Naturgemäß ist, und daß
sich die Anbieter von Altersklassifizierungssystemen - also *Nutzer*
des Formats - darauf einigen sollen, wie das Format zu prüfen ist,
ist zumindest ausgesprochen überraschend.
Größen‐Limit
Zitat von
Kapitel 12:
Die Gesamtgröße des age‐de.xml‐Files soll
50 kb
nicht übersteigen, um Performanceprobleme beim Auslesen durch Jugendschutzprogramme zu
vermeiden. Das technisch durch Jugendschutzprogramme zu akzeptierende Maximum wird auf
maximal 200 kb festgesetzt – der Anbieter jedoch darauf hingewiesen, dass eine age‐de.xml dieser
Größe zu Performance‐Problemen führen kann.
Bitte was? Wie in aller Welt soll eine mittelmäßig große Site damit auskommen?
Das Forum für Naturfotografen hat 80000 Bilder. Ich lasse jetzt mal außen vor, daß jeder Kommentar noch auf einer eigenen Seite gezeigt werden kann.
Gesetzt den Fall, ich könnte 79000 als "ab 6" klassifizieren und müßte nur 1000 einzeln klassifizieren, und gesetzt den Fall, ich reduzierte deren URL-Länge auf das absolute Minimum:
<scope>naturfotografen-forum.de/123456</scope>
(Goodbye, sprechende URLs!)
46 Zeichen mal 1000 Exemplare = 45 KB. Mit allem Overhead wäre ich dann bei 50 KB. Dieser "Type" ist also für das Forum zumindest dauerhaft nicht geeignet.
Wollte ich beim jetzigen URL-Schema bleiben - und ich will - wäre ich übrigens bereits jetzt bei nur 1000 einzeln zu klassifizierenden Bildern bei 63 KB, plus Overhead. 64 KB wären auch nicht gut genug.
Damit ist dieser Type nicht skalierbar.
revisit-after
Zitat von Kapitel 7.1:
Anweisung an Jugendschutzprogramme, die die age‐de.xml cachen,
ggfls. die Informationen für eine Filterliste nutzen. Format wie
im alten revisit‐HTML‐Meta‐Element. Maximal akzeptierte
Angabe: „100days“, minimal ist „1days“ (keine Stunden, kein
Singular). Aktuelle Inhalte werden mit „always“ gekennzeichnet. Die
revisit‐Angabe ist für JSP optional nutzbar und für das age‐de.xml
nicht verpflichtend.
Schön und gut, aber was
bewirkt always? Wahrscheinlich, daß
die Jugendschutzprogramme die Datei bei jedem Seitenaufruf neu laden -
aber spezifiziert ist das nicht, und sinnvoll wäre das wesentlich
seltener als "stündlich".
Allerdings gehört revisit-after nicht in diesen Standard. Die
Cachekontrolle läuft bei HTTP nicht über den Inhalt der Dateien,
sondern Meta-Informationen. Und *wenn* man das schon unbedingt in der
Datei unterbringen muß, muß man zumindest spezifizieren, daß die
Jugendschutzprogramme das HTTP-Caching abzuschalten / zu umgehen haben.
Schlimmer allerdings ist die Tatsache, daß die Jugendschutzprogramme diese Anweisung nicht beachten müssen und daß nicht spezifiziert ist, was sie sonst zu tun haben. Es spricht aus meiner Sicht der Dinge nichts dagegen, daß das Programme "100days" nach Bedarf verkürzt oder "always" nicht implementiert, aber daß es "always" nicht implementiert und statt dessen die Datei erst nach 1000 Tagen wieder mal kontrollieren könnte, ist unbefriedigend.
Wie dem auch sei: Die Anforderung "Aktualität" ist damit nicht zuverlässig erfüllt.
Die Sache mit der Reihenfolge
Zitat von Kapitel 13:
Grundsätzlich gilt: Je höher im XML eine (passende) Definition steht, desto höhere Priorität genießt
sie.
Das hängt wohl von der Definition des Wortes "passend" ab:
<ageblock-labeltype>
<xmlfile>true</xmlfile>
<default-age>12</default-age>
</ageblock-labeltype>
<ageblock-labeltype-definition>
<labeltype-xmlfile>
<label class="default">
<min-age>0</min-age>
<default-age>16</default-age>
</label>
<label class="Forum">
<age>16</age>
<scope>*.naturfotografen-forum.de/*</scope>
</label>
M.m. "paßt" das Label
default grundsätzlich - muß aber niedrigste Priorität haben, nicht die höchste.
Und welches "default-age" gilt jetzt eigentlich? Das Erste oder das höhere Zweite?
Und wie spielen
- default-age (im default‐age‐Parameter [ist] stets die höchste Altersstufe anzugeben, die auf der Website (FQDN) bzw. in der definierten Bewertungseinheit vorhanden ist.),
- min-age (die niedrigste in einer Bewertungseinheit vorkommende Altersklasse), und
- age (Altersklassifizierung der Bewertungseinheit)
genau zusammen?
Und außerdem:
Zitat:
Der „default‐age“‐Parameter legt fest, welche Altersklasse gelten soll, sofern keiner der Types auf
„true“ steht oder keiner technisch valide ausgelesen werden kann.
Das heißt doch, der default-age-Parameter macht nur außerhalb der ageblock-labeltype-definition Sinn. Warum taucht er in Beispielen darin auf?
Davon abgesehen: Wenn XML nicht technisch valide ausgelesen werden kann, ist es kaputt. Und damit ist es kaputt, ungültig und unbenutzbar. Es ist beinahe immer ein Fehler, wenn man Fehler, die ein XML-Parser wirft, ignoriert.
Was bewirkt "min-age" eigentlich?
Zitat:
Sofern der Nutzer des JSP jünger ist als die Angabe im „min‐age“‐Tag, kann das JSP auf die
performancebelastende Abfrage der Label einzelner Webpages einer Bewertungseinheit verzichten.
Bitte? Bei euren lächerlichen 50-KB-Dateien soll das irgendeinen Unterschied ausmachen?
Heutige Computer durchsuchen ab ein Gigabyte unstrukturiertem Datenmüll pro Sekunde... Daher bringt uns diese unnötige Optimierung nun übertriebene Komplexität.
protocol
Zitat von Kapitel 13:
Für welche Protokolle (Alle, http, https, ftp etc.) gilt das Label. „Alle“ ist: all
Das wird vom Labelgenerator auf
http://altersklassifizierung.denicht erzeugt, ohne als optional gekennzeichnet zu sein. Hm?
Von solchen spassigen Fragen einmal abgesehen: die Beschränkung der
age-de.xml auf 50 oder maximal 200 KB würde es unmöglich machen, daß ein
großer Mailservice wie gmx.de alle möglichen Emailadressen von bekannt
gefährlichen Individuen da erfaßte - selbst wenn GMX wüßte, daß
sie welche sind.
<scope> in der URL
Zitat von Landschaftsworkshop Siegaue:
Innerhalb der URL werden bestimmte Pfade (Ordner) einer bestimmten Bewertungseinheit und
damit Altersgruppe zugeordnet. Der die Altersgruppe kennzeichnende Pfad‐Teil wird dabei von /‐
Slash umklammert. Handelt es sich um das Pfad‐Ende (also letztlich eine konkrete Datei), kann auch
auf den abschließenden Slash verzichtet werden.
Ich könnte die "ab 12" Sachen im Forum also mit URLs wie
Baer-frisst-Bambi
ablegen. Ohne das näher durchdacht zu haben: Es gibt, ein, zwei Stellen, an den das Schwierigkeiten machen würde. Aber machbar wäre es, und es würde das 50-KB-Problem vermeiden.
Nur läßt die Spezifikation zu wünschen übrig:
Zitat von Landschaftsworkshop Siegaue:
Ob das CMS im „Inneren“ andere Pfade kennt, auf die z.B. per 301‐Weiterleitung oder durch andere Techniken von
der die Kennzeichnung enthaltenden URL verwiesen wird, ist dabei unerheblich.
Das heißt, der Server darf, wenn /ab12/o123456-Baer-frisst-Bambi aufgerufen wird,
den Browser bzw. das Jugendschutzprogramm anweisen, /o123456-Baer-frisst-Bambi ohne "ab 12" zu holen?
Glaubt jemand, daß das eventuell gefährdete menschliche Wesen im Alter
von 12 bis 15 das nicht merkt, und daraus nicht den Schluß zieht, daß /ab18/o123458-Baerenkopula-Hardcore
auch als /o123458-Baerenkopula-Hardcore zu erreichen ist? (Falls doch:
es sollen schon real existierende Zwölfjährige mit mehr als einer
Gehirnzelle gesichtet worden sein)
Da darf eben keine Weiterleitung auf weniger restriktiv klassifizierte URLs geschehen, sondern weniger restriktive Aliasse müßten im Gegenteil auf den restriktivsten weiterleiten... so jedenfalls erfüllt das die Anforderung Sicherheit nicht.
Kurz gesagt: Das ist kein Schutz, das ist Unsinn.
<scope> als URL-Variable
Zitat von Landschaftsworkshop Siegaue:
Bewertungseinheiten können auch in der URL als Variable gekennzeichnet werden. Variablen können
flexibel innerhalb des gesamten Angebotes gesteuert werden, ohne dass dafür die Serverstruktur
grundlegend geändert werden muss. Variablen sind deshalb auch für anspruchsvolle Server‐Parks
und große Angebote mit zahllosen Webpages eine Alternative.
Das ist etwa so gemeint:
<label class='default'>
<min-age>6</min-age>
<default-age>18</default-age> // ???
<scope>mindestalter=6/<scope>
</label>
<label class='twelve'>
<min-age>12</min-age>
<default-age>18</default-age> // ???
<scope>mindestalter=12/<scope>
</label>
<label class='sixteen'>
<min-age>16</min-age>
<default-age>18</default-age> // ???
<scope>mindestalter=16/<scope>
</label>
Damit hätte man die Möglichkeit, die Altersklassifizierung in der Seiten-URL unterzubringen, und
diese URL zu meinem Profil würde den Jugendschutz-Programmen signalisieren, daß es erst ab 18 freigegeben ist.
Falls Du, lieber Leser, jetzt nicht auf Anhieb erkennst, wo das Problem ist, frag' doch bitte mal Deine Kinder, Enkel oder so. Die werden es Dir ganz schnell erklären.
Richtig, man muß nur eben in der URL herumpfuschen, und aus mindestalter=18 wird mindestalter=0. Es ist auch nicht unverstellbar, daß es demnächst Browserplugins geben wird, die einem diese Arbeit annehmen.
Das könnte durch eine serverseitige Kontrolle des in der URL angegebenen Mindestalters abgefangen werden, bei der der Server den Browser dann auf die richtige URL weiterleitet. Das wäre für das Forum hinreichend einfach machbar, aber ich weiß von anderen Softwarelösungen, die in dem Bereich nicht so flexibel sind. Nur: solche Maßnahmen sind nicht vorgesehen, wenn ich da nichts übersehen habe.
Siehe auch die abschließenden Absätze zu 13.1.2.
Der „alternate“‐Tag
Zitat von
Kapitel 8.3:
Mit dem Alternate‐Tag wird angegeben, auf welchen Content (URL) das Jugendschutzprogramm den
User im Fall einer Sperre umleiten soll – statt einer einfachen Blocking‐Page.
Der Alternate‐Tag kann in der einfachen Version als einfaches „alternate“ angegeben werden und
weist dann auf eine für alle Altersklassen gültige Alternativ‐URL.
Beispiel:
<alternate>http://www.site.de/kinderblockinfo</alternate>;
Es können jedoch auch nacheinander altersklassenbezogene „alternateXX“‐Tages genutzt werden,
wobei die ergänzte Altersklassen‐Zahl angibt, ab welchem Alter der Alternativ‐Content tauglich ist.
Das klingt sinnvoll, entspricht aber nicht dem, was im Rest der Spezifikation verwendet wird. Die sieht nämlich so aus:
<ageblock-labeltype>
...
<alternate age=“16“>http://www.site.de/jugend</alternate>;
<alternate age=“12“>http://www.site.de/kinder</alternate>;
<alternate>http://www.site.de/kleinste</alternate>;
Warum ist die <alternate>-Angabe eigentlich auf dem <ageblock-labeltype>-Niveau ansiedelt? Was spräche gegen:
<label class='sixteen'>
<min-age>16</min-age>
<default-age>16</default-age>
<scope>*/softporn</scope>
<alternate>/sorry.py?reason=Für+Softpornos+mußt+Du+mindestens+16+sein!
</label>
?
Der Type HTTP-Header
Diese Methode der Kennzeichnung verwendet einen HTTP-Header:
X-content‐age: 12
Das ist wenigstens schön einfach.
Auf der negativen Seite ruiniert es jede Chance auf Internationalisierung (für welches Land gilt das eigentlich?).
Davon abgesehen wäre das etwas, was zwar nicht wirklich alle meine Wünsche erfüllt (immer noch zu geringe Granularität), aber halbwegs ausreicht und vor allem benutzbar ist. Aber:
Jugendschutzprogramme müssen nicht alle Types können
Obige Überschrift ist die Überschrift von Kapitel 9 der
Spezifikation. Gemeint ist, daß die Jugendschutzprogramme nicht alle
Arten, die Alterskennzeichnung anzugeben, auch verstehen müssen. Sie
müssen nicht alle Varianten implementiert haben - nur eine muss vorhanden
sein: Die age-de.xml-Methode.
Mit anderen Worten: Als Betreiber einer Website kann man sich nicht darauf verlassen, daß X-content-age funktioniert. Warum sollte man es also implementieren? Warum sollte dann überhaupt irgendein anderer "Type" als age-de.xml jemand implementiert werden?
Wenn ein solches Feature benutzt werden können soll, darf es nicht optional sein.
Der Type <meta>-header
Diese Methode der Kennzeichnung verwendet ein meta-tag im HTML-Header:
<meta name="age-de-meta-label"
content="age=16 info=naturfotografen-forum.de/age-de.xml
v=1.0 kind=sl protocol='all' "/>
Leider reichen 40 Seiten aber nicht aus, das vernünftig zu beschreiben -
es ist nicht klar, was "kind" eigentlich bedeutet. Einzige Information darüber:
Ggfls. Erstellung‐Art des Meta‐Labels (sofern z.B. für Web 2.0‐Content vereinfachtes Verfahren). Und weiter fehlt auch jeder Hinweis darauf, was das vereinfachte Verfahren sein könnte.
Das macht keinen ausgereiften Eindruck. Was bewirkt dieser Wert "sl"? Was bewirken andere Werte? Müßte nicht irgendjemand bereits darüber gestolpert sein, zum Beispiel die Hersteller der Jugendschutz-Programme?
Das mal außen vor lassend, liefert der Versuch, eine Seite mit einer solchen Alterskennzeichnung mit dem W3C-Validator zu prüfen Bad value age-de-meta-label for attribute name on element meta: Keyword age-de-meta-label is not registered - offensichtlich hat sich niemand die Mühe gemacht, diesen Header zu standardisieren (das kann man ziemlich formlos hier tun).
Nun ist es nicht besonders wichtig, ob die Namen in einem meta-Header nun registriert sind oder nicht (es nervt nur etwas beim validieren), aber als weiteres Zeichen, wie ausgereift dieser Standard ist, taugt das durchaus.
Außerdem ist auch dieser "Type" praktisch unbrauchbar (siehe "Jugendschutzprogramme müssen nicht alle Types können").
Mit anderen Worten: Der einzige "Type", der garantiert vorhanden ist, ist für uns unbrauchbar, und zwingt zu einer Einstufung aller Inhalte auf dem Niveau des schlimmstmöglichen Inhalts.
Der Type Label-Z
Zitat von
Kapitel 17:
Das „Label Z“ (Z = Zeitsteuerung) erlaubt es, die Sendezeitbeschränkung nach § 5.3.2 JMStV als
zulässiges vollwertiges und gleichberechtigtes Instrumentarium des gesetzlichen
Jugendmedienschutzes einzusetzen oder – falls vom Anbieter gewünscht – die Sendezeitbegrenzung
mit dem neuen Jugendschutzlabel zu kombinieren.Das „Label Z“ teilt dem JSP mit, dass der Anbieter die Sendezeitsteuerung einsetzt und damit
außerhalb des Label‐Systems (und damit auch außerhalb der mit dem Label nach JMStV ggfls.
verbundenen Privilegierung) die Contents nach JMStV‐Sendezeitbeschränkung selbst steuert.
Schön und gut, wenn man davon absieht, daß auch dieser "Type" nicht implementiert sein muß. Also muß der Anbieter, selbst wenn er nur zwischen 23 und 6 Uhr schmutziges Zeug (oder so) sendet, in der age-de.xml das Mindestalter auf 18 setzen, und kann davon ausgehen, daß alle Jugendschutzprogrammme, die "label-z" nicht implementieren, seine Seite auch am Tag, wenn er Kinderprogramme sendet, sperren werden.
Der Fall kommt zum Glück nicht vor, weil soetwas wie Sendezeitbeschränkung oder je nach Uhrzeit wechselnde Porno- und Kinderprogramms-Inhalte im Netz ziemlich ungewöhnlich sind.
Auf der anderen Seite frage ich mich ja, wie diese Sendezeitbeschränkung unsere gefährdeten Jugendlichen, die sich gerade mal für einen Urlaub im Ausland und in einer anderen Zeitzone befinden, schützen soll... aber das nur als unnütze Frage am Rande.
Die Anlagen
Ich wollte mir das eigentlich schenken, aber auf Wunsch eines einzelnen Herrn gehe ich trotzdem kurz darüber:
Anlage1: Definition eines „B2B‐Info‐Standards
Da geht es darum, wie man beim Einbinden von Inhalten anderer Sites Altersklassifizierungen übertragen kann
(was B2B in dem Zusammenhang soll ist mir ein Rätsel - das ist normales Web 2.0).
Zitat:
Die in dieser „Anlage“ genannten Standards sind nicht direkt Teil des zu definierenden Jugendschutz‐
Labels (Kennzeichnung) als Schnittstelle zwischen Telemedium und Jugendschutzprogramm und
haben insofern keine bindende Wirkung nach JMStV.
Gleichwohl erscheint es sinnvoll, an dieser Stelle übergreifende Standards zu definieren, wie
Altersklassen bei Einzelcontents „mitgegeben“ werden sollten, damit Anbieter insbesondere vor dem
Hintergrund dynamischer Website‐Steuerung von allen ihren möglicherweise zahlreichen Content‐
Lieferanten die Altersangaben im gleichen Format bekommen.
Ich übersetze "Dies ist eine Anlage, hat keine bindende Wirkung, soll aber einen Standard definieren" und sage gleich schon mal voraus, daß das nichts werden wird.
Nein, nicht nur deshalb, sondern auch wegen der Interna.
Das kann so aussehen:
<script=http://trailerverteiler123.de/567895678
width=“816“ height=“485“
age‐de=“16“>
</script>
Ich habe es auf das wesentliche gekürzt. Kurz gesagt: Das wird nie funktionieren. Zwar kann man, mit noch einigem CSS, ein Script-Tag tatsächlich darstellen, aber es hat keinen Inhalt - und ich würde mich nicht darauf verlassen, daß das überhaupt in allen Browsern funktioniert. Und Grund zwei: Der Code lädt ein Script, ruft es aber nicht auf. Grund 3: Und wenn das Script später angerufen werden sollte, ist das age-de vergessen.
Vermutlich hat Anlage 1 nie das Auge eines Menschen passiert, der mit HTML schon mal gearbeitet hat.
Wenn man das <script>- durch ein <objekt>- oder <iframe>-Tag ersetzt und das age-de entsprechend richtig ändert, beginnt die Sache Sinn zu ergeben. Allerdings fällt auf, daß plötzlich der Inhalts-Lieferant dafür zuständig ist, die passende Altersklasse einzuhalten. Richtig, jetzt auf einmal geschieht diese Prüfung nicht mehr beim Jugendschutzprogramm, sondern auf dritter Seite.
Das macht keinen großen Unterschied? Doch, doch, das macht sogar einen sehr großen Unterschied. Bisher war das Jugendschutzprogramm dafür zuständig, die Prüfung zu machen, und der Server war zuständig, zu klassifizieren. Und das Jugendschutzprogramm enthält Black- und Whitelists - also zusätzliche Informationen, was erlaubt und gesperrt sein soll (möglicherweise zusätzliche Anforderungen der Schule, der Eltern, ...). All das allerdings steht dem Server und der dritten Seite nicht zur Verfügung.
Folglich werden hier potentiell sowohl die Sicherheit aufgeweicht als auch zusätzliche eingeräumte Rechte ignoriert, m.a.W., die vorhandenen Eingriffsmöglichkeiten der Eltern werden reduziert.
Kapitel 19: Anlage2: Bewertung von Einzel‐Content
Zitat:
Die Altersklassifizierung von Webpages als kleinster Bewertungseinheit macht es überflüssig, die
Vielzahl der in der Seite ggfls. enthaltenen Einzel‐Contents (Bilder, Videos etc.) jeweils einzeln mit
einer Altersangabe zu klassifizieren – und diese Altersangabe jeweils durch das
Jugendschutzprogramm auszulesen und zu bewerten (was in vielen Anwendungsfällen zu einer
extremen Performance‐Verschlechterung führen kann).
In einigen Telemedien‐Konstellationen ist es jedoch wünschenswert, auch Einzel‐Contents mit einer
Altersklasse zu versehen (z.B. Filmtrailer von einem zentralen Content‐Lieferanten), die das
Jugendschutzprogramm direkt auslesen kann.
Ich habe eben auf den Kalender geschaut. Es ist 2012.
In 2012 ist es auf großen Portalen üblich, Inhalte von anderen Anbietern
einzubinden, und auch üblich geworden, auf speziellen Übersichtsseiten
viele Inhalte in Kurzform als Teaser zu zeigen (man findet das Konzept
seit mindestens 10 Jahren auf den Startseiten der meisten Zeitungen).
Das würde es schon sinnvoll machen, wenn als kleinste Bewertungseinheit
etwas Kleineres als die ganze Seite möglich wäre.
Was die Performance‐Verschlechterung betrifft: sicher, wenn ich
eine Seite habe, auf der 100 Inhalte von 100 verschiedenen Anbietern
eingebunden werden und die Prüfung nach dem vorliegenden Konzept erfolgt,
dann gibt es beim ersten Aufruf durchaus Performance-Einbußen. Nun
ist der Fall nicht gerade häufig, aber für die paar Fälle könnte
man immer noch bei den Herstellern von Antivirus-Produkten nachfragen,
wie sie es schaffen, daß die Performance noch erträglich bleibt.
Aber die Performance-Einbußen gibt es auf jeden Fall, sogar dann, wenn
über den HTTP-Header X-content-age die Altersangabe des Inhalts mitgeliefert
würde, denn selbst in diesem Fall müßte die age-de.xml von 100 Servern
geladen werden, um nachzusehen, ob <httpheader>true</httpheader>
darin gesetzt ist...
Ja, klar, so kann man die Performance durchaus ruinieren. Man muß sich
aber schon etwas anstrengen.
Das Problem der sich ändernden Inhalte
Nehmen wir an, ein Bild zweier Enten sei "ab 0" klassifiziert. Später
schreibe jemand einen Kommentar "die sehen auch, als kopulierten sie
gleich". Nehmen wir an, der Kommentar wird "ab 6" eingestuft, und die
ganze Bildseite nun ebenfalls (dank fehlender Granularität).
Nun müßte das Bild von:
/o123456-Enten
auf
/ab6/o123456-Enten
verschoben werden, und im Interesse der Sicherheit der Server den Zugriff auf neue Variante weiterleiten.
Technisch wäre das etwas aufwändig, weil ich mich bisher nicht dafür interessiere, wie ein Objekt angesprochen wird - Hauptsache, ich habe eine eindeutige Identifikation.
Dasselbe gilt auch, wenn nachträglich eine Klassifizierung geändert wird, weil ein Fehler passiert ist (Fehler passieren!).
Die Spezifikation übergeht das Problem sich ändernder Inhalte oder Klassifikationen vollkommen.
Internationalisierung
Außer dem beim HTTP-Header schon erwähnten Problem gibt es noch eines: In den USA gibt es Bundesländer mit deutlich unterschiedlichen Jugendschutz-Regeln. Die vorliegende Spezifikation übergeht dieses Detail (das mit Hilfe von 50 age-us-xx.html-Dateien nachzurüsten wäre offensichtlich möglich und offensichtlich unsinnig).
Bewertung
Folgende Anforderungen werden nicht oder teilweise nicht erfüllt.
- Interoperabel: das ist nur auf dem beschränktestem Niveau gegeben. Auf die flexiblen Types kann man sich nicht verlassen, denn alle Types außer "age-de.xml" müssen vom Jugendschutzprogramm nicht verstanden werden.
- Sicher: Ausgerechnet beim einzigen zuverlässig implementierten Type sind Varianten mit URL-Manipulation unsicher. Die Spezifikation müßte mindestens um die Anforderung an den Server, Zugriffe auf weniger restriktive URL-Varianten auf die gerade geltende restriktive Variante weiterzuleiten (statt ausgerechnet den umgekehrten Weg zu erlauben) ergänzt werden. Ersatzweise: diese Types sind zu streichen.
- Skalierbar: Zum gegenwärtigen Zeitpunkt ist "sichere" Variante des zuverlässig verfügbaren "Types" für große Sites unbrauchbar.
- Aktuell: der zuverlässig verfügbare Type ist nicht notwendigerweise aktuell. Die Altersangabe-Definition kann ein beliebiges Alter haben.
- Granular: Nein.
- International: Der Type "HTTP-header" unterläuft das.
- Begründet: Nein. Man kann zwar pro Altersklasse und age-de.xml Datei unterschiedliche alternative URLs angeben, aber keinen Grund.
In meinen Augen erfüllt die Spezifikation keine der Anforderungen, und teilweise bleibt sie in einem erschreckenden Maße dahinter zurück. In ihrem jetzigen Zustand ist kaum vorstellbar, daß der geplante deutsche Jugendschutz ein Erfolg wird.
Ich hatte erwartet, daß ich nicht erfreut sein würde. Wie undurchdacht die Spezifikation aber tatsächlich ist, hatte ich nicht erwartet.
An etlichen Stellen der Spezifikation wird von Performance gesprochen. Ich kann mir beim besten Willen nicht vorstellen, daß die Autoren eine Spur von Erfahrung haben - sonst wüßten sie, daß 50 oder 200 KB zu durchsuchen kein Problem ist, daß allerdings überflüssige HTTP-Requests ein Problem sein können, und daß man daher solche Types als Standard vorschreiben müßte, die diese vermeiden - und das dann auch noch so, daß überhaupt keine Dateien durchsucht werden müssen.
