Camp Firefox

Die Firefox-Community

Private Browsing 2.0: Mozilla erweitert Privaten Modus um Tracking-Schutz

Mozilla hat wie bereits vorab angekündigt den Privaten Modus von Firefox um einen Tracking-Schutz erweitert, den Nutzer der Nightly-Version und Developer Edition von Firefox nun testen können.

Firefox besitzt bereits seit einiger Zeit einen experimentellen Tracking-Schutz. Dieser kann in Vorabversionen von Firefox über eine versteckte Einstellung aktiviert werden. In die Nightly-Version von Firefox 39 wurde die experimentelle Funktion über eine weitere versteckte Einstellung zur Verfügung gestellt, den Tracking-Modus in den sogenannten privaten Fenstern zu aktivieren. Private Fenster sind Fenster, in denen Firefox keine Chronik, Sucheinträge, Cookies oder sonstige Surfspuren zurücklässt.

Wer eine Nightly-Version von Firefox oder die Developer Edition nutzt, wird feststellen können, dass diese Option in den Einstellungen sichtbar gemacht worden ist. Darüber hinaus ist der Tracking Schutz für private Fenster nun standardmäßig aktiviert.

Die Startseite der privaten Fenster wurde außerdem überarbeitet und macht nun deutlicher als bisher klar, was sich Firefox in diesem Modus merkt und was nicht. Der neue Tracking-Schutz findet in dem neuen Design eine besondere Hervorhebung. Der Status, ob dieser aktiviert ist oder nicht, wird auf dieser Seite ebenso angezeigt wie ein Link, um diesen zu deaktivieren respektive wieder zu aktivieren, ohne dafür extra in die Einstellungen gehen zu müssen.

Mit aktiviertem Tracking-Schutz erkennt der Nutzer am Schild-Symbol in der Adressleiste, dass Elemente blockiert worden sind. Hierüber gibt es auch die Möglichkeit, den Tracking-Schutz für die aktuelle Session auf dieser Webseite zu deaktivieren. In dem Fall befindet sich hinterher ein durchgestrichenes Schild-Symbol in der Adressleiste.

Wer wissen will, welche Elemente durch den Tracking-Schutz blockiert worden sind, kann dies über die Webkonsole ablesen.

Abgrenzung zu Werbeblockern

Der Tracking-Schutz blockiert Elemente von bekannten Trackern. Dies trifft häufig auf Anzeigen aus Werbenetzwerken zu, womit der Tracking-Schutz einen Großteil der Werbung im Web blockiert. Es handelt sich hierbei aber um keinen klassischen Werbeblocker, der jede Werbung blockiert: Werbung, die ohne Tracking auskommt, wird durch den Tracking-Schutz naheliegenderweise nicht blockiert.

Mozilla kündigt große Änderungen für Entwickler von Firefox Add-ons an

Mozilla hat heute eine Reihe von Ankündigungen gemacht, welche die Zukunft der Entwicklung von Add-ons für Firefox betreffen. Dabei geht es neben der Signierung von Add-ons und der kommenden Multiprozessarchitektur (Electrolysis, kurz: e10s) auch um die Einführung der sogenannten WebExtensions, welche größtenteils API-kompatibel mit Chrome, Opera und in der Zukunft ggfs. auch Edge ist, sowie um die Deprecation von XUL, XBL und XPCOM.

Auf die Entwickler von Add-ons für Firefox kommt eine Reihe von wichtigen Änderungen zu, die Mozilla frühzeitig kommuniziert, so dass Entwickler rechtzeitig über Mozillas Pläne informiert sind. Diese Änderungen seien notwendig, um Technologien wie die Multiprozessarchitektur Electrolysis (auch bekannt als e10s) oder Mozillas kommende Browserengine Servo zu unterstützen, die Nutzer besser vor Spyware und Aware zu schützen und außerdem die Zeit zu reduzieren, die es für die Reviews von Add-ons benötigt.

