Hallo Leute,
entschuldigt die Wartezeit, hier nun der Maßnahmenkatalog von seitens Mozilla/Mozilla Europe/deutsches l10n team.
Zum Anfang sollte ich wohl erst einmal buckeln. Ich habe die URL angenommen, das searchplugin getestet und eingecheckt. Ich hätte es sehen sollen, und das habe ich nicht. Tut mir leid, ehrlich. Zu meiner Entlastung, mozilla.org hat etliche Prozeduren, die genau solche Fehler vermeiden sollen. Insbesondere die <em>tree rules</em>, also unter anderem <em>reviews</em>. Das hat hier nicht funktioniert, sicherlich zu einem guten Teil, weil wir an 20-30 Übersetzungen gleichzeitig gearbeitet haben. Zumindest ich habe das.
Was passiert nun? In Absprache mit der Mozilla Foundation und eBay Deutschland haben wir die search URL zurück auf search.ebay.de gesetzt. Es wird einen neuen build geben, als fallout von bug 270299. Vielen Dank an Steffen Wilberg für den patch und das xpi. Ich werde versuchen, das xpi auf update.m.o zu bekommen, sodaß wir bald auch mit einem Klick schon installierte builds zurücksetzen können. Darüber hinaus wurde die <code>src</code>-Datei auf mozilla-europe.org entsprechend geändert, sodaß bestehende Installationen diesen Wechsel per autoupdate nachvollziehen. Das ganze wurde auf mozilla-europe.org angekündigt. Weitere Änderungen an searchplugins auf diesem Server wird es ohne vorherige Ankündigung nicht geben.
autoupdate? In der Regel geben searchplugins im BROWSER tag an, wie häufig sie die entsprechende <code>src</code>-Datei sowie ihr Icon updaten. Die searchengine code gibt daraufhin einen HEAD request auf die <code>src</code>-Datei auf dem server ab und vergleicht die modification time sowie die Dateilänge mit der lokalen Version. Richtig gelesen, der <em>"fix"</em> im c't Newsitem tut's nicht. Leider haben dort alle anderen abgeschrieben. Das wäre gegangen, wenn sie denn die update URL rausgenommen hätten. Soweit zum technischen Vorgang.
Ist das schlimm? Hier sollte man sich im Klaren sein, was searchplugins eigentlich können. Es handelt sich hier um Text-Dateien in einem XML-ähnlichen Format. Diese werden mit einem speziellen Parser eingelesen (s. a. die source). Irgendwelche Skripte oder ähnliches werden dabei nicht ausgeführt, das kann der Parser gar nicht. Bei einer Suchanfrage werden die statischen Optionen in dem searchplugin dann mit dem Suchbegrifff kombiniert und als GET (unverschlüsselt) an den server (action= Eintrag im searchplugin) übermittelt. Während dieser Aktion kann die engine keine personenbezogenen Daten einflechten, ausser den im HTTP header vorhandenen Daten (IP, accept-lang etc...). (*) Alles gut? Nicht ganz. Mozilla Firefox sollte dem User hier eine Kontrollmöglichkeit offerieren, so wie es bei software-updates, extensions oder themes schon der Fall ist. Bug 271097.
Axel Hecht
(*) Waterproof? Jein. Das Einflechten von personenbezogenen Daten kann entweder beim download entstehen, oder durch Modifikation des searchplugins auf der Platte. Ersteres setzt wahrscheinlich einen Cookie mit personenbezogenem Kontext voraus, heisst, ihr seid dem server eh schon persönlich bekannt. Ich sehe da kein wirkliches Szenario. Zweiteres setzt Schreibzugriffe auf eure Platte voraus, dann ist eh Hopfen und Malz verloren.[/url]
ich hoffe, sie fallen den nachfolgerversionen von FF DE nicht zum opfer, weil einer von ihnen nicht ganz [url=
Mach ich was falsch?? 
