Mozilla Brick: UI-Komponenten für moderne Web Apps

Mit den Web Components befindet sich eine Webtechnologie in der Standardisierung durch das W3C, welche es Webentwicklern erlaubt, eigene HTML-Elemente für Webanwendungen zu bauen. Mit Brick stellt Mozilla nun eine Sammlung wiederverwendbarer UI-Komponenten vor.

Brick heißt das neuste Projekt aus dem Hause Mozilla und besteht aus einer Sammlung von UI-Komponenten, welche cross-browser-kompatibel sind. Brick nutzt dafür X-Tag – eine von Mozilla entwickelte Polyfill-Bibliothek, welche die sogenannten Web Components in heutigen Browsern verfügbar macht. X-Tag ist kompatibel mit Firefox ab Version 5, Chrome ab Version 4, Safari ab Version 4, Opera ab Version 11 sowie dem Internet Explorer ab Version 9. Bricks befindet sich derzeit noch in der Betaphase.

Mit Web Components sind Webentwickler dazu in der Lage, eigene HTML-Elemente zu bauen, welche in der Anwendung wiederverwendet werden können. Eines der Bricks ist beispielsweise ein Kalender. Eine Zeile wie reicht, um einen Kalender in die Webanwendung zu integrieren. Weitere Widgets, welche Brick bereitstellt, sind unter anderem eine Tab-Leiste, ein Slider oder auch Tooltips. Mit den Bricks kann ein Entwickler viel Zeit sparen, da er sich keine Gedanken um das HTML/CSS/JavaScript dahinter machen muss.

Die Widgets von Brick sind mit allen aktuellen Browsern kompatibel und mobiltauglich. Im Gegensatz zu jQuery UI erfordert Brick kein nicht-semantisches HTML-Markup und muss nicht explizit via JavaScript initialisiert werden. Mit Brick genügt es, den entsprechenden Tag im HTML der Anwendung zu schreiben als wäre es ein ganz gewöhnlicher Bestandteil von HTML.

Plug-n-Hack: Mozilla schlägt Standard zur Interaktion zwischen Sicherheitstools und Browsern vor

Mit Plug-n-Hack (PnH) schlägt Mozilla einen Standard vor, welcher definiert, wie Sicherheitstools mit Browsern besser interagieren können.

In einem aktuellen Blog-Beitrag schreibt Mozilla, dass Sicherheitstools häufig in Verbindung mit Browsern benutzt werden, bislang aber eine direkte Interaktion Plattform- und Browsererweiterungen notwendig gemacht haben. Das Konfigurieren des Browsers, damit dieser mit einem Sicherheitstool zusammenarbeitet, sei ein nicht trivialer Vorgang, welcher Entwickler und Tester mit weniger Erfahrung davon abhalten kann, solche Tools zu nutzen.

PnH soll dieses Problem lösen, indem es Sicherheitstools erlaubt, die Funktionalitäten mittels Manifest festzulegen, welche geeignet für eine Interaktion mit dem Browser sind. Ein Browser, welcher PnH unterstützt, kann diese Funktionalitäten dann direkt aufrufen ohne zum und vom Tool hin- und herwechseln zu müssen. Neben einigen fest definierten Fähigkeiten, beispielsweise zur Proxy-Konfiguration, seien die meisten Möglichkeiten dabei komplett generisch gehalten, so dass praktisch jede denkbare Funktionalität über PnH festgelegt werden kann.

PnH wurde sowohl browser- als auch toolunabhängig entwickelt, auch eine Implementierung für Firefox ist bereits vorhanden. Beides steht unter der Mozilla Public Licence 2.0 und ist damit auch für kommerzielle Tools geeignet. Mozilla hofft, dass auch andere Browserhersteller PnH implementieren werden. Der aktuelle Stand, von Mozilla als Phase 1 bezeichnet, erlaubt die einfache Integration und definiert, wie Sicherheitstools ihre Fähigkeiten dem Browser bekannt machen können. In Phase 2 sollen dann auch Browser den Sicherheitstools mitteilen können, welche Fähigkeiten diese besitzen und genutzt werden können. Dann sollen die Tools Informationen direkt vom Browser erhalten und der Browser sogar als Erweiterung des Tools genutzt werden können.