Neue Schnittstelle für browserübergreifend kompatible Add-ons

Die Entwicklung von Add-ons sollte nach Ansicht von Mozilla vergleichbar mit der Entwicklung von Webseiten sein: der selbe Code soll in verschiedenen Browsern funktionieren. Mit den sogenannten WebExtensions führt Mozilla eine neue Schnittstelle für Add-ons ein, welche größtenteils kompatibel mit Chrome und Opera ist – möglicherweise in der Zukunft sogar mit Microsoft Edge, wie Mozilla andeutet. Mozilla hat bereits Diskussionen mit anderen Browserherstellern gestartet, um zumindest einen Teil der Schnittstelle zu standardisieren und somit die browserübergreifende Kompatibilität auch langfristig zu gewährleisten. Dies bedeutet für Entwickler, die Add-ons für verschiedene Browser entwickeln, dass nur minimale Anpassungen notwendig sind und nicht für jeden Browser eine grundlegend unterschiedliche Erweiterung programmiert werden muss. Ein weiterer Vorteil der WebExtensions ist, dass diese die Multiprozessarchitektur der Browser direkt unterstützen. Eine erste Unterstützung für WebExtensions wird ab Firefox 42 verfügbar sein.

Multiprozessarchitektur („Electrolysis“ / „e10s“)

Die geplante Multiprozessarchitektur für Firefox macht große Fortschritte und wird bekanntermaßen große Auswirkungen auf die Kompatibilität von Add-ons haben, insbesondere von Add-ons, welche mit dem Inhalt von Webseiten interagieren.

Die neuen WebExtensions sind wie bereits erwähnt vollständig kompatibel mit e10s. Add-ons, die auf dem Add-on SDK basieren, auch bekannt als Jetpack, sind kompatibel, solange sie nicht require(‘chrome’) oder manche Low-Level-APIs nutzen, die Objekte im Content-Prozess berühren. Dann gibt es noch sogenannte Kompatibilitäts-Shims in Firefox, die dafür sorgen, dass Add-ons oder Teile von Add-ons auch in e10s funktionieren, obwohl sie noch nicht für e10s angepasst worden sind – dies allerdings zum Preis einer spürbar schlechteren Performance.

Einen verbindlichen Zeitplan für die Auslieferung von e10s in einer finalen Version von Firefox gibt es noch nicht. Fest steht, dass e10s in der Nightly Version sowie Developer Edition bereits standardmäßg aktiviert ist. Am 22. September wird Firefox 42 die Betaphase erreichen und e10s den Nutzern per Opt-In zur Aktivierung angeboten werden. Die am 3. November erscheinende Betaversion von Firefox 43 wird die früheste Betaversion sein, in welcher e10s standardmäßig aktiviert sein wird. Sobald dies der Fall ist, wird Mozilla damit beginnen, Add-ons zu blockieren, die nicht kompatibel mit e10s sind und Performance- und/oder Stabilitätsprobleme verursachen. Am 15. Dezember erscheint dann die finale Version von Firefox 43 und damit die frühestmögliche Version, in welcher e10s aktiviert sein wird. Im Zeitraum von zwischen sechs und zwölf Monaten nach der standardmäßigen Aktivierung von e10s in der finalen Version von Firefox wird Mozilla die Kompatibilitäts-Shims entfernen, womit Add-ons inkompatibel werden, die hiervon Gebrauch machen.

Entwickler von Add-ons sollten sich also so langsam mit der möglicherweise notwendigen Anpassung ihrer Add-ons befassen, falls nicht schon geschehen, und ggfs. das Kompatibilitäts-Flag setzen. Eine Alternative dazu ist natürlich die Portierung zu einer WebExtension. Add-ons können bereits in der Nightly Version sowie Developer Edition mit aktivierter Multiprozessarchitektur getestet werden. Außerdem ist jeder eingeladen, auf der Webseite arewee10syet.com die Liste der Add-ons durchzugehen und die Kompatibilität der Add-os zu testen.

