Informatik, Photos, und Ameisen in einem Terrarium.

David ist Informatiker mit biologischem Interesse. Ihn faszinieren dezentral organisierte Systeme. Er arbeitet als Systemingenieur bei der IVU Traffic Technologies AG an Themen im Umfeld von Continuous Delivery und DevOps.




Xerox untersucht neue Nummernvertauschungs-Funde

Im zweiten Presse-Statement von Xerox hat Rick Dastin, Vice President at Xerox Corporation, gesagt: „You will not see a character substitution issue when scanning with the factory default settings.“ In Xerox' offiziellem Technischen Statement zum Thema werden diese factory default settings definiert: Gemeint sind der Kompressionsmodus „higher“ und eine Auflösung von mindestens 200 dpi. Für diesen Kompressionsmodus (und den darüber) sind auch keine „character substitution“-Hinweise in den Bedienungsanleitungen oder Admin-Panels; zumindest nicht in denen, die ich kenne.

Heute im Laufe des Tages konnte ich nun das Nummernvertauschungsproblem auf einem Xerox WorkCentre 7545 reproduzieren, und zwar unter Benutzung des „higher“-Kompressionsmodus, mit noch großzügiger gewählten 300 dpi Auflösung. Wie ihr euch alle vorstellen könnt, könnte das auf ein sehr ernstes Problem hindeuten. Nicht nur würde das Zahlenvertauschen auch mit den Fabrikeinstellungen vorkommen und damit alle betreffen, auch Xerox' Pressestatements wären nicht akkurat gewesen, wenn auch sicher wohlgemeint.

Hätte es wirklich so einfach sein können, Xerox?

Ich bekomme Kommentare und Mails, die etwas sehr interessantes sagen. Kann es sein, dass im hier verwendeten JBIG2-Algorithmus direkt ein „Lossless“-Flag eingebaut ist, der den ganzen Mist hätte verhindern können, wenn man ihn nur angestellt hätte? Diese Pressemeldung sagt das zumindest (danke, Flavio). Money Quote:

supports traditional “lossless” compression, but also a new „lossy“ type of image compression, whereby the compression factor is increased on average by a factor of about 3 to 10, without noticeable visual differences compared with the lossless mode.

Die „lossy“-Variante ist das, was die Fehler hier verursacht. Das wichtige ist, wie der Auszug zu lesen ist. Der Faktor 3-10 bezieht sich auf die Lossy-Variante. Insgesamt heißt das, dass JBIG 2 wohl im lossless mode etwas kleinere Dokumente produziert als andere Kompressionsverfahren, und im lossymode noch mal massiv kleinere, aber u.U. auf Kosten der Datenintegrität.

Nummern-Veränderungen vielleicht nicht nur ein Xeroxproblem?

Die Frage, ob die Scanfehler nur ein Xeroxproblem sind, könnte beantwortet worden sein. Ich habe eine Mail von einem Brother-Kunden erhalten, der den Fehler auf einem Brother MFC-9140CDN reproduzieren konnte. Angehängt an die Mail war eine ausgedruckte und eingescannte Seite meines Zahlen-TestPDFs, wo mindestens eine 6 ersetzt wurde durch eine schöne, saubere 8. Anfrage bei Brother steht aus.

Edit: Brother hat sich gemeldet, und gesagt, dass sie vom Problem nicht betroffen sind. Auf den ersten Blick sieht es so aus, als würde der Brother weniger Ziffern ersetzen als die Xerox-Geräte. Aber, Vorsicht: Ich habe diesen Fehler nicht selbst reproduziert, und leider steht die Geräte-ID auch nicht im PDF, sondern dort steht „Paperport 12“, also kann ich auch nicht wissen, auf welche weise die Daten jetzt wo genau durch die Mangel gedreht wurden. Es könnte auch die empfangende Software gewesen sein. Nehmt es als Hörensagen und seid verantwortungsvoll, wenn ihr irgendwas verbreitet. Diese Meldungen schlagen im Moment so ein, dass man niemals sicher sein kann, dass irgendeine potentielle Sensationsmail in meiner Box nicht Bestandteil einer Spindoctorkampagne ist. Nichtsdestotrotz nehme ich gerne weitere Geräte in meine „Hörensagenliste möglicherweise betroffener Geräte“ auf. 8-)

Xerox kündigt Softwarepatch an

Einen Tag nach dem ersten Statement, das im wesentlichen bereits bekannte Informationen enthielt, gibt es nun ein weiteres Statement von Xerox.

Darin kündigt Xerox einen Softwarepatch an, der den fraglichen Kompressionsmodus komplett abstellt. Das ist die absolute Radikallösung, denn der Modus wurde immerhin in den Hochglanzprospekten als High-end-Feature hervorgetan. Wie ich hier ja schon mehrfach geschrieben habe, ist patch based lossy compression in einem Dokumentenscanner eher fehl am Platze.

