Traue keinem Scan, den du nicht selbst gefälscht hast

jens · Montag 12. Januar 2015, 14:00

Kopierer, die spontan Zahlen im Dokument verändern: Im August 2013 kam heraus, dass so gut wie alle Xerox-Scankopierer beim Scannen Zahlen und Buchstaben einfach so durch andere ersetzen. Da man solche Fehler als Benutzer so gut wie nicht sehen kann, ist der Bug extrem gefährlich und blieb lange unentdeckt: Er existiert über acht Jahre in freier Wildbahn.

Ansehen: http://media.ccc.de/browse/congress/201 ... html#video

jens · Montag 12. Januar 2015, 14:25

Ab ca. 28Min wird es richtig interessant...

mutetella · Montag 12. Januar 2015, 15:30

Mit einem Wort: Irre!

mutetella

jens · Montag 12. Januar 2015, 15:43

Was ich nicht ganz verstehe, bei der Entwicklung von JBIG2 ( https://de.wikipedia.org/wiki/JBIG2 ), dem verwendeten Kompressionsstandart, hätte man doch wissen müßen, das Pattern-Matching zu Fehlern führen wird...

mutetella · Montag 12. Januar 2015, 16:25

@jens
In der Wildnis geschehen halt dann doch andere Dinge, als unter Laborbedingungen. Und gut möglich, dass keiner der JBIG2-Beteiligten großen Bock darauf hatte, jede Text enthaltende jbig2-Datei genauestens mit dem Original zu vergleichen. Und das mit möglichst vielen gängigen Schriftarten und unter verschiedenen Bedingungen. Und wie man in dem Vortrag ja sieht, treten die Fehler bei ähnlichen Zeichen auf. Und das merkt man erstmal nicht, weil unser Hirn eine der genialsten Fehlerkorrekturen ever besitzt...

mutetella

jens · Montag 12. Januar 2015, 16:34

Es muß ja so sein, das man eine Toleranz eingebaut hat. Also die Teile müßen sich nur zu x% ähnlich sehen. Das war der eigentliche folgenschwere Fehler...

Denke mal bei der Entwicklung von jbig2 hat man daran schlicht nicht gedacht...

Da würde mich jetzt mal die Haftungsfrage interessieren... Eine Firma hat im großen Stil auf Pappierlos umgestellt und nutzte dazu einen Xerox Kasten. (Ist ja nicht wirklich unwahrscheinlich)... Nun haben sie also ein gefälschtes Archiv und nun?!?

Vermutlich, so war ja auch das Fazit im Vortrag, wird alles schön unter den Teppich gekehrt...

EyDu · Montag 12. Januar 2015, 16:37

Ich denke schon, dass das den Entwicklern völlig klar war. Es kommt halt darauf an, wie man den Algorithmus umsetzt. Hat man ein Dokument welches 1:1 kopiert werden soll, mal abgesehen der Glättung durch die Kompression, dann darf eben keine blinde Substitution verwendet werden. Dann funktioniert das Pattern-Matching auch wunderbar, da zu jeder Stelle das entsprechende Differenzbild gespeichert wird.

Darin bestand ja auch gerade der Fehler bei Xerox. Man war dort der Meinung, dass die Ersetzung auf einigen Qualitätsstufen nicht aktiviert war, sie war es aber trotzdem. Also ein Bug in der Software, keine Schwäche des Kompressionsverfahrens an sich.

jens · Montag 12. Januar 2015, 16:54

btw. ich denke der Fehler von Xerox werden auch noch einige Andere gemacht haben...

Auf die schnelle mal gesucht:
Anscheinend kann man in Adobe Software zur PDF Erzeugung/Bearbeitung ebenfalls JBIG2 nutzten, siehe: http://blogs.adobe.com/acrobatineducati ... _part.html

Bei http://www.konradvoelkel.com/2013/03/scan-to-pdfa/ wird auf der Tipp gegeben, JBIG2 zu nutzten, weil es "besser" komprimiert.

JBIG2 gibt es als OpenSource Modul, hier: https://github.com/agl/jbig2enc/

Eigentlich ist es doch so: Das Pattern-Matching, bei Text, macht nur mit einer sehr sehr niedrigen Differenz Sinn... Also wenn Buchstaben so klein sind, das man sie so oder so nicht auseinander halten kann. Die Grenze dabei herrausfinden ist allerdings aufwendig und sollte recht konservativ vorgenommen werden...

Frage mich, wie das in der jbig2enc Lib geregelt ist bzw. in anderen Implementierungen... und wo wurden sie überall eingesetzt...

Das Thema Papierloses-Büro ist ja nun schon seid ein paar Jahren in der "Erprobung"... Da wird sicherlich oft genau sowas gemacht.

Bin gespannt was noch kommen wird...

mutetella · Montag 12. Januar 2015, 17:42

Wobei ich mich frage, weshalb in Zeiten von unverschämt günstigem Speicherplatz die letzten Bytes mittels eines Verfahrens herausgepresst werden, bei dem mindestens bei Texten Fehler nie ausgeschlossen werden können. Ein Verfahren, das bei einer 6 von einer 8 ausgeht, weil eben die 8 schon mal ausgesehen hat, wie eine 6...

mutetella

jens · Montag 12. Januar 2015, 17:47

Wahrscheinlich Historisch bedingt..? JBIG2 ist von 2000 und der Xerox Bug ist mindestens 8 Jahre alt.

Zeitlicher Ablauf und mehr Informationen hier: http://www.dkriesel.com/xerox

EyDu · Montag 12. Januar 2015, 17:56

jens hat geschrieben:Eigentlich ist es doch so: Das Pattern-Matching, bei Text, macht nur mit einer sehr sehr niedrigen Differenz Sinn... Also wenn Buchstaben so klein sind, das man sie so oder so nicht auseinander halten kann. Die Grenze dabei herrausfinden ist allerdings aufwendig und sollte recht konservativ vorgenommen werden...

Du hast das Matching glaube ich nicht ganz korrekt verstanden. Es geht nicht darum zu schauen, was ein "e" und ein "y" gemeinsam haben, sondern was alle "e"s im Text gemeinsam haben. Dann sucht man sich das durchschnittlichste "e" aus und stellt alle anderen "e"s als Differenzbilder da. Diese Differenzbilder lassen sich dann wieder sehr gut komprimieren, da sie quasi keine Information enthalten. Das macht man dann für alle Symbole im Dokument.