Unterstützt wird PnH in Firefox ab Version 24 unter Zuhilfenahme des Add-ons Ringleader. OWASP ZAP 2.2.0 ist das erste Sicherheitstool, welches PnH unterstützt, hierfür wird das MITM-conf Add-on benötigt. Die Unterstützung für die Burp Suite soll bald folgen.

Firefox: Add-on Manager findet ab sofort nur noch vollständig überprüfte Add-ons

Add-ons für Firefox können direkt über den integrierten Add-on Manager gesucht und installiert werden. Dieser findet ab sofort nur noch vollständig überprüfte Erweiterungen.

Alle Add-ons, welche sich über addons.mozilla.org finden lassen, sind entweder vollständig oder vorläufig von Mozilla überprüft. Die vollständige Überprüfung stellt höhere Anforderungen an die Qualität der Add-ons, während die vorläufige Überprüfung nicht weit über das Überprüfen auf Sicherheitslücken und Regelverstöße hinausgeht und dabei in der Regel auch nicht installiert und auf korrektes Funktionieren überprüft wird.

Auf der Add-on-Seite sind die Unterschiede gut erkennbar, so ist der Button zum Installieren bei vollständig geprüften Erweiterungen grün, bei vorläufig geprüften Erweiterungen gelb mit Hinweis. Im Add-on Manager gibt es diese Unterscheidung nicht. Aus diesem Grund wird Mozilla ab sofort nur noch vollständig überprüfte Erweiterungen in der Suche des Add-on Managers anzeigen. Da es sich dabei um eine serverseitige Änderung handelt, betrifft diese Änderung alle Versionen von Firefox.

Firefox OS ab Oktober in Deutschland

Firefox OS kommt nach Deutschland und zwar im Oktober. Dann wird Congstar Smartphones mit Mozillas Betriebssystem verkaufen.

Seit etwas mehr als einem Monat ist bekannt, dass die Deutsche Telekom plant, diesen Herbst in Deutschland Smartphones mit Firefox OS unter der Congstar-Marke zu verkaufen. Nun steht auch der Monat für den Verkaufsstart fest. Ab Oktober sollen die Geräte über die Ladentheke gehen. Weitere Details sind noch nicht bekannt, werden aber in den nächsten Wochen erwartet.

via: telecompaper.com

Google und Mozilla: Kürzere Laufzeiten für Zertifikate

Google und Mozilla planen zur Verbesserung der Sicherheit Zertifikate nur noch mit einer geringeren Laufzeit für ihre Browser Chrome respektive Firefox zu akzeptieren.

Google wird ab Anfang des kommenden Jahres keine nach dem 01. Juli 2012 ausgestellten Zertifikate mit einer Laufzeit länger als fünf Jahre für Chrome / Chromium mehr akzeptieren. Ab dem 01. April 2015 soll die maximale Laufzeit auf 39 Monate gesenkt werden. Dies entspricht den Baseline Requirements des CA/Browser-Forums, welche Ende 2011 von Zertifikatsausstellern und Browserherstellern beschlossen worden sind. Damit macht Google den Anfang, Mozilla plant Google zu folgen und die Baseline Requirements ebenfalls entsprechend umzusetzen. Es geht dabei nicht um die Zertifikate der Certificate Authorities, welche in den Browsern integriert sind, sondern um beispielsweise die Zertifikate beim Aufbau von verschlüsselten Verbindungen über SSL.

Firefox Mobile 26 für Android mit neuem Awesomescreen

Mit dem neuen Awesomescreen erhält Mozillas Browser für Android-Geräte in Version 26 einen Umbau der etwas größeren Sorte und den optisch größten seit der Neuentwicklung von Firefox für Android von Version 10 auf Version 14. Der neue Awesomescreen ersetzt die alte Startseite und Seitenauswahl beim Tippen in die Adressleiste.

Firefox Mobile bietet derzeit unterschiedliche Inhalte auf der Startseite und bei Klick auf die Adressleiste an. Die Startseite zeigt Vorschaubilder der meistbesuchten Webseiten an. Den Bildschirm bei Klick auf die Adressleiste bezeichnet Mozilla als Awesomescreen, ähnlich wie die Adressleiste der Desktop-Version von Firefox als Awesomebar bezeichnet wird. Der Awesomescreen bietet Zugriff auf die meistbesuchten Seiten, Lesezeichen sowie Chronik.