Signierung von Add-ons

An den Plänen zur Signierung von Add-ons hat sich nichts geändert. Add-ons müssen in Zukunft von Mozilla signiert sein, damit sie in Firefox installiert werden können. Damit sollen Nutzer besser vor schädlichen Add-ons und Add-ons, die Dinge gegen den ausdrücklichen Willen des Nutzers machen, geschützt werden. Bislang konnte Mozilla immer nur im Nachhinein reagieren und Add-ons blockieren, nachdem sie bereits Schaden angerichtet haben.

Seit Version 40 warnt Firefox bei nicht signierten Add-ons, ab Version 41 werden diese standardmäßig deaktiviert werden, können aber per Änderung in about:config wieder zum Laufen gebracht werden, ab Firefox 42 ist die Signaturpflicht in der finalen Version und in der Beta unumgänglich. In der Nightly-Version sowie Developer Edition wird die Signaturpflicht auch weiterhin deaktivierbar bleiben. Außerdem wird Mozilla spezielle Beta- und Finalbuilds ohne offizielles Firefox-Branding bereitstellen, welche ebenfalls eine Deaktivierung der Signaturpflicht erlauben.

Schnellere Reviews von Add-ons

Bis Add-ons ein Review von Mozilla erhalten, können schon mal Wochen vergehen – was ohne Frage zu lange ist. Auch hier spielen die neuen WebExtensions einen Vorteil aus, denn diese können wesentlich schneller von Mozilla kontrolliert werden. Ziel sind maximal fünf Tage für ein neues Add-on und maximal zwei Tage für ein Update.

Mozilla wird außerdem das Team der freiwilligen und bezahlten Reviewer aufstocken und weitere Verbesserungen am automatischen Validator vornehmen, um die Wartezeiten zu verkürzen.

Deprecation von XUL, XBL und XPCOM

Eine weitere sehr große Veränderung betrifft die XUL- und XPCOM-basierten Erweiterungen. Dass Mozilla von XUL und XBL abweichen möchte, ist nicht neu. Auch kann Firefox nicht Mozillas kommende Engine Servo nutzen, solange XUL unterstützt wird. Die enge Verzahnung von Browser und XUL-Erweiterungen bereitet außerdem Probleme für die Entwicklung, die in der Ankündigung näher benannt werden.

Für die Deprecation von XUL, XBL und XPCOM gibt es noch keinen genauen Zeitplan, vermutlich wird dies aber innerhalb der nächsten zwölf bis 18 Monate passieren. Ab dann muss man sich darauf einstellen, dass Add-ons, welche Gebrauch von diesen Technologien machen, irgendwann nicht länger funktionieren werden.

Mozilla ist sich dessen bewusst, dass die SDK basierten Add-ons und auch die WebExtensions Stand heute nicht alles leisten können, was XUL-basierte Add-ons leisten können. Basierend auf dem Feedback der Entwickler möchte Mozilla die WebExtensions-API im Laufe des kommenden Jahres aber entsprechend erweitern, um so viel wie möglich zu unterstützen, was von den populären Erweiterungen benötigt wird.

Mozilla schaltet FTP-Zugriff auf Downloadverzeichnis ab

Neue, aber auch alte Versionen von Firefox und anderen Mozilla-Produkten konnten bislang per FTP heruntergeladen werden. Als Teil der geplanten Migration in die Amazon-Cloud wurde nun der FTP-Zugriff auf das Downloadverzeichnis abgeschaltet.