Speicherknappheit ist nicht mehr verbreitet, und wenn man bei keinem der gescannten Dokumente Rechtssicherheit hat, oder Angst haben muss die Rentenkasse zu entlasten, indem man der eigenen Oma die Medikamentendosierung mit Xerox-Geräten scannt, ist das sicherlich auch nicht im Sinne des Erfinders.

Der Tag danach

… wird wohl noch etwas auf sich warten lassen.

So halb war ich drauf gefasst, dass die Sache jetzt an Schwung verlieren würde, und ich habe ja auch nicht vor, Xerox zu schaden. Ich habe mich ernsthaft gefreut, wie offen sie auf mich zugegangen sind und habe daher auch ernsthaft versucht, zu helfen.

Aber – Stammleser kennen diesen Satz schon – wir gehen nun über zur Thematik „das Internet vergisst nichts.“ Lest mal die teilweise harschen Kommentare unter dem Xerox-Statement! So ganz scheint man sich nicht damit zufrieden zu geben, dass ein einmaliger kleiner Hinweis beim Einstellen der Kompression auf „Normal“ (sic!) ausreichen soll, um mögliche Jahresladungen subtil verfälschter Dokumente über vielleicht zigtausende Unternehmen weltweit einfach abzuhaken. Die Seite läuft schon den ganzen Tag über bei bis zu 160 Hits pro Minute, weil die Xerox-Sache so ganz, ganz langsam die Massenmedien erreicht. Ein Bekannter von mir hat die Sache auf eine wunderschöne Art und Weise auf den Punkt gebracht, die ich euch nicht vorenthalten möchte:

Oh, wow, David, du bist am Arsch. Es steht GANZ KLAR im Bedienerhandbuch. Oder hast du etwa die Seite 107 von 328 nicht gelesen? – Das ist ja, wie wenn ich im Auto die Heizung auf exakt 21 Grad stelle, dann deswegen die Bremse nicht funktioniert, und sich die Herstellerfirma nach Jahren von unerklärlichen Unfällen auf Seite 107 im Manual bezieht, wo ganz klar steht, dass man nun mal nicht exakt 21 Grad einstellen sollte, wenn man auch bremsen will.

Treffer, versenkt – wobei vergessen wurde, dass ich meinen Blogartikel ja gar nicht erst geschrieben hätte, wenn der Xerox Support über alle Level hinweg mal auf das Schlagwort „Character Substitution“ reagiert hätte. Den Mund hab ich mir fusselig geredet.

Einenhabichnoch, einenhabichnoch: Den besten und trockensten Kommentar zum Thema habe ich auf Gizmodo gelesen. „You had 1 Job, Xerox, 8 Job.“ LOL

Bleibt mir gewogen, und natürlich wird hier weiter zum Thema gepostet, sobald es was neues gibt. Vielen herzlichen Dank für die Unterstützung aus aller Welt!

Edit: Noch eine (ernstere) Sache, die ich die ganze Zeit gefragt werde. Kann das mehr als nur ein Xerox-Problem sein? Ich denke, ja. JBIG2 ist ein mächtiges Kompressionsverfahren, aber wie wir alle sehen, kann es gefährlich werden, wenn es falsch eingesetzt wird. Der wichtige Punkt ist, dass die Benutzer nicht sehen können, dass der Scan falsch ist. Andere Kompressionsverfahren lassen Zahlen unter Artefakten untergehen, und dann sieht man das und scannt eben neu. Hier werden kaputte Zahlen durch wunderschön aussehende, jedoch vielleicht inkorrekte ersetzt. Das macht den Fehler extrem schwer zu finden. Diese Sache existiert in Xeroxmaschinen anscheinend über Jahre hinweg, und *jetzt*, wo die Leute aufmerksam geworden sind, reproduzieren sie den Fehler über die ganze Welt hinweg. Natürlich kann das auch bei Maschinen genauso passieren, die nicht von Xerox sind.

Was Xerox angeht: Ich stimme mit Xerox überein, dass die Sache nicht in dem Sinne ein Bug sein muss (it's not a bug, it's a feature!!1) :-) – aber in jedem Fall ist es der Supergau unter den Kommunikationspannen sowohl vom Aspekt der Dokumentation, als auch vom Support, als auch von der Reaktionsgeschwindigkeit der Pressestelle her. Und diese Panne erzeugt dann leider exakt die Folgen, die ich gefürchtet habe, als ich noch davon ausging, es wäre ein Bug.

Andere sehen das nciht ganz so rosig. Mir ist mehrmals die Hypothese zugetragen worden, dass das durchaus ein Bug war, der Xerox irgendwann zugetragen wurde – und dann konnten sie natürlich keinen Rückschritt machen, sondern haben das „Normal“-Setting nicht mehr als Default rausgegeben und eine kleine Meldung daneben platziert. Dass Patch-Based lossy compression in einem Dokumenten-Scankopierer nicht sinnvoll einzusetzen ist, macht diese These nicht unplausibel.

Mag jeder selbst sehen, was er am wahrscheinlichsten findet.

Recent changes RSS feed Creative Commons License Donate Minima Template by Wikidesign Driven by DokuWiki