Mit Firefox 26 werden beide Bildschirme zu einem neuen Awesomescreen vereint. Welchen Umfang diese Änderung besitzt, erzählt Lukas Rocha, User Interface Designer bei Mozilla für den Android-Browser, in seinem Blog. Über drei Monate aktive Entwicklung mit 250 Changesets und 147 geschlossenen Bugs in Mozillas Bugtracker, bei welchem alle Verbesserungen, also nicht nur Fehler, als Bug bezeichnet werden. Bis zur Veröffentlichung der finalen Version wird noch weiterer Feinschliff betrieben. Firefox Mobile 26 wird am 10. Dezember erscheinen.

Es handelt sich dabei um eine komplette Neuentwicklung des Awesomescreens, also nicht nur einem neuen optischen Anstrich. Die Zusammenlegung beider Bildschirme zu einem dürfte die Bedienung von Firefox Mobile nicht unbedeutend intuitiver machen. Der Awesomescreen besteht aus mehreren Seiten, zwischen welchen sich per Wischgeste blättern lässt. Standardmäßig geöffnet ist die Ansicht für die Lesezeichen. Wie auf der alten Startseite gibt es hier sechs Vorschaubilder, darunter befindet sich eine Auflistung der übrigen Lesezeichen und Lesezeichen-Ordner. Eine Wischgeste nach links führt zur Chronik. Hier gibt es drei weitere Tabs, auf dem Smartphone unten, auf dem Tablet auf der linken Seite. Dort kann zwischen den meistbesuchten und den aktuellsten Seiten sowie den Tabs der letzten Sitzung gewechselt werden. Eine Wischgeste von den Lesezeichen aus nach rechts geht es zur Leseliste. Hier finden sich zu dieser Liste hinzugefügte Artikel, welche per Klick im Lesemodus angezeigt werden. Die dort abgelegten Artikel stehen übrigens sogar offline zur Verfügung.

 

 

Firefox OS: Smartphone von LG im ersten Quartal 2014

Auch LG gehört zu den Hardware-Herstellern, welche mindestens ein Gerät mit Firefox OS auf den Markt bringen werden. Im ersten Quartal 2014 soll es soweit sein.

Dimitar Valev, Manager for Mobile Communications and Products von LG in Bulgarien, hat in einem Interview mit Dnevnik.bg noch einmal bestätigt, dass LG an einem Smartphone mit Firefox OS arbeitet, und dieses für Anfang des nächsten Jahres in Aussicht gestellt. LG hatte bereits auf dem Mobile World Congress 2013 im Februar angekündigt, ein Smartphone mit Firefox OS anbieten zu wollen.

via: The Next Web

Firefox OS: ZTE Open in UK und USA ausverkauft

ZTE hat am vergangenen Freitag den Vertrieb seines Smartphones ZTE Open über die eBay-Shops in UK und USA begonnen. Die Geräte waren bereits am Montag ausverkauft.

Die Menge der Geräte war zugegebenermaßen nicht übermäßig groß. Dennoch lässt sich das Interesse an Mozillas Betriebssystem Firefox OS nicht leugnen. 990 Smartphones wurden im UK-Shop verkauft, 985 waren es im USA-Shop. Der Preis belief sich auf £59.99 respektive $79.99 inklusive Versand. Besonders war dabei nicht nur die Art des Vertriebes über eBay, sondern auch das Smartphone selbst – die orangefarbene Version des ZTE Open gab es nur über eBay, die Telekommunikationsanbieter in den verschiedenen Ländern bieten das ZTE Open in Blau an. Ob / wann weitere Geräte über eBay vertrieben werden, ist derzeit nicht bekannt.

Bildquelle: ZTE

FuzzDB: Mozilla stellt Datenbank zum Finden von Sicherheits-Schwachstellen vor

