32 Reaktionen

Mozilla kündigt standardmäßige Blockierung aller Plugins und temporäres Plugin-Whitelisting an

Geschätzte Lesedauer:

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.

Unabhängige Berichterstattung unterstützen.

Unterstütze wirklich unabhängige und Fakten-basierte Berichterstattung zu Mozilla, welche nicht das Ziel hat, Schlagzeilen zu produzieren, sondern objektiv zu informieren.

Dieser Artikel wurde von Sören Hentzschel verfasst.

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, firefoxosdevices.org sowie sozone.de.

32 Kommentare - bis jetzt!

Eigenen Kommentar verfassen
  1. schrieb am :

    „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.

  2. Wolfgang D.
    schrieb am :

    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?

  3. Patrick Albrecht
    schrieb am :

    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.

  4. Anon
    schrieb am :

    An einer Unterstützung von PPAPI ist Mozilla nicht interessiert.

    Schön, dass das von Mozilla so ausführlich begründet wurde…

  5. Antares
    schrieb am :

    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.

    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. 😉

  6. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Gerhard Hallstein:

    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?

    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.

    Wird ein aktiviertes Plugin nach dem Schließen des entsprechenden Programms bzw. Runterfahren des Rechners automatisch wieder deaktiviert?

    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.

    Wenn ein Plugin angefordert wird, gibt es dann zugleich einen Hinweis, wenn das entsprechende Plugin ein Update erfordert?

    Nein, das ist nach wie vor Aufgabe des Plugins über notwendige Updates zu benachrichtigen, darauf hat Mozilla keinen Einfluss.

    @Wolfgang D.:

    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?

    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:

    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.

    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:

    Schön, dass das von Mozilla so ausführlich begründet wurde…

    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 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.

    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…

    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. ;)

    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. 😉

  7. schrieb am :

    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.

  8. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

  9. schrieb am :

    Ich möchte noch einmal den integrierten PDF-Betrachter testen. Wo stelle ich das ein?

  10. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Unter Einstellungen → Anwendungen nach PDF suchen und dort Vorschau in Firefox auswählen.

  11. schrieb am :

    Kann ich bei dieser Einstellung den PDF-XChange Viewer auf meinem Rechner belassen?

  12. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

  13. schrieb am :

    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.

  14. Antares
    schrieb am :

    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.

  15. XtC4UaLL
    schrieb am :

    An einer Unterstützung von PPAPI ist Mozilla nicht interessiert.

    Schön, dass das von Mozilla so ausführlich begründet wurde…

    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

  16. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Gerhard: Dann bedarf es auch keiner weiteren Aktion außer eben der einen Einstellung im Einstellungsdialog. 😉

  17. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Danke fürs Finden der entscheidenden Kommentare, XtC4UaLL!

  18. Anon
    schrieb am :

    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

    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.

    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.

    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…

    Mozilla möchte komplett von Plugins wegkommen, da ergibt es für Mozilla keinen Sinn, Ressourcen in eine andere Plugin-Schnittstelle zu investieren.

    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. 

     

     

  19. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

    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.

    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)

    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.

    und mit ziemlich hoher Wahrscheinlichkeit stürzt Firefox irgendwann ab.

    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.

    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. 

    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.

  20. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

  21. schrieb am :

    Hallo Sören,

    Unter Einstellungen → Anwendungen nach PDF suchen und dort Vorschau in Firefox auswählen.

    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

  22. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Überprüfe mal über about:config den Schalter pdfjs.disabled, steht dieser auf false?

  23. Anon
    schrieb am :

    (Ich weiß es wird gerade etwas Off-Topic und dies ist kein Bugtracker…)

    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.

    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.

  24. Jens Almann
    schrieb am :

    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

  25. Anon
    schrieb am :

    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).

  26. schrieb am :

    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.

  27. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

  28. Ben
    schrieb am :

    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.)

  29. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

  30. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Mir sind Kommentare entgangen…

    @Anon:

    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.

    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.

  31. Anon
    schrieb am :

    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…

  32. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    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.

Und jetzt du! Deine Meinung?

Erforderliche Felder sind mit einem Asterisk (*) gekennzeichnet. Die E-Mail-Adresse wird nicht veröffentlicht.
  1. Nach Absenden des Kommentar-Formulars erfolgt eine Verarbeitung der von Ihnen eingegebenen personenbezogenen Daten durch den datenschutzrechtlich Verantwortlichen zum Zweck der Bearbeitung Ihrer Anfrage auf Grundlage Ihrer durch das Absenden des Formulars erteilten Einwilligung.
    Weitere Informationen