uBlock-Origin-Lite-Entwickler beendet Unterstützung für den Firefox-Store

 (neowin.net)
2 Punkte von GN⁺ 2024-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • uBlock Origin Lite wird nicht mehr über den Firefox Add-ons Store verteilt, und Entwickler Raymond Hill hat die Erweiterung auf Self-Hosting umgestellt
  • Das Mozilla-Review-Team markierte Anfang September alle Versionen als Richtlinienverstoß und beanstandete dabei sowohl eine angebliche Erfassung von Nutzerdaten als auch „minified, concatenated or otherwise machine-generated code“
  • Hill entgegnete, diese Kritik ergebe keinen Sinn für jeden, der JavaScript grundsätzlich verstehe, und bezeichnete den Review-Prozess als „nonsensical and hostile“
  • Mozilla räumte später in einer in einem GitHub-Issue enthaltenen E-Mail den Fehler ein und entschuldigte sich, doch uBlock Origin Lite ist auf addons.mozilla.org weiterhin nicht auffindbar
  • Firefox-Nutzer müssen die neueste Version von GitHub beziehen; das bisherige uBlock Origin for Firefox wird weiter angeboten und unterstützt

Vertrieb über den Firefox Add-ons Store eingestellt

  • Der Entwickler von uBlock Origin Lite, Raymond Hill, hat die Unterstützung des Firefox Add-ons Store beendet, nachdem er wiederholt den „nonsensical and hostile“ Review-Prozess des Store-Teams erlebt hatte
  • Anfang September markierte Mozilla alle Versionen von uBlock Origin Lite als Richtlinienverstoß
    • Die Reviewer kamen zu dem Schluss, dass die Erweiterung offenbar Nutzerdaten sammle
    • Außerdem beanstandeten sie, dass sie „minified, concatenated or otherwise machine-generated code“ enthalte
  • Hill erwiderte, dass jeder mit grundlegenden JavaScript-Kenntnissen in wenigen Sekunden erkennen könne, dass diese Vorwürfe keinen Sinn ergäben

Umstellung auf Self-Hosting und Auswirkungen für Nutzer

  • Hill nahm die Erweiterung aus dem Firefox Add-ons Store und wechselte zu einer selbst gehosteten Version
  • Wer uBlock Origin Lite in Firefox weiter nutzen möchte, muss die neueste Version von GitHub herunterladen
    • Diese Version kann sich selbst automatisch aktualisieren
  • Die letzte Nachricht in diesem geschlossenen GitHub-Issue enthält eine E-Mail, in der Mozilla den Fehler einräumt und sich entschuldigt
  • Dennoch bleibt uBlock Origin Lite aus dem Mozilla Add-ons Store entfernt und ist auf addons.mozilla.org nicht mehr zu finden