Mit FuzzDB hat Mozilla im offiziellen Sicherheits-Blog eine Open Source Datenbank mit Angriffsmustern, verbreiteten Ressourcennamen wie den Logfiles und Administrationsverzeichnissen sowie weiteren Dingen vorgestellt, welche zum Testen der Sicherheit von Web-Anwendungen nützlich sein können.

FuzzDB ist ein Projekt von Adam Muntner, welcher seines Zeichens Application Security Engineer bei Mozilla ist. Vor drei Wochen erst hat Mozilla mit Minion ein Sicherheits-Test-Framework vorgestellt und eine Zusammenarbeit mit Blackberry angekündigt, um gemeinsam neue und innovative Werkzeuge zum Finden von Sicherheitslücken zu entwickeln.

Die Vorstellung von FuzzDB im Sicherheits-Blog von Mozilla ist der Anfang einer Reihe weiterer Artikel über FuzzDB. Details zu FuzzDB gibt es in der Vorstellung von FuzzDB im Mozilla Sicherheits-Blog.

 

Intern: Wie entsteht eigentlich ein Release-Artikel zu Firefox?

Die Release-Artikel zu Firefox auf diesem Blog sind die wohl umfassendsten im deutschsprachigen Raum, wahrscheinlich sogar darüber hinaus. Doch wie entstehen diese eigentlich? Wie viel Aufwand steckt dahinter? Mit diesem Artikel möchte ich einen kleinen Einblick hinter die Kulissen gewähren.

Normalerweise erscheinen auf diesem Blog immer kurz nach dem Eintritt einer Version in die Aurora-Phase ausführliche Artikel über die Neuerungen von Firefox. Derzeit gibt es leider Verzögerungen, was vor allem mit dem dahinter stehenden Aufwand zusammenhängt. Aus diesem Grund möchte ich einen Einblick in meine Arbeit geben.

Die Basis für meine Artikel bildet Mercurial, das von Mozilla verwendete Versionskontrollsystem. Jede Änderung am Mozilla-Code wird darüber eingecheckt, damit sind alle Änderungen online dokumentiert. Das für Firefox entscheidende Repository ist mozilla-central. Bei durchschnittlich mindestens zwei Seiten zu je 60 Changesets pro Tag ergeben sich daraus in einem Zeitraum von sechs Wochen mindestens 3500 Änderungen, wenn man von etwa zwei Dritteln als Zahl unterschiedlicher Bugs ausgeht. Auf diese Zahl komme ich auch in etwa, wenn ich die Anzahl der Bugzilla-Seiten in meiner Chronik für sechs Wochen zähle. Bei Bugzilla handelt es sich um den Bugtracker von Mozilla, die entsprechenden Bug-Nummern sind im Repository immer verlinkt.

Für jeden einzelnen dieser Artikel muss ich also eine vierstellige Anzahl an Änderungen durchgehen, was konkret heißt, die entsprechenden Bugs aufrufen, die Beschreibung überfliegen und bewerten, ob die Änderung relevant ist. Spoiler: Die meisten Änderungen sind absolut uninteressant für die Artikel, da es sich bei den meisten Änderungen um interne Änderungen handelt, Änderung bedeutet längst nicht gleich neues Feature. Erschwerend kommt hinzu, dass mozilla-central nicht nur die Änderungen von Firefox, sondern auch von Firefox Mobile und Firefox OS beinhaltet sowie der Gecko-Engine. Fun Fact: Die Informationen über die Neuerungen von Firefox Mobile entstehen damit quasi als Abfallprodukt aus der Recherche für den Desktop-Firefox. Was die Qualität dieser Artikel natürlich nicht schmälern soll, ganz im Gegenteil. Dadurch, dass diese Artikel denselben Prozess durchlaufen, stehen diese ihren Desktop-Pendants in nichts nach.