Neue Versionen von Firefox sollte man sich grundsätzlich immer über die offizielle Webseite herunterladen. Manchmal möchte man aber zu Testzwecken eine ältere Version herunterladen, Ungeduldige suchen sich über das FTP-Verzeichnis vor der offiziellen Freigabe und Veröffentlichung einer neuen Version die Downloads. Dies geschieht in der Regel über ftp.mozilla.org. Der FTP-Zugriff (ftp://ftp.mozilla.org) darauf ist seit Anfang August nicht länger möglich und liefert nur noch den Status „550 Permission denied“ zurück. Weiterhin möglich ist der Zugriff im Browser über https:// respektive http://.

Damit ist die Eingabe von „ftp.mozilla.org“ in die Adressleiste nicht länger ausreichend, da diese standardmäßig auf das FTP-Protokoll auflöst. Es müsste stattdessen explizit „https://ftp.mozilla.org“ oder „http://ftp.mozilla.org“ in die Adressleiste eingegeben werden. Auch wenn diese URL weiterhin funktioniert, sollten Nutzer, die im Browser auf das Verzeichnis zugreifen, in Zukunft stattdessen den Link https://archive.mozilla.org verwenden.

Ende August wird Mozilla damit beginnen, die Inhalte von ftp.mozilla.org aus den eigenen Datenzentren nach AWS/S3 (Amazon Web Services Simple Storage Service) zu migrieren. Abgeschlossen soll die Migration Ende Oktober sein.

Weitere Informationen
Mozilla IT & Operations: Product Delivery Migration: What is changing, when it’s changing and the impacts

Programmiersprache: Rust 1.2 und Rust 1.3 Beta stehen bereit

Rust ist eine neue Programmiersprache, in welcher die ebenfalls sich in Entwicklung befindliche neue Rendering-Engine von Mozilla geschrieben wird, die auf den Namen Servo hört. Wieder sind sechs Wochen vergangen, so stehen nun Rust 1.2 und Rust 1.3 Beta bereit.

Für die neue Programmiersprache Rust, in welcher auch Mozillas neue Engine Servo entwickelt wird, ist ein Release-Zyklus vorgesehen, den man ähnlich auch von Firefox kennt: alle sechs Wochen erscheint eine neue Version und gleichzeitig eine erste Betaversion des Nachfolgers der neuen Version. Nachdem vor sechs Wochen Rust 1.1 und Rust 1.2 Beta erschienen sind, stehen nun erwartungsgemäß Rust 1.2 sowie Rust 1.3 Beta bereit.

Wie bereits in Rust 1.1 wurde auch in Rust 1.2 wieder an der Performance-Schraube des Compilers gedreht, auch Cargo hat Performance-Verbesserungen erhalten. Außerdem erhält Rust 1.2 eine erste Unterstützung für Microsoft Visual C (MSVC).

  • An across-the-board improvement to real-world compiler performance. Representative crates include hyper (compiles 1.16x faster), html5ever (1.62x faster), regex (1.32x faster) and rust-encoding (1.35x faster). You can explore some of this performance data at Nick Cameron’s preliminary tracking site, using dates 2015-05-15 to 2015-06-25.
  • Parallel codegen is now working, and produces a 33% speedup when bootstrapping on a 4 core machine. Parallel codegen is particularly useful for debug builds, since it prevents some optimizations; but it can also be used with optimizations as an effective -O1 flag. It can be activated by passing -C codegen-units=N to rustc, where N is the desired number of threads.

Cargo’s performance has also improved dramatically:

  • Builds that do not require any recompilation (“no-op builds”) for large projects are much faster: for Servo, build time went from 5 seconds to 0.5 seconds.
  • Cargo now supports shared target directories that cache dependencies across multiple packages, which results in significant build-time reduction for complex projects.

Detailliertere Informationen sowie erste Informationen zu Rust 1.3 lassen sich in der offiziellen Ankündigung nachlesen.

Firefox 39.0.3 / ESR 38.1.1: Mozilla behebt Sicherheitslücke in PDF-Betrachter

Mozilla hat nur vier Tage vor dem kommenden planmäßigen Firefox-Update ein Sicherheits-Update für Firefox veröffentlicht, welches eine schwerwiegende Sicherheitslücke im integrierten PDF-Betrachter behebt.

Mozilla wird am kommenden Dienstag Firefox 40 veröffentlichen. Und obwohl es nur noch wenige Tage bis dahin sind, sah sich Mozilla dazu veranlasst, vorab noch ein Sicherheits-Update für Firefox 39 und Firefox ESR 38 vorzuschieben, was die Einstufung als schwerwiegende Sicherheitslücke zusätzlich unterstreicht. Konkret handelt es sich um eine Sicherheitslücke im integrierten PDF-Betrachter, welche nach Angaben von Mozilla bereits ausgenutzt wird. Ein Update ist damit für alle Nutzer dringend empfohlen, welche den integrierten PDF-Betrachter und kein Plugin zur Darstellung von PDF-Dateien nutzen. Die Sicherheitslücke erlaubt es einem Angreifer, Zugriff auf lokale Dateien zu erlangen.

Die neuen Versionen tragen die Versionsnummern 39.0.3 respektive ESR 38.1.1. Firefox ESR 31 ist von der Sicherheitslücke nicht betroffen, wird ab Dienstag im Falle von Sicherheitslücken aber auch keine weiteren Updates mehr erhalten. Nutzer von Firefox ESR 31 sollten also möglichst bald auf Firefox ESR 38 aktualisieren, falls noch nicht geschehen.

Update: Mozilla hat eine ausführliche Ankündigung veröffentlicht. Demnach existiert die Sicherheitslücke auf Windows, OS X sowie auf Linux, bekannt ist aber nur die Ausnutzung auf Windows und Linux. Wer Windows oder Linux nutzt, sollte alle gespeicherten Passwörter und Schlüssel in den folgenden Dateien ändern:

On Windows the exploit looked for subversion, s3browser, and Filezilla configurations files, .purple and Psi+ account information, and site configuration files from eight different popular FTP clients. On Linux the exploit goes after the usual global configuration files like /etc/passwd, and then in all the user directories it can access it looks for .bash_history, .mysql_history, .pgsql_history, .ssh configuration files and keys, configuration files for remina, Filezilla, and Psi+, text files with “pass” and “access” in the names, and any shell scripts.

Firefox 42: Mozilla aktiviert Media Source Extensions (MSE) für alle Webseiten

Die sogenannten Media Source Extensions (MSE) sind bislang nur für ausgewählte Webseiten in Firefox aktiviert. In Firefox 42 entfernt Mozilla diese Restriktion und macht damit MSE für alle Webseiten verfügbar.

Bei den Media Source Extensions (MSE) handelt es sich um die entscheidende Zutat, welche beispielsweise den HTML5-Player von YouTube um die hohen Auflösungen erweitert, aber auch für die 60FPS-Videos auf YouTube werden die MSE benötigt. Seit Firefox 37 sind die Media Source Extensions standardmäßig in Firefox für Windows und OS X aktiviert – allerdings zu diesem Zeitpunkt nur für YouTube, mittlerweile außerdem für Netflix und Dailymotion. Mozilla hat die Implementierung weiter verbessert und wird diese Restriktion – sofern nichts schief geht – in Firefox 42 aufheben. Dann stehen die Media Source Extensions für alle Webseiten zur Verfügung.

Firefox Nightly / Developer Edition erfordert ab sofort signierte Add-ons (deaktivierbar)

Add-ons müssen in Zukunft von Mozilla signiert sein, damit sie in Firefox installiert werden können. Dies ist ab sofort auch in der Nightly-Version und Developer Edition standardmäßig Voraussetzung, dort aber wie bereits angekündigt deaktivierbar.

Zum Schutz seiner Nutzer führt Mozilla eine Signaturpflicht für Add-ons ein. Für Add-on, welche auf Mozillas Add-on-Webseite AMO (addons.mozilla.org) gehostet werden, sollte sich dadurch nicht viel ändern, da die Signierung automatisch im Zuge des Reviews erfolgt. Wer sein Add-on auf einer anderen Webseite hostet oder ein fremdes Add-on zu privaten Zwecken selbst angepasst hat, kann dies auch weiterhin tun, muss dafür aber sein Add-on zur Signierung einreichen. Wie das funktioniert, kann hier nachgelesen werden. Normalerweise sollte auch dies kein Problem sein.

Die Signaturpflicht ist nun in der Nightly-Version sowie Developer Edition von Firefox 42 respektive 41 scharf geschaltet. Das bedeutet, dass sich standardmäßig keine Add-ons mehr installieren lassen, welche nicht signiert sind. Bereits installierte, nicht signierte Add-ons werden automatisch deaktiviert. Wer die Signaturpflicht deaktivieren will, kann dies über about:config tun, indem der Schalter xpinstall.signatures.required per Doppelklick auf false gesetzt wird.

Mozilla wird in Firefox 40 eine Warnung im Add-on Manager anzeigen, wenn ein Add-on nicht signiert ist. In Firefox 41 werden nach aktueller Planung nicht signierte Add-ons automatisch deaktiviert, können aber durch Kippen des genannten Schalters wieder aktiviert werden. Ab Firefox 42 gibt es diese Einstellung nur noch in der Nightly-Version sowie in der Developer Edition. In der Beta- sowie finalen Version von Firefox ist die Signierung von Add-ons dann unumgänglich. Darüber hinaus wird Mozilla spezielle Builds der finalen sowie Betaversionen ohne offizielles Firefox-Branding veröffentlichen, welche ebenfalls eine abschaltbare Signaturpflicht besitzen werden.

Aktivierte Signaturpflicht:

Deaktivierte Signaturpflicht (nur Warnungen):

Chromecast-Alternative Matchstick wird nicht ausgeliefert, Unterstützer erhalten Geld zurück

Mit dem Matchstick sollte es eine auf Firefox OS basierende Alternative zum Google Chromecast geben. Bei der Kickstarter-Finanzierung Ende des vergangenen Jahres wurde das Ziel deutlich übertroffen. Nun haben die Macher bekannt gegeben, dass man aufgrund von Schwierigkeiten in der Entwicklung das Produkt nicht ausliefern und stattdessen den Unterstützern das Geld zurückerstatten wird.

Eine Alternative zu Google Chromecast, aber besser, günstiger und ein wirklich offenes System – so lauteten die ehrgeizigen Ziele der Macher des Matchsticks. Das Projekt hatte einen vielversprechenden Start: das Finanzierungsziel von 100.000 Dollar war bereits nach 24 Stunden erreicht und wurde deutlich übertroffen. Am Ende waren es ganzen 470.310 Dollar. Im Februar gab es dann die Ankündigung, dass sich die Auslieferung um ein halbes Jahr verspäten wird. Der Grund: man wollte dem Matchstick eine bessere Hardware spendieren und um Fähigkeiten zum Digital Rights Management (DRM) erweitern, was den Weg für Premium-Inhalte, beispielsweise von Netflix, ebnen sollte.

Ausgerechnet die von vielen Unterstützern sowieso nicht gewünschte DRM-Entwicklung ist es nun, was den Entwicklern so große Schwierigkeiten bereitet und Grund für die Entscheidung ist, allen Unterstützern das Geld zurückzuzahlen statt mit dem Geld der Unterstützer die Auslieferung erneut und auf unbestimmte Zeit zu verschieben. Wie es mit dem Projekt weitergeht, wurde nicht kommuniziert. Da die Rückerstattung von Hand geschieht, soll man sich auf einen Zeitraum von bis zu 60 Tagen einstellen, den es dauern kann, bis jeder der 17.218 Unterstützer sein Geld zurück hat.

Firefox Nightly: Performance-Monitor identifiziert langsame Add-ons und Webseiten

Die Nightly-Version von Firefox besitzt einen Performance-Monitor, der dabei helfen kann, Add-ons und Webseiten zu identifizieren, welche die Performance negativ beeinträchtigen.

Nutzer der Nightly-Version von Firefox können bereits seit einigen Monaten über about:performance auf ein Tool zugreifen, welches dabei helfen kann, die Ursache für Performance-Probleme zu finden.

Dieses zugegebenermaßen nicht ganz einfach interpretierbare Werkzeug präsentiert sich in der aktuellsten Nightly-Version optisch überarbeitet und leichter verständlich, da nun auf einen Blick erkannt werden kann, wenn ein Add-on oder eine Webseite einen negativen Einfluss auf die Performance hat. Farben zwischen Grün und Rot zeigen, wie stark der Performance-Einfluss ist, per Klick lassen sich Details wie die CPU-Auslastung ablesen, außerdem lassen sich Tabs direkt hierüber schließen. Es kann wahlweise der Gesamt-Einfluss seit dem Firefox-Start oder nur der letzten zehn Sekunden angezeigt werden.

Der Performance-Monitor ist nach wie vor ausschließlich in der Nightly-Version von Firefox verfügbar. Mozilla plant noch weitere Verbesserungen der Genauigkeit sowie des Performance-Einflusses des Performance-Tools selbst, ehe das Feature in der Firefox Developer Edition und darüber hinaus erwartet werden kann.

Mozilla schaltet Firefox Sync 1.1-Server Ende September ab

Mozilla wird in Kürze erwartungsgemäß die Server des alten Firefox Sync 1.1 abschalten. Nutzer, welche noch nicht auf Sync 1.5 migriert sind, haben noch zwei Monate Zeit, ehe Mozilla die Server abschaltet und kein weiterer Zugriff mehr auf die Daten möglich ist.

Mozilla hat den Zeitpunkt der Abschaltung der Firefox Sync 1.1-Server bekannt gegeben: ab dem 30. September wird es nicht länger möglich sein, sich mit seinen Sync 1.1-Daten anzumelden. Im April 2014 hat Mozilla mit Firefox 29 die sogenannten Firefox Accounts und das neue Sync 1.5 eingeführt und damit die alte Sync-Architektur ersetzt. Nach wie vor ist es aber möglich, Sync 1.1 in Firefox zu nutzen. Die Abschaltung der alten Sync-Server wurde bereits im Februar für die zweite Jahreshälfte 2015 angekündigt, seit Firefox 37 weist Mozilla Nutzer des alten Syncs auf das bevorstehende Ende von Sync 1.1 hin und bietet eine Migration auf Sync 1.5 an.

Mozilla hat mit der aktuellen Ankündigung auch eine Liste mit Antworten auf naheliegende Fragen veröffentlicht. Dort wird unter anderem erklärt, dass es nicht nur um die Einsparung von Ressourcen geht, die Sync 1.1-Server also nicht einfach in einer Art Wartungsmodus weiter betrieben werden können, sondern die Abschaltung auch finanzielle Gründe hat: Sync 1.1 werde auf alter Hardware betrieben, deren Betrieb mit signifikaten Kosten für Mozilla verbunden sei, und die man ausmustern möchte.

Aufgrund der starken Verschlüsselung sowohl des alten als auch des neuen Syncs ist eine automatische Migration nicht möglich. Darum besteht die Migration darin, sich ein neues Sync-Konto anzulegen, den Firefox Account, und seine Daten wie Lesezeichen und Chronik neu hochzuladen. Hierzu hat Mozilla eine Anleitung veröffentlicht.

Wer einen eigenen Sync 1.1-Server betreibt, ist hiervon nicht betroffen. Dann wird Firefox auch nach dem 30. September noch die Daten synchronisieren. Aber auch in diesem Fall sollte man sich auf den Umstieg auf Sync 1.5 vorbereiten, denn Mozilla hat die Entfernung der Sync 1.1-Unterstützung aus dem Firefox-Produkt für 2016 angekündigt. Auch zum Betrieb eines eigenen Sync 1.5-Servers hat Mozilla eine Anleitung veröffentlicht und optional auch zum Betrieb eines eigenen Firefox Account-Servers.

Seiten

Camp Firefox RSS abonnieren