Kontext zu uBlock Origin und Manifest-Versionen

  • Das bestehende uBlock Origin for Firefox wird weiterhin angeboten und unterstützt
  • Die Lite-Version ist eine Erweiterung auf Basis von Manifest V3 und verursacht eine geringere Last bei Ressourcen wie Prozessor und Arbeitsspeicher
  • Hill hatte nachdrücklich empfohlen, auf uBlock Origin Lite umzusteigen, nachdem Chrome begonnen hatte, uBlock Origin als nicht unterstützte Erweiterung zu kennzeichnen
  • Mozilla plant in naher Zukunft nicht, die Unterstützung für Manifest-V2-basierte Erweiterungen einzustellen, sodass uBlock Origin in Firefox und anderen Browsern mit MV2-Unterstützung weiter bestehen und funktionieren wird

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-02
Hacker-News-Kommentare

  • Ich verwalte beruflich eine mittelgroße Browser-Erweiterung und habe sie auch für Firefox angeboten, habe mich aber im letzten Jahr damit herumgeschlagen, nach einer manuellen Prüfung wieder in den Mozilla-Store zu kommen.
    Ich sitze in den USA, und es scheint in Europa, vielleicht in Rumänien, nur etwa zwei Prüfer zu geben. Die Antwortzeiten sind lang, und es ist extrem frustrierend, dass die Behebung einfacher Fehler jeweils zwei Wochen dauert, etwa wenn Dinge übersehen werden, die bereits vorhanden sind wie „Es wird eine Datenschutzerklärung benötigt“, oder wenn nach Sichtung des Build-Artefakts behauptet wird, es handle sich um „maschinell erzeugten bzw. verschleierten Code“, oder wenn wegen Nichtbeachtung der Anleitung aus dem falschen Verzeichnis heraus gesagt wird, man könne „den Source nicht reproduzieren“

    • Gleiche Situation hier. Ich veröffentliche beruflich eine Erweiterung mit zusammen etwa 1 Million Installationen über Chrome/Firefox/Edge, und gerade das Firefox-Prüfverfahren bei der am wenigsten genutzten Plattform ist völlig dysfunktional.
      Sie verlangen reproduzierbare Builds, können aber nicht einmal die richtige yarn-Version installieren und schaffen es auch nicht, grundlegende Setup-Schritte wie den exakten Installationsbefehl, der mehrfach fett in der README steht, das Installieren der Node-Version oder die Automatisierungsskripte zu befolgen.
      Noch unangenehmer wird es, wenn ein Unternehmen die „verrückte“ Sache macht, private NPM-Module zu verwenden. Selbst wenn man Zugang zu einem vorab eingerichteten Konto oder Berechtigungen für ein Review-Konto anbietet, sagt Mozilla, dass es „schwierig ist, während der Prüfung externe Konten zu verwenden“.
      Schon die Notwendigkeit, mit dem Browser-Review-Team interagieren zu müssen, ist ein wichtiger Grund, warum ich Firefox nicht mehr empfehle. Im besten Fall sind sie inkompetent und versuchen nur, möglichst viel aus den Einnahmen des Google-Suchvertrags herauszupressen, statt ernsthaft einen alternativen und sicheren Browser bereitzustellen
    • „Den Source nicht reproduzieren“ war das größte Problem, und ich musste dem Build ziemlich komplexe Elemente hinzufügen, um die von ihnen verlangte exakte Form von reproduzierbaren Builds zu unterstützen.
      Die Erweiterung ist jedoch so aufgebaut, dass sie wasm-Dateien aus Rust baut, und nach einigem Hin und Her kamen wir zu dem Schluss, dass dieses wasm nicht reproduzierbar sein muss. Obwohl dort der Kern der Erweiterung und 99 % der Logik stecken.
      Ich verstehe nicht, welchen Sinn es hat, wenn das JS reproduzierbar ist, man aber im wasm beliebigen potenziell bösartigen Code verstecken könnte.
      Eine Zeit lang habe ich sogar ernsthaft erwogen, vorgebaute wasm-Dateien in das Source-Paket oder nach npm zu legen, nur um die „reproduzierbaren Builds“ bei AMO zu vereinfachen, aber damit entfernt man sich noch weiter von der tatsächlichen Build-Methode
    • Jedes Mal, wenn ich vom Prüfverfahren für Browser-Erweiterungen höre, schockiert mich, dass ein Mensch die README lesen und den Build-Prozess manuell nachvollziehen muss.
      In manchen Fällen habe ich sogar gehört, dass Prüfer virtuelle Maschinen wiederverwenden oder gar keine verwenden.
      Im Prüfungsformular gibt es ein Eingabefeld zum Einfügen eines Git-Links, und ich hatte erwartet, dass es eine gut dokumentierte automatisierte Pipeline gibt, die eine VM mit vorgegebenem Speicher und Festplattenplatz startet, das Git-Repository klont und dann docker build -t ./docker/review/Dockerfile ausführt.
      Überraschend ist auch, dass die Prüfer solche Werkzeuge nicht schon aus Gründen der Arbeitszufriedenheit massiv innerhalb der Organisation eingefordert haben. Es ist schwer vorstellbar, wie sehr sie von verärgerten App-Besitzern bedrängt werden müssen
    • Ich hatte das gleiche Problem auch mit Erweiterungen bei meinem früheren Arbeitgeber. Der Firefox-Prüfprozess war wirklich ein Albtraum, und die Verzögerungen und Missverständnisse entsprachen genau dem, was oben beschrieben wurde.
      Am Ende reduzierte das Unternehmen die Update-Frequenz der Firefox-Erweiterung, weil die Nutzung gering und das Review zu schmerzhaft war. Als einziger Ingenieur dort, der Firefox nutzte — vielleicht sogar als einziger Mitarbeiter — fand ich das sehr schade
    • Das Problem an solchen Dingen ist, dass Leute, die qualifiziert genug wären, gute Reviews zu machen, meist einen viel interessanteren Job bekommen können, in dem sie etwas bauen statt Code zu prüfen.
      Es ist eine Arbeit, die ein gewisses technisches Niveau erfordert, gleichzeitig aber ziemlich langweilig ist, und diese interessanteren Jobs werden wahrscheinlich auch besser bezahlt

  • Ich arbeite bei Mozilla, bin aber weit von den Add-ons entfernt und weiß daher nicht, welchem Druck dieses Team ausgesetzt ist.
    Trotzdem würde ich, wenn ich das zu verantworten hätte, sagen: Hier geht es gerade um gorhill. Ich würde ihn einfach zu einem Add-on-Reviewer mit vollen Rechten machen, der nur seine eigene Erweiterung prüfen darf.
    Seine Fähigkeiten oder Vertrauenswürdigkeit müssen nicht erst verifiziert werden. Viel mehr historische Daten sprechen für ihn als für irgendeinen Auftragnehmer oder Angestellten.
    Er ist auch kein Einzelfall. Es ist zwar nicht mehr so stark freiwilligengetrieben wie früher, aber viele wichtige Beiträge kommen weiterhin von Freiwilligen, und zumindest im SpiderMonkey-Team gibt es keine Mauer zwischen externen und bezahlten Mitwirkenden.
    Ich sehe keinen Grund, warum gorhill kein offizielles Mitglied des Review-Teams werden sollte. So wie die Lage jetzt ist, würde er das vermutlich nicht sofort annehmen, aber es wäre immer noch sinnvoller, als anderen Personen oder Organisationen irgendwelche Sonderausnahmen zu gewähren.
    Er trägt bereits stark zu den Fähigkeiten und zum Erfolg von Firefox bei, also könnte man ihn auch zum bereits bestehenden und wertvollen Review beitragen lassen. Selbst wenn er nur seine eigenen Reviews macht, wäre das meiner Meinung nach ausreichend.
    Jetzt muss ich wohl herausfinden, wen ich in Slack damit nerven sollte

    • Dem stimme ich nicht zu. Man sollte niemandem erlauben, den eigenen Code selbst zu prüfen. Das untergräbt den Zweck des Reviews.
      Selbst bei Superstars sollte jemand anderes den Code ansehen, damit die Sicherheitspraktiken nicht aufweichen.
      Wenn man solche Privilegien erlaubt, werden andere Superstars an der Grenze der Zulässigkeit dieselben Rechte wollen.
      Auch im wissenschaftlichen Publikationswesen werden selbst Beiträge von Chefredakteuren von anderen begutachtet, und der Entscheidungsprozess findet an Stellen statt, die sie selbst nicht einsehen können. Das ist gut für die Wissenschaft
    • Das klingt eher wie ein Vorschlag, Reputation stärker zu gewichten, anders als beim derzeitigen Review-Prozess, der vollständig technisch sein sollte.
      Das mag eine gute Idee sein, aber Mozilla könnte sich damit neue Beschwerden einhandeln, dass Reputation nicht konsistent bewertet wird.
      https://wiki.mozilla.org/Add-ons/Reviewers/Guide/Reviewing
    • Große Bitte: Könntest du herausfinden, warum sie nicht erlauben, dem FF ein eigenes Root-Zertifikat hinzuzufügen und Add-ons direkt selbst zu signieren?
      Stattdessen muss man ESR/Developer/Nightly-Versionen verwenden und xpinstall.signatures.required auf false setzen, was die Sicherheit stark senkt
    • Er wird sich wahrscheinlich wieder beruhigen. Wenn jemand, der Tausende Stunden hineingesteckt hat, von einer uninformierten Person ausgebremst wird, ist das frustrierend, daher mache ich ihm sein Verhalten überhaupt nicht zum Vorwurf.
      Ich denke, innerhalb einer Woche wird er zurück sein, und unter Firefox ist das wichtig, weil es gegenüber normalem uBlock Origin Akku sparen kann

  • Wenn ich die Zeitleiste richtig verstanden habe, wirkt es so, als hätte gorhill überreagiert. Das sehe ich sogar aus einer Haltung heraus so, die gegenüber fast allem, was Mozilla in den letzten mehr als fünf Jahren getan hat, normalerweise ziemlich scharf kritisch ist
    Für Mozilla ist es praktisch kaum machbar, alle Add-on-Revisionen manuell sicher und rechtzeitig zu prüfen; am Ende mussten sie wohl zwischen Automatisierung und langen Verzögerungen wählen. Bei Automatisierung sind False Positives unvermeidlich
    Was wäre die Alternative? Die Prüfung vor der Veröffentlichung ganz abzuschaffen? Als Nutzer hoffe ich das nicht. Es ist tatsächlich bestätigt, dass aufwendige Supply-Chain-Angriffe in freier Wildbahn stattfinden
    Die Prüfungsrichtlinie schützt auch gorhill selbst. Selbst wenn man ihn dazu nötigen wollte, Spyware einzubauen, sinkt der Reiz, ihn physisch unter Druck zu setzen, ein wenig, wenn es eine Chance gibt, dass das schon vor der Veröffentlichung entdeckt wird

    • Bei einem der populärsten Erweiterungs-Publisher von Firefox ist es vernünftig, ein höheres Niveau an Prüfservice zu erwarten
      Gorhill und andere Top-Entwickler von Erweiterungen liefern Firefox echten Mehrwert und haben über Jahre gutes Verhalten gezeigt
      Das heißt nicht, dass sie beliebig veröffentlichen dürfen, aber wenn ein Prüfer ein bekanntes Plugin ablehnen will, sollte eine zweite Person draufschauen. Dieser Fehler wäre dann natürlich aufgefallen
      Es fühlt sich an wie ein weiterer Fall von „Firefox investiert zu wenig in Developer Relations“. Das ist erstaunlich, wenn man bedenkt, wie stark sie von ihnen abhängen
      Wenn uBlock Origin Lite 8,4 Millionen Nutzer hat, ist schwer zu verstehen, dass gorhill keinen festen Ansprechpartner bei Mozilla hat. Wenn es ein Problem mit der Erweiterung gibt, sollte man ihn auf diesem Niveau telefonisch informieren
    • Dass das Add-on markiert wurde, ist an sich nicht überraschend. Die in den GitHub-Issues verlinkten Dateinamen wirkten alle so, als stünden sie in direktem Zusammenhang mit bekannten Trackern, und genau das blockiert uBOL natürlich
      Es ist gut möglich, dass das von Mozilla verwendete automatische Scan-Tool erkannt hat: „Das ist Google Tag Manager“, und dann die Warnung ausgelöst hat, die normalerweise an Add-ons mit verdächtigen Skripten geschickt wird
      In der E-Mail steht allerdings ausdrücklich, dass „das Mozilla-Add-ons-Team dies manuell geprüft hat“
      Entweder ist das gelogen, oder der manuelle Prüfer hat nicht verstanden, dass die automatisch ausgeführten Tools False Positives erzeugen können
      Automatische Missbrauchserkennung auf einer Plattform wie Mozilla ist völlig in Ordnung, aber man sollte in der Kommunikation nicht lügen. Oder man sollte Leute einstellen, die wissen, was sie tun, wenn es um das Sperren von Add-ons geht
    • Es sollte doch zumindest ein weniger chaotisches Prüfsystem möglich sein
      Selbst bei selbst gehosteten Erweiterungen muss man nach einer abgelehnten Einreichung irgendeine unbestimmte Zeit warten, und wenn Filterregeln in die Erweiterung paketiert werden, ist Zeit wichtig. Nach der Freigabebenachrichtigung muss man die Erweiterungsdatei offenbar erneut manuell herunterladen, umbenennen und dann auf GitHub hochladen sowie update_url manuell auf die neue Version patchen
      Nach Einreichung von 2024.9.12.1004 dauerte es fünf Tage, bis die Genehmigung für Self-Hosting kam, und zum Zeitpunkt des Schreibens war 2024.9.22.986 noch immer nicht freigegeben
      Als Hobby klingt das überhaupt nicht nach Spaß
      https://github.com/uBlockOrigin/uBOL-home/issues/197
    • Ich stimme den Aussagen über die Zielkonflikte des Prüfverfahrens zu, aber ich stimme entschieden nicht zu, dass Raymond Hill überreagiert hat
      Er ist ein unabhängiger Entwickler, der uBlock als Hobby betreibt und nicht einmal Spenden annimmt, also schuldet er uns nichts
      Er hat jedes Recht zu entscheiden, ob das Prüfverfahren reibungslos genug ist, um weiterhin seine Zeit und Energie hineinzustecken, und diesmal hat er einfach entschieden, dass es das nicht ist
      Da er die Erweiterung als Open Source veröffentlicht hat, kann sie jeder an seiner Stelle als uBlock Origin Lite veröffentlichen
    • Es wirkt nicht so, als hätte der Autor überreagiert, und der erste Absatz scheint nicht zur Zeitleiste zu passen. Vielleicht wurde das im Artikel nicht richtig vermittelt, daher ist es besser, sich das GitHub-Issue anzusehen
      https://github.com/uBlockOrigin/uBOL-home/issues/197
      Das war keine automatische Prüfung, sondern eine mangelhafte manuelle Prüfung
      Der Autor erklärt zusätzlich, was alles zum AMO-Prüfverfahren gehört, und sagt, dass er diesen Stress nicht aushalten möchte. Er erwähnt auch, dass eine etwas schädliche Version des Plugins noch online ist
      Nicht mit diesem Stress umgehen zu wollen, ist eine vollkommen nachvollziehbare Reaktion

  • Es ist extrem nervig, dass man die Erweiterung den Torwächtern vorlegen muss, um sie an normale Nutzer zu verteilen.
    Wie gorhill auf GitHub sagte, dauerte selbst die Freigabe der selbstgehosteten Version mehrere Tage, und das ist nicht akzeptabel.
    Man stelle sich vor, man müsste für die Verteilung von Software eine Genehmigung von Microsoft einholen. Nicht einmal Android ist so geschlossen.
    Die erzwungene Signierung und die Entfernung von XUL gehören zu den schlimmsten Dingen, die Mozilla getan hat. Google macht dasselbe und noch Schlimmeres, aber von Google erwartet man so etwas, von Mozilla nicht.

    • XUL musste verschwinden. Die anderen Probleme standen damit eigentlich nicht direkt in Zusammenhang; es war eher ein Fall von „wenn wir sowieso die meisten Erweiterungen kaputtmachen, können wir bei der Gelegenheit auch noch anderes durchdrücken, was wir wollen“. XUL ist eher zum Sündenbock geworden.
      Ich weiß das, weil ich VimFx nach der Entfernung von XUL noch eine Zeit lang gepflegt habe. Es war zwar schwierig, mit den sich ändernden internen APIs Schritt zu halten, aber ich konnte es ihnen nicht verdenken, schließlich mussten sie das Produkt weiterentwickeln.
      Der eigentliche Grund, warum ich die Pflege von VimFx aufgegeben habe, war die erzwungene Signierung. Sie haben die Schrauben immer weiter angezogen, sodass man nicht einmal „meinen eigenen Code“ noch mit einer vernünftigen User Experience ausführen konnte.
      Gewünscht hätte ich mir, dass WebExtensions als empfohlener Weg mit Kompatibilitäts- und Bestandszusagen angeboten wird, dass man sich um die Kompatibilität anderer APIs nicht kümmert und externe Erweiterungen mit „vollem Zugriff“, die interne APIs nutzen, weiterhin erlaubt.
      Im Store hätte man warnen sollen: „Diese Erweiterung verwendet nicht unterstützte APIs, kann daher jederzeit kaputtgehen und kann alle privaten Daten stehlen“, meinetwegen mit knallrotem Installationsbutton — aber erlauben sollte man sie trotzdem.
      Selbst verteilte Erweiterungen mit vom Entwickler verwaltetem Signaturschlüssel und Update-URL hätte man ebenfalls weiter unterstützen sollen.
      Für solche APIs gab es ohnehin keine Kompatibilitätsgarantie, also wäre der Zusatzaufwand wohl gering gewesen: etwas UI-Arbeit für die abschreckenden Warnhinweise und die Pflege des Update-Codes außerhalb des Stores.
    • Bedeutet „man braucht Microsofts Genehmigung, um Software zu verbreiten“ dasselbe wie auf macOS/iOS, wo man ebenfalls eine Erlaubnis für die Softwareverteilung braucht?
      Immer mehr Plattformen entwickeln sich in diese Richtung, und es würde mich nicht wundern, wenn Windows irgendwann ebenfalls so wird.
    • In Firefox kann man Erweiterungen auch ohne den Erweiterungs-Store problemlos installieren. XUL musste weg.
    • In Firefox für Desktop kann man Erweiterungen von überall herunterladen und installieren. Ihre Torwächterrolle betrifft nur ihr eigenes Repository, und die meisten werden das wohl auch so wollen.
      Auf Mobilgeräten scheint man einen Nightly-Build zu brauchen, um Erweiterungen außerhalb des Mozilla-Repositorys zu installieren; das deutet darauf hin, dass ihr Denken vom restlichen mobilen Ökosystem angesteckt wird.

  • Bevor Mozilla zu so einer extremen Maßnahme greift und ein Add-on aus dem Store entfernt, sollten sie bei Fragen oder Bedenken aus der Prüfung zuerst Kontakt aufnehmen.

    • Es wirkt, als würden alle Unternehmen, die Apps, Erweiterungen oder ähnliche nutzergenerierte Inhalte schützen, viel zu schnell überreagieren.
      Wenn man nicht prominent ist, viele Follower hat oder die App bzw. Erweiterung sehr populär ist, kann man kaum erwarten, dass das rechtzeitig geklärt wird.

  • Gorhills vollständiges uBlock Origin könnte fast das einzige verbliebene Verkaufsargument von Firefox sein.
    Für die absurde Summe Geld, die Mozillas Führung in letzter Zeit eingestrichen hat, hätte man stattdessen ein Team mit Spitzenkräften aufstellen können, das sich ausschließlich um alles kümmert, was Mr. Gorhill braucht.

    • Sie sind zu beschäftigt damit, für die Werbefirmen zu arbeiten, die Mr. Gorhill blockiert.
      Zuletzt haben sie die Funktion privacy preserving attribution eingebaut, nach der kein Nutzer gefragt hat.

  • Ich verstehe nicht, warum diese Erweiterung überhaupt auf AMO existiert. Dem Artikel zufolge ist es die „Lite-/Manifest-v3-Version“ — warum sollte man in Firefox statt der Version, die Werbung richtig blockiert, eine schlechtere Variante für ältere Browser installieren?

    • Einer der wenigen guten Gründe, warum Google das Add-on-Manifest eingeschränkt hat, sind Leistung und Sicherheit.
      Deklarative Domainlisten lassen sich leicht cachen und reduzieren unnötige Aktivierungen von Erweiterungen. Mit weniger Berechtigungen ist auch der Schaden viel geringer, falls später einmal eine mit Malware infizierte Version in den Store gelangt.
      Die Regel-Engine von uBlock ist so mächtig, dass benutzerdefinierte Regelsätze auf praktisch jeder Website Code einschleusen können. Das gilt nicht nur für benutzerdefinierte Regeln, sondern auch für eingebaute Regeln, deren Konto oder Hosting kompromittiert oder später verkauft werden könnte.
      Das heißt natürlich nicht, dass ich die Lite-Version benutzen würde oder dass ich Googles Entscheidung gutheiße. Sie haben ja keine alternative API angeboten und die Werbeblocker-API abgewürgt.
      Da der Code ohnehin öffentlich ist und es Leute gibt, die weiter Google Chrome benutzen, kann man diese Version auch in Firefox anbieten.
    • Der Stromverbrauch ist geringer, und auf Firefox für Android ist das wichtig.
    • Anders als UBO kann es mit deutlich weniger Berechtigungen laufen.
    • Es ist schneller und hat weniger sicherheitsrelevante Implikationen. Ich bestreite nicht, dass UBO leistungsfähiger ist, aber aus Sicherheitssicht hat es einen etwas weniger sicheren Footprint, und andere entscheiden sich vielleicht lieber für die höhere Sicherheit von V3.
    • Es ist mein Computer. Ich habe ihn bezahlt und ich verwalte ihn. Ich werde damit machen, was ich will.
      Die bessere Frage ist: Warum sollte ich Firefox benutzen, wenn Firefox verweigert, was ich will?

  • Das wirkt ziemlich hart. Mozilla hat einen Fehler gemacht, sich entschuldigt, den Fehler behoben und vielleicht sogar den Prozess verbessert, aber der Autor nimmt die Erweiterung trotzdem herunter und kritisiert Mozilla.
    Meiner Meinung nach hat der Autor das entweder zu persönlich genommen oder wollte mit einer starken Botschaft Verbesserungen im Prüfprozess erzwingen. Dabei hat die Sichtbarkeit des Projekts etwas gelitten.

    • Man sollte sich daran erinnern, warum uBlock Origin überhaupt entstanden ist. Raymond Hill war die ganze Verwaltungsarbeit rund um uBlock leid, und aus einem Hobby begann sich Arbeit zu entwickeln.
      https://github.com/gorhill/uBlock/issues/38#issuecomment-918...
      Dass er nun auch vom Mozilla-Prüfprozess genug hat und aufhören will, ist daher vorhersehbar.
      Damals übergab er das Projekt an irgendeine beliebige, gewissenlose Person, die es sofort monetarisieren wollte; Raymond gefiel das Ergebnis nicht, sodass er sein eigenes früheres Projekt kritisieren musste und am Ende nach viel zusätzlicher Arbeit fast wieder am Ausgangspunkt landete.
    • Der Autor ist Freiwilliger, und diese Software ist ein aus Leidenschaft geschaffenes Werk — natürlich ist das persönlich.
      Solche Projekte funktionieren gut, wenn der Autor das Gefühl hat, der Community ein wertvolles Geschenk zu machen, und dass die Community es annimmt und wertschätzt.
      Wenn man sein eigenes Werk einem gefühllosen „Prüfprozess“ unterwerfen muss und es auf eine Weise abgelehnt wird, bei der offensichtlich niemand richtig hingeschaut hat, dann ist das nicht bloß demotivierend, sondern eine Beleidigung.
      Ich wäre auch gegangen.
    • Mozilla hat lediglich eine E-Mail mit Textbausteinen verschickt, und hier wird so getan, als hätten sie mehr getan als das.
      Sie haben dem Autor nicht einmal garantiert, dass das Add-on nicht erneut entfernt wird, ohne vorherige wechselseitige Kommunikation.
      Mozilla hat eine Pressemitteilungsseite, also hätten sie öffentlich klar darlegen können, was schiefgelaufen ist und was sie künftig ändern werden. Sie hätten auch anerkennen können, dass diese Erweiterung hervorragend ist, und finanziell dazu beitragen können, dass sie den Nutzern weiter zur Verfügung steht.
      Stattdessen haben sie nach einem groben Fehler des Prüfers nur das absolut Notwendige getan, um das Gesicht zu wahren. Die Begründungen aus der ersten Prüfung waren offensichtlich falsch, auf einem Niveau, das selbst ein JS-Anfänger erkennen würde.
      Sogar ein KI-Prüfer hätte es besser gemacht. ChatGPT 4o mini kam zu dem Schluss, dass diese Datei nicht wie obfuskierter Code aussieht, keine komprimierte Form mit entfernten Leerzeichen, Zeilenumbrüchen und Kommentaren ist und aufgrund von Kommentaren, Einrückungen und strukturierten Funktionen nicht die Merkmale obfuskierter Codes aufweist.
    • „Der Autor hat das zu persönlich genommen“ — ja, wirklich unerquicklich, wenn lästige unbezahlte Entwickler Gefühle in ihre persönlichen Projekte hineintragen.
      Warum können sie nicht so kühl und gefühllos sein wie die Leute, die den Firefox-„Store“ betreiben?
    • Man kann gorhill kaum vorwerfen, dass er das Spiel „reichen Großorganisationen unbegrenzt zweite Chancen geben“ nicht mitspielen will.
      Selbst wenn man meint, man hätte an seiner Stelle anders gehandelt, ist irgendwann einfach genug.
      Und Mozilla hat sich nicht entschuldigt. Ich will hier nicht die Entschuldigungspolizei spielen, aber das war nur ein formelhafter Kundensupportsatz mit dem Wort „apologize“ darin.
      Das reicht, und niemand erwartet mehr, aber man kann es trotzdem als das benennen, was es ist.

  • Eine berechtigte Reaktion. uBO ist eine Killer-Erweiterung, und Mozilla scheint nicht auf den Gedanken gekommen zu sein, dass man, wenn man schon auf einem schrecklichen maschinengetriebenen Erweiterungs-Prüfprozess nach Google-Art besteht, zumindest für eine der wichtigsten existierenden Erweiterungen eine Ausnahme machen sollte.
    Selbst wenn Mozilla „seinen Fehler erkannt“ hat, ist es nachvollziehbar, dass gorhill über die ganze Sache völlig verärgert ist und die Zusammenarbeit verweigert.
    Ihr Fehler bestand darin anzunehmen, dass er wie viele Erweiterungs- und Open-Source-Entwickler die Bürokratie für wenig Dank und immer mehr Forderungen schon irgendwie ertragen werde.
    Das Ergebnis ist alles andere als ideal, aber leider liegt die Verantwortung vollständig bei Mozilla.

    • Es geht hier um uBOL. Bei der Haupt-Erweiterung habe ich keine nennenswerten Verzögerungen gesehen.
      Die Haupt-Erweiterung ist in Firefox ohnehin immer aktueller als in Chrome/Edge.
    • Wenn ich höre, dass uBO eine Killer-Erweiterung ist, frage ich mich, ob Googles Endziel darin besteht, Mozilla auf der Gehaltsliste zu halten, den Anreiz für Produktinnovation zu senken und dann Firefox-Nutzer langsam abwandern zu lassen, bis es niemand mehr verwendet und Chromes Position zementiert ist.
      So würde man mit Werbeblockern umgehen. Da Google Chromium bereits umfassend kontrolliert, bleibt als echte Alternative nur Safari, das sich viel schwerer angreifen lässt.
      Google kann Werbeblocker-Erweiterungen in Firefox nicht stoppen, aber es kann Mozilla dazu drängen, Firefox faktisch wie vernachlässigte Software zu betreiben, bis es stirbt.
      Es ist beschämend, wie gründlich die Mozilla Foundation ihre eigene Position ruiniert hat, und es fällt schwer, dieses Verhalten bloß auf Inkompetenz zu schieben.
    • uBlock Origin ist wahrscheinlich der Hauptgrund dafür, dass Firefox heute überhaupt noch irgendeinen nennenswerten Browser-Marktanteil hat.
      Wenn Firefox das nicht unterstützt hätte, würde ich einen anderen Browser benutzen. Wenn Mozilla immer weniger richtig macht, sollte man gorhill ausgesprochen gut behandeln.

  • Ich hoffe wirklich, dass Raymond Hill bei uBlock Origin, also der Manifest-v2-Version, nicht denselben Schritt macht.
    Anderen Leuten die Installation von selbstgehosteten Erweiterungen zu empfehlen, ist nicht gerade angenehm.
    Es ist schade, dass Mozilla und Raymond Hill dieses Problem nicht gemeinsam lösen können oder wollen. Ich verstehe, dass eine solche Erweiterung nicht durch so eine Prüfung hätte gehen sollen, und ich verstehe auch, dass er sich nicht mehr damit befassen will, aber ich mache mir Sorgen, welche Auswirkungen diese Situation auf die langfristige Stabilität des uBlock-Origin-Projekts haben wird.
    Die ganze Lage wirkt eindeutig nicht gesund.
    https://github.com/uBlockOrigin/uBOL-home/issues/197#issueco...

    • UBO hat über alle Browser hinweg womöglich mehr Nutzer als Firefox insgesamt, oder wäre zumindest nicht weit davon entfernt, vielleicht nur im einstelligen Vielfachen darüber.
      Anzudeuten, das Projekt sei gefährdet, nur weil sich eine unbedeutende Plattform stur stellt, ist absurd.
    • Dem neuesten Update im Link zufolge hat das Mozilla-Prüfteam den Fehler anerkannt und korrigiert. Hoffentlich kann es weiterbestehen.
    • uBlock Origin 1.60 hängt immer noch in der Mozilla-Prüfung fest.
      Obwohl die Veröffentlichung schon etwa eine Woche her ist, ist auf der Firefox-Add-ons-Seite weiterhin 1.59 die neueste verfügbare Version.