Was passiert nun, wenn ich eine Änderung als relevant befunden habe? Die Änderung wird inklusive Bug-Nummer in einem Textdokument festgehalten. Für die unterschiedlichen Produkte (Firefox, Firefox Mobile, Firefox OS, Firefox Metro, Thunderbird) existieren verschiedene Dokumente. In diesen Dokumenten werden alle notierten Änderungen außerdem einer Kategorie zugeordnet, so dass in den Artikeln später beisammen steht, was zusammen gehört. So werden Änderungen an der Benutzeroberfläche gruppiert oder Neuerungen an den Entwickler-Werkzeugen. Die Aufzählung verrät es, auch für den Metro-Firefox gibt es ein solches Dokument und sobald dieser offiziell verfügbar ist, wird es auf diesem Blog alle sechs Wochen auch noch separate Artikel zu den Neuerungen der Metro-Version geben. Für Thunderbird kommt außerdem noch ein weiteres Repository dazu, nämlich comm-central. Die Anzahl an Änderungen hält sich hier stark in Grenzen und beläuft sich im Schnitt auf weniger als eine Hand voll pro Tag, wobei man nicht vergessen darf, dass sich Thunderbird die selbe Plattform mit Firefox teilt und einige Dinge aus mozilla-central damit auch für Thunderbird relevant sind. Und um es nicht zu einfach zu machen, muss auch hier noch gefiltert werden, denn comm-central listet auch noch Änderungen für SeaMonkey und Lightning.

Ist dies abgeschlossen gehe ich diverse englischsprachige Blog-Artikel zu Neuerungen durch, welche ich mir in den sechs Wochen als Lesezeichen gespeichert habe. Manche davon helfen, Neuerungen zu verstehen, manche stellen Neuerungen auch einfach gut dar und helfen dabei, eine Idee vom zukünftigen Artikel zu erhalten.

Die nächste Phase ist es dann, alle notierten Änderungen zu testen. In meinen Release-Artikeln gibt es kein einziges Wort, welches nicht zuvor von mir überprüft worden ist. Für die Erstellung der Artikel bedeutet das, dass die neuste Version und die Vorgängerversion parallel gestartet werden und jede einzelne Änderung verifiziert wird. Was nicht bestätigt werden kann, fliegt aus dem Dokument. Dazu wird in dieser Phase noch einmal ein halbes bis ganzes Dutzend kleinerer Änderungen aus dem Dokument gestrichen, weil diese Änderungen in der Gesamtheit des Artikels als nicht mehr ganz so relevant befunden werden.

Dann erst geht es an das Formulieren des Artikels. Der geschriebene Text, der später tausende Leser erfreut, macht tatsächlich nur den allerkleinsten Teil der Arbeit aus. Sobald der Text geschrieben ist, folgt die Aufnahme und Einarbeitung von Screenshots. Das ist dann der Punkt, an welchem ich genervt bin und einfach nur noch veröffentlichen möchte. ;) Aber dies gehört dazu, genauso wie hinterher alles noch mindestens einmal, besser zweimal durchzulesen und Fehler zu korrigieren, dann den Artikel zu veröffentlichen und über die sozialen Kanäle zu verbreiten.

Wie lange dauert die Erstellung dieser Artikel also insgesamt? Das ist schwer pauschal zu beantworten, das ist unterschiedlich. Man kann aber festhalten, dass ein einziger dieser Artikel mindestens zwei komplette und unbezahlte (!) Arbeitstage, also mindestens 16 Stunden, dauert. Tendenz höher. Interner Tipp: Die richtige Musik dabei zu hören ist elementar wichtig!

Die berechtigte Frage ist natürlich: Wieso mache ich mir diese Arbeit? Wieso tippe ich nicht einfach ab, was in den Release Notes steht? Dann ist der Artikel in spätestens zwei Stunden geschrieben. Klar. Kann ich machen. Aber da denk ich mir dann, dass ich es gleich sein lassen kann. Von diesen Artikeln gibt es im Web bereits genug, da braucht es meine auch nicht mehr. Ich möchte mich auch in Zukunft qualitativ deutlich vom Rest abheben und wenn es dann zu solchen Verzögerungen wie aktuell kommt, weil mir das reale Leben nicht immer die Zeit lässt, die ich hierfür benötige, ist mir das immer noch lieber als an der Art meiner Artikel etwas zu ändern. Und ich hoffe, dass dies auch im Interesse meiner Leser ist, wenn sie auch manchmal etwas länger warten müssen, was mir Leid tut. Sollte jemand eine andere Meinung dazu haben, bin ich für einen Dialog in den Kommentaren natürlich offen. :)

Inhalt abgleichen