Mozilla kündigt standardmäßige Blockierung aller Plugins und temporäres Plugin-Whitelisting an
Mozilla setzt sich für ein pluginfreies Web ein und geht dabei den nächsten Schritt: In Zukunft sollen alle Plugins standardmäßig blockiert werden. Pluginentwickler können die temporäre Aufnahme in eine Whitelist beantragen, sofern sie einen glaubhaften Plan für die Migration weg von NPAPI-basierenden Plugins beschreiben.
Wenn es nach Mozilla geht, dann sind die Tage von Browserplugins gezählt. Plugins können signifikante Auswirkungen auf die Performance, Stabilität und vor allem die Sicherheit haben. Aus diesem Grund sind die meisten Plugins in Firefox standardmäßig auf Click-to-Play geschaltet, was so viel bedeutet, dass die Plugins zunächst deaktiviert sind und bei Bedarf vom Nutzer für die jeweilige Webseite aktiviert werden können. Darum wird Firefox seit Version 19 auch mit einem von Mozilla entwickelten PDF-Betrachter ausgestattet, welcher nur auf Webtechnologien basiert und kein Plugin benötigt, und darum hat Mozilla selbiges mit Shumway auch für Flash-Inhalte vor.
Nun geht Mozilla noch einen Schritt weiter: Bald schon sollen wirklich alle Plugins standardmäßig blockiert werden. Um den Übergang zu erleichtern können Plugins die Aufnahme in eine Whitelist beantragen. Die Frist hierfür endet bereits am 31. März 2014. Sofern Mozilla dem Antrag zustimmt, wird das jeweilige Plugin für eine Beta- und vier Release-Versionen, was einem Zeitraum von 30 Wochen entspricht, auf eine Whitelist gesetzt und in dieser Zeit nicht blockiert. Nach Ablauf der 30 Wochen kann eine erneute Aufnahme beantragt werden. Die Aufnahme in die Whitelist kann aber jederzeit widerrufen werden, wenn Mozilla der Meinung ist, dass dies das Beste für die Nutzer sei.
Allerdings ist die Aufnahme in die Whitelist an eine nicht unerhebliche Bedingung geknüpft. So müssen die Pluginhersteller hierfür einen glaubhaften Plan beschreiben, wie sie weg von NPAPI-basierenden Plugins zu einer auf Webstandards basierenden Lösung migrieren möchten. Anders gesagt: Den Vorzug noch etwas länger nicht blockiert zu werden erhalten nur Plugins, welche sowieso ersetzt werden sollen. NPAPI steht für Netscape Plugin Application Programming Interface und bezeichnet die damals von Netscape entwickelte und erstmals mit dem Netscape Navigator 2.0 im Jahr 1995 eingeführte Plugin-Schnittstelle, welche unter anderen Firefox, Safari, Chrome und Opera verwenden. Außerdem sind die Pluginhersteller genehmigter Plugins für QA-Tests auf dem Beta-Kanal von Firefox zuständig. Auch wird Mozilla unabhängig von der Whitelist weiterhin Plugins blockieren, sofern sie Sicherheitslücken aufweisen.
Google hatte im September 2013 angekündigt, NPAPI ab 2014 nicht mehr unterstützen zu wollen, auch hier findet ein schrittweiser Rückgang mit Whitelist statt. Ende 2014 möchte Google die NPAPI-Unterstützung dann komplett eingestellt haben. Flash ist im Falle von Chrome allerdings nicht betroffen, da das mit Chrome gebündelte Flash Googles PPAPI-Schnittstelle nutzt. Adobe selbst bietet neue Flash-Versionen für Linux nur noch für PPAPI an, versorgt aber zumindest die NPAPI-Version noch einige Zeit mit Sicherheitsupdates. An einer Unterstützung von PPAPI ist Mozilla nicht interessiert.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, mozilla.de, firefoxosdevices.org sowie sozone.de.
„Nun geht Mozilla noch einen Schritt weiter: Bald schon sollen wirklich alle Plugins standardmäßig blockiert werden.“ (Zitatfunktion ist fehlerhaft, weil sie automatisch den nächsten Absatz ebenfalls als Zitat kennezeichnet.)
Dieser Standard ist für mich schon ein wenig verwirrend, weil ich jedes Plugin aktivieren würde, das für eine bestimmte Aktion angefordert wird. Oder ist das eine vorsorgliche Maßnahme, die verhindern soll, dass Lücken in aktivierten Plugins ausgenutzt werden?
Wird ein aktiviertes Plugin nach dem Schließen des entsprechenden Programms bzw. Runterfahren des Rechners automatisch wieder deaktiviert?
Wenn ein Plugin angefordert wird, gibt es dann zugleich einen Hinweis, wenn das entsprechende Plugin ein Update erfordert?
Den PDF-Betrachter habe ich seinerzeit getestet, habe aber wieder aus nicht mehr nachvollziehbaren Gründen davon wieder Abstand genommen und nutze weiterhin den PDF-XChange Viewer.
Ok, es sollen Plugins blockiert werden, und nicht die Erweiterungen. Der erste Schreck lässt nach.
Aber: Wie soll die Lösung für Flash aussehen, wenn Mozilla die PPAPI nicht unterstützen will? Welcher Zeitraum ist insgesamt für den Rausschmiss der Plugins angedacht?
Jaaawohl! Nieder mit den Plugins!
Aber damit es soweit kommt, muss die DRM-Funtion endlich Teil von HTML5 werden sonst wirds nix und wir müssen uns weiterhin mit Silverlight herumschlagen.
Schön, dass das von Mozilla so ausführlich begründet wurde…
Das wird sich von alleine erledigen, die Encrypted Media Extensions (seufz… ich mag DRM nicht) sind mittlerweile auf dem Weg und Silverlight 5.1 ist bereits die letzte Version Da gibts nur noch bis 2021 Hotfixes, die aktive Weiterentwicklung wurde aber eingestellt.
Den Schritt von Mozilla begrüße ich sehr. Ich würde mir aber wünschen, dass die endgültige Blockierung aller Plugins möglichst verträglich im Zusammenspiel mit der Einführung von Shumway verläuft. Außerdem hoffe ich nicht, dass das Whitelisting anderen Plugins wie Java zu viel Luft gibt und man zumindest dann immer noch so restriktiv handelt wie mit Flash und dort nur die jeweils aktuellste Version frei hält. Das wären zwei wichtige Bedingungen, damit das auch für den Endnutzer möglichst angenehm und wenig riskant wird. Und wenn Shumway dann kommt, ist der erste Weg für mich… na…. richtig: Systemsteuerung –> Programme deinstallieren –> Adobe Flash Plugin deinstallieren. 😉
@Gerhard Hallstein:
Es geht um drei Aspekte, Sicherheit ist einer davon. Die anderen beiden sind Performance und Stabilität. Plugins sind für einen Großteil der Abstürze verantwortlich, Firefox selbst ist eigentlich ziemlich stabil.
Plugins werden deaktiviert, wenn sie nicht mehr benötigt werden, ich meine drei Minuten, nachdem keine Seite mehr offen ist, welche ein Plugin benötigt, kann aber auch eine andere Zahl sein. In dieser Größenordnung war es was.
Nein, das ist nach wie vor Aufgabe des Plugins über notwendige Updates zu benachrichtigen, darauf hat Mozilla keinen Einfluss.
@Wolfgang D.:
Flash kann ja optional weiterhin aktiviert werden. Ansonsten arbeitet Mozilla mit Shumway an einem Ersatz für den Flash-Player, welcher rein auf Webtechnologien setzt, ähnlich pdf.js für PDF-Dateien.
Zeitraum: Am 31. März läuft die Frist für den Antrag auf Whitelisting ab, kurz danach werden dann die Plugins blockiert, dann sind es 30 Wochen bis erneut Whitelistung beantragt werden kann. Wie lange das weitergeht, wird man sehen.
@Patrick Albrecht:
Ob DRM der richtige Ansatz ist, darüber lässt sich streiten. Mozilla positioniert sich ganz klar gegen DRM und DRM ist auch bereits in der Musikindustrie ganz kläglich gescheitert. Man wird sich natürlich zwangsläufig dem beugen müssen, wenn alle anderen Browserhersteller bei DRM dabei sind…
@Anon:
Mozilla möchte komplett von Plugins wegkommen, da ergibt es für Mozilla keinen Sinn, Ressourcen in eine andere Plugin-Schnittstelle zu investieren.
@Antares:
Ich denke nicht, dass Mozilla den Sicherheits-Standard reduzieren wird, Java ist ja bereits vollkommen unabhängig von der Version standardmäßig auf Click-to-Play geschaltet, weil es Mozilla gereicht hat mit den permanenten Sicherheits-Problemen…
Ich denke, dass Shumway sein Debüt in Windows 8 Modern UI feiern wird, denn dort ist das die einzige Möglichkeit für die Wiedergabe von Flash-Inhalten, NPAPI-Plugins sind dort nicht möglich. Dann ist die Modern UI-Version von Firefox sogar tatsächlich für etwas gut – als Testbereich für Shumway. 😉
Vorausgesetzt, Shumway funktioniert zuverlässig – und das bezweifle ich (zumindest im Moment noch). Flash ist über die Jahre extrem gewachsen, sodass es keine leichte Aufgabe ist, alle Features zu implementieren. Shumway wird also wohl nur die üblichsten Funktionen anbieten und das reicht oft eben nicht.
Naja, sagen wir mal so, es muss reichen: Flash Player auf Linux ist auf alte Versionen beschränkt, dort gibt es keine weiteren Feature-Updates mehr, Flash Player auf Android ist Geschichte, Flash Player auf iOS gab es nie, Flash Player auf Windows 8 Modern UI gab es ebenfalls nie (abgesehen für ein paar Seiten auf einer Whitelist im Internet Explorer). Shumway wird also automatisch für immer mehr Plattformen interessant, das erledigt die Zeit, die vergeht. Ansonsten denke ich aber ehrlich gesagt auch gar nicht, dass – wenn Shumway denn gut läuft – es oft nicht reichen wird beziehungsweise, dass Shumway unbedingt jedes Feature des Flash Players unterstützen muss. Ein gewisses Basis-Set, welches dafür hervorragend funktioniert, sollte schon den Großteil des Bedarfs abdecken. Das wäre vielleicht auch wieder irgendwo eine Ressourcen-Verschwendung, denn das Flash nicht die Technologie der Zukunft ist, das ist ja schon ganz lange bekannt. Shumway sollte da gut funktionieren, wo Webtechnologien (noch) nicht funktionieren. Da fällt mir Streaming ein. Aber wenn ich zum Beispiel an Spiele denke, das ist ganz klar mit Webtechnologien umsetzbar, da muss man also vielleicht nicht die allerspeziellsten Flash-Features für unterstützen. Aber das ist nur meine Meinung.
Ich möchte noch einmal den integrierten PDF-Betrachter testen. Wo stelle ich das ein?
Unter Einstellungen → Anwendungen nach PDF suchen und dort Vorschau in Firefox auswählen.
Kann ich bei dieser Einstellung den PDF-XChange Viewer auf meinem Rechner belassen?
Ja, aber das entsprechende Browserplugin sollte über den Add-on Manager deaktiviert werden, denn es sollten immer nur die Plugins aktiviert sein, die man auch benötigt.
Der PDF-Change Viewer ist kein Browserplugin, sondern ein externes Programm. Aus diesem Grunde habe ich den Viewer in meinem Kommentar von 00:05 Uhr informationshalber verlinkt.
Der PDF Viewer stellt aber eigentlich immer auch ein zugehöriges Plugin bereit, macht der PDF XChange Editor, sein Nachfolger, ja auch, genau wie der Adobe Reader. 😉 Gibt aber Ausnahmen. Ich verwende selber momentan den Brava Reader, der macht das nicht. Im Firefox-Browser nutze ich pdf.js.
https://bugzilla.mozilla.org/show_bug.cgi?id=729481#c10
https://bugzilla.mozilla.org/show_bug.cgi?id=729481#c32
https://bugzilla.mozilla.org/show_bug.cgi?id=729481#c40
@Gerhard: Dann bedarf es auch keiner weiteren Aktion außer eben der einen Einstellung im Einstellungsdialog. 😉
Danke fürs Finden der entscheidenden Kommentare, XtC4UaLL!
Aus meiner Erfahrung kann ich berichten: Er ist ne gute Idee, aber leider Mist (freundlich: nicht brauchbar). Es ist vielleicht unfair einen vollwertigen Ersatz für richtige PDF-Plugins von Adobe (relativ lahm), Foxit oder auch XChange zu ewarten, deswegen verzeihe ich ihm die häufigen Anzeigefehler (auf die zum Glück ja auch hingewiesen wird) noch. Aber bei jedem Dokument was größer als nen MiB ist oder ein paar mehr Seiten hat wird PDF.js lahm, die Suche funktioniert nicht (weil Seiten erst geladen werden wenn man sie überscrollt) und mit ziemlich hoher Wahrscheinlichkeit stürzt Firefox irgendwann ab. Dies passiert mit Firefox unter Win7, Firefox Beta unter Win8.1 und nem etwas älteren Firefox unter Ubuntu (auf drei verschiedenen Rechnern). Dies widerspricht dann zumindest etwas dem folgenden, auch wenn PDF.js nur ein Teilaspekt ist.
Eigentlich glaube ich das auch, Abstürze sind gefühlt ähnlich häufig wie die einzelner Tabs bei Chrome, nur dass es bei Firefox halt noch den ganzen Browser mitreißt…
Danke für die Erläuterung. Aber warum das? Du nennst ja oben durchaus drei Aspekte, aber das liegt ja eher an einer schlechten Implementierung (Probleme die PPAPI ja versucht zu beheben) als an der Idee von Plugins selbst. Also die Frage: Warum werden Plugins per se nicht mehr als Möglichkeit gesehen den Browser mit erweiterten Features auszustatten – zumindest solange sie nicht Konkurrenz mit etablierten Webtechnologien stehen? Flash oder VLC-Plugin für Streaming, ein PDF-Viewer wären Beispiele wo Webtechnologie es einfach (noch?) nicht schafft vergleichbare Ergebnisse zu liefern.
Ich weiß nicht, was für PDFs du betrachtest, aber ich betrachte relativ häufig PDFs und die können mit dem integrierten PDF-Betrachter von Mozilla alle ohne Anzeigeprobleme dargestellt werden. Ich hatte noch keine PDF, mit welcher der PDF-Betrachter Probleme hatte. Außer wenn ich auf Bugzilla mal eine verlinkte PDF-Datei betrachtet hatte, wo es darum ging, dass diese nicht richtig dargestellt wird, aber noch nie bei einer PDF-Datei, die ich ernsthaft betrachten wollte. Manchmal kommt eine Hinweisleiste, dass es Anzeigeprobleme geben könnte, gibt es in diesen PDFs aber nicht, die Anzeige kommt viel häufiger als sie müsste. Nur ist es halt nicht feststellbar, ob es tatsächlich Anzeigeprobleme gibt oder nicht. Man kann nur erkennen, ob bestimmte Muster in einer PDF-Datei vorkommen, wo bekannt ist, dass Abweichungen möglich wären. Ein Computer ist eben kein Mensch.
Nö. Hier sind die Seiten sofort sichtbar, wenn ich zur Seite scrolle. Auch die Suchfunktion funktioniert in der PDF-Datei, in der ich das gerade vor fünf Minuten getestet habe.
Das ist mir in all den Monaten nicht ein einziges Mal passiert, nicht einmal bevor das Feature offiziell ausgeliefert worden ist. Und ich nutze sogar eine Nightly-Version, die tendenziell anfälliger für Abstürze sein müsste.
Plugins haben einfach überhaupt nichts mit Webstandards zu tun, alleine das ist schon Grund genug zu versuchen von Plugins wegzukommen. Und Nutzer sollten das Web nutzen können ohne sich Plugins dafür installieren zu müssen, das widerspricht vollkommen der Idee eines offenen Webs. Dazu kommt, dass Mozilla nur wenig Einfluss auf die Plugins nehmen kann. Deren Instabilitäten und Sicherheitslücken sind ein ernsthaftes Problem. Und Sicherheitslücken in Plugins sind gefährlicher als Sicherheitslücken in der Web-Plattform, zumal Sicherheitslücken in der Web-Plattform sowieso von Mozilla behoben werden und wenn eine davon z.B. den PDF-Betrachter betrifft, dann wird die Sicherheitslücke der Web-Plattform quasi automatisch für den PDF-Betrachter mit behoben. Aber ein ganz entscheidender Punkt, den ich nicht genannt hatte, aber in dem oben verlinkten Bug genannt wird: Pepper ist ein Teil von Googles Bestrebungen, einen Teil der Web-Plattform durch seine native Technologie zu ersetzen, was in ganz klarem Widerspruch zu Mozillas Idealen steht.
Ich hab eine E-Mail an Chad Weiner, Director of Product Management von Mozilla, geschrieben, um mir ein klares Statement bezüglich Flash abzuholen, und nun eine Antwort erhalten. Mit Flash wird man es weiter so handhaben, dass die jeweils aktuellste Version eine Ausnahme darstellt und standardmäßig nicht blockiert wird, da Flash einfach noch viel zu verbreitet ist.
Hallo Sören,
wenn ich diese Einstellung wähle, wird beim Aufruf einer PDF-Datei nach wie vor der PDF-XChange Viewer genutzt. Allerdings kann ich die anderen PDF-Einstellungen nicht entsprechend ändern ==> http://www.pic-upload.de/view-22433906/pdf.png.html
Gut´s Nächtle
Gerhard
Überprüfe mal über about:config den Schalter pdfjs.disabled, steht dieser auf false?
(Ich weiß es wird gerade etwas Off-Topic und dies ist kein Bugtracker…)
Bei mir tritt es gerade ganz konkret bei diesem Dokument auf: Manchmal (also nicht bei jedem Neuladen) wird angezeigt, dass das Dokument nicht richtig angezeigt werde. Eine Suche z.B. nach UNTOC von der Startseite aus liefert erst Ergebnisse wenn ich einmal runtergescrollt und kurz gewartet habe bis die typische Ajax-Loader-Grafik verschwunden ist.
Hallo,
wir setzen Firefox in der ESR-Version ein, um Webanwendungen in einem geschützten Netzbereich zu betreiben. In diesem Zusammenhang sind Plugins im Einsatz, die nicht auf der Whitelist von Mozilla stehen werden. Entweder, weil sie wegen Inkompatibilität oder noch nicht abgeschlossener Tests nicht in der neusten Version eingesetzt werden oder weil keine Ablösung mit Standard-Webtechnologien geplant ist.
Besteht die Möglichkeit, das Blockieren von Plugins zu steuern? Beispielsweise durch die Freigabe aller Plugins für definierte Domains oder eine zusätzliche Whitelist, die im eigenen Netz abgelegt wird.
Andernfalls ist Firefox im Enterprise Bereich nicht mehr einsetzbar, da wir nicht von jedem Mitarbeiter verlangen könnnen, dass er entscheidet, welches Plugin er aktivieren darf.
Viele Grüße,
Jens
Jens Almann: So wie ich das interpretiere ja, da Plugins ja weiterhin für einzelne Seiten aktiviert werden können. Langfristig muss man sich aber als Firma (und überhaupt) darauf einstellen, dass die Plugin-Schnittstelle ganz verschwindet (wohl aber erst, wenn auch Flash obsolet geworden ist).
Ich habe jetzt diese Einstellungen vorgenommen. In den vier Zeilen über der letzten ist die Einstellung „Vorschau in Firefox“ nicht vorgesehen. Nunmehr werden pdf-Dokumente teilweise mit pdfj.js geöffnet und teilweise mit PDF-XChange Viewer.
Bei den mit pdf.js geöffneten Dokumenten reicht der Inhalt sehr weit an den rechten Rand. Wie kann ich die Inhalte dauerhaft auf mittig setzen? Ich habe keine entsprechende Einstellung gefunden.
In about:config ist pdfjs.disabled auf false gesetzt.
Manche Webseiten erzwingen den Download von PDF-Dateien und damit das Öffnen nicht direkt auf der Webseite, das ist dann einfach so. Man könnte die heruntergeladene Datei dann natürlich wieder mit Firefox öffnen, das ginge. Nur wird sich wahrscheinlich vollkommen automatisch dein PDF-Programm öffnen, denn in deinem Screenshot sind ja Einträge zu sehen, wo etwas wie force-download in Klammern steht. Das ist eine Methode um genau dieses Verhalten zu erreichen. Und das ist offensichtlich fix mit Firefox verknüpft. Wenn sich das in Firefox nicht ändern lässt, dann gibt es vielleicht im PDF-Programm eine Einstellung dafür, das weiß ich nicht. Aber selbst wenn diese Verlnüpfung aufgehoben wird, dann wirst du gefragt werden, ob du die PDF-Dateien herunterladen / mit einem anderen Programm öffnen möchtest, die Dateien, auf die diese Einstellung zutrifft, werden nicht direkt in Firefox geöffnet.
Würde mich ja freuen, wenn FF zuließe, endlich die dämlichen Plugins aus der Liste löschen zu können, statt, dass ich ab und zu in die Registry nach \mozillaplugins\ gehen muss um wieder angesammelten Müll zu löschen. (Gut, besser wäre es, wenn nicht MS/Google/EA/… versuchen würden ihren Dreck in den FF reinzuhängen.)
Das dürfte technisch nicht ganz so einfach sein, da die Plugins ja nicht in Firefox installiert werden, sondern auf dem System installiert sind und von Firefox dann nur erkannt werden. Dass sich Plugins auf Windows in die Registry eintragen können, ist tatsächlich nicht so schön. Auf OS OX gibt es einen auf dem System vorgegebenen Ordner, Plugins müssen eine Datei in genau diesen Ordner ablegen, das ist die einzige Möglichkeit. Das erlaubt zwar auch auf OS X keine Deinstallation von Plugins, macht das Ganze aber zumindest überschaubar.
Mir sind Kommentare entgangen…
@Anon:
Kann ich nicht bestätigen, klappt hier einwandfrei.
@Jens Almann:
Wie Anon sagte, es geht hier um eine Standard-Einstellung und man kann die Plugins weiterhin nutzen. Google wird die NPAPI-Schnittstelle aber Ende des Jahres in Chrome komplett ausknipsen.
Vielleicht betreibt Firefox bei pdf.js so ein Ressourcenmanagement, dass er bei weniger Arbeitsspeicher nicht das ganze Dokument lädt? Irgendwodran muss es ja liegen, dass es bei mir unter mehreren Systemen auftritt. Jetzt gerade das gleiche Problem mit dem gleichen Dokument mit Australis unter Windows 7 mit eher unzeitgemäßen 3 GB RAM…
Da in meinem Computer 16 GB Arbeitsspeicher verbaut sind, kann ich nichts zu wenig Arbeitsspeicher sagen. 😛
In Firefox 29 gibt es allerdings größere Verbesserungen bezüglich Speicherverbrauch von pdf.js.