Chrome Dev Summit – Zusammenfassung der offenen Webplattform

von Greg Simon und Eric Seidel

Blink ist die Open-Source-Rendering-Engine von Chrome. Das Blink-Team entwickelt das Web weiter und behebt die Probleme, auf die Entwickler stoßen.

Seit der Einführung im April haben wir einige Verbesserungen im Hintergrund vorgenommen.

Als Erstes haben wir die Hälfte unseres Quellcodes gelöscht, die wir nicht unbedingt benötigten. Wir sind noch nicht fertig! Wir gehen dabei nicht blind vor: Das Entfernen von Code basiert auf anonym gemeldeten aggregierten Statistiken von Chrome-Nutzern, die die Berichterstellung aktiviert haben.

Wir veröffentlichen alle sechs Wochen eine neue Entwickler-API, also im selben Rhythmus wie Chrome.

Eine wichtige Änderung, die wir beim Forking von Blink vorgenommen haben, war das Hinzufügen eines Intent-Systems: Jedes Mal, wenn wir die Webplattform ändern möchten, senden wir eine öffentliche Ankündigung an Blink dev, in der wir unsere Absicht, eine Funktion hinzuzufügen oder zu entfernen, bekannt geben. Dann machen wir uns an die Programmierung. Und am nächsten Tag nach dem Einchecken der Funktion ist sie bereits in unseren Canary-Builds verfügbar. Diese Funktion ist standardmäßig deaktiviert, kann aber über „about:flags“ aktiviert werden.

Anschließend kündigen wir auf unserer öffentlichen Mailingliste eine Absicht zur Auslieferung an.

Auf chromestatus.com finden Sie die Funktionen, an denen wir gearbeitet haben, die Funktionen, die wir eingeführt haben, und die Funktionen, die wir einstellen möchten. Im Chromium Releases-Blog finden Sie außerdem Links zu Fehlern und zu unserem Tracker-Dashboard.

Eine weitere große Änderung ist, dass wir WebKit-Präfixe entfernen. Es ist nicht beabsichtigt, Blink-Präfixe zu verwenden, sondern Laufzeit-Flags (und nicht nur Kompilierzeit-Flags).

Android WebView war eine große Herausforderung, aber HTML5Test zeigt, dass sich die Situation verbessert. Wir sind dem Desktop viel näher, was die Verfügbarkeit eines Satzes von Webplattform-APIs überall angeht (Web Audio ist ein gutes Beispiel dafür).

Aber wie funktioniert die Wurstmaschine? Jede einzelne Änderung, die wir an Blink vornehmen, wird sofort in über 30.000 Tests geprüft. Hinzu kommen alle Chromium-Tests, die später zusätzlich ausgeführt werden. Wir verwenden ein 24-Stunden-Sheriffing mit Tausenden von Bots, Tausenden von Benchmarks und Systemen, die Millionen von defekten Webseiten an unsere Engine senden, um sicherzustellen, dass sie nicht abstürzt. Wir wissen, dass die mobile Version deutlich langsamer ist, und arbeiten mit Hochdruck daran, das zu verbessern.

Was ist neu?

  • Webkomponenten: Sehen Sie sich den Vortrag von Eric Bidelman an.
  • Web-Animationen:komplexe, synchronisierte, leistungsstarke Animationen, bei denen die GPU nach Möglichkeit verwendet wird
  • Teillayout:Berechnen Sie nur das, was Sie benötigen.
  • CSS Grid
  • Responsive Bilder: srcset oder srcN oder ?
  • Schnellere automatische Anpassung der Textgröße und einheitliche Subpixel-Schriftarten
  • Skia, das von Blink verwendete Grafiksystem, wird unter Windows von GDI auf DirectWrite umgestellt.

Wir möchten wissen, was du zu sagen hast.

Wenn Sie C++ im Blut haben und mit uns C++ schreiben möchten, ist unser gesamter Code offen. Sie müssen niemandem etwas erzählen oder uns überzeugen. Sie können einfach einen Patch posten oder einen Fehler melden.

Präsentationen:Blink

Sicherheit

von Parisa Tabriz

Noch nie waren so viele Menschen mit dem Internet verbunden wie heute – und das von mehr Orten aus.

Wir sind mit unseren Laptops, Smartphones und Tablets verbunden und wahrscheinlich bald auch mit persönlichen Geräten und Zubehör. Wir greifen über nicht vertrauenswürdige und manchmal sogar feindselige Netzwerke auf das Internet zu. Da so vieles in unserem Leben online stattfindet, ist es unerlässlich, dass wir Maßnahmen ergreifen, um unsere Daten und die Daten unserer Nutzer zu schützen.

Vor allem als Entwickler müssen wir die Notwendigkeit und Praktikabilität von SSL verstehen.

Was ist SSL? Die Abkürzung steht für Secure Sockets Layer. Es handelt sich um ein kryptografisches Protokoll, das für eine sichere Kommunikation über das Internet entwickelt wurde. Es bietet Datenschutz durch Verschlüsselung und Integrität, um zu verhindern, dass Ihre Internetverbindung ausspioniert oder manipuliert wird. SSL hat seine Schwächen, ist aber die führende und eigentlich einzige Möglichkeit, die Sicherheit der Datenkommunikation im Internet zu gewährleisten.

Laut SSL Pulse lag die SSL-Akzeptanz vor einem Jahr bei knapp 15 %. Mittlerweile liegt sie bei über 50 %.

Zwei Akronyme:

  • TLS:Im Wesentlichen dasselbe wie SSL. Genauer gesagt wurde SSL 3.1 in TLS umbenannt und TLS ist der IETF-Standardname. Sie sind aber austauschbar.

  • HTTPS:Dies ist HTTP über SSL, also die Kombination der Sicherheitsfunktionen von SSL und Standard-HTTP. Zuerst erfolgt der Client-Server-Handshake, bei dem mithilfe der Public/Private-Key-Kryptografie ein gemeinsamer Schlüssel erstellt wird, der im zweiten Teil des SSL-Protokolls zur Verschlüsselung der Kommunikation verwendet wird.

Die Vernetzung im Internet kann sich sicher, unmittelbar und schnell anfühlen. Es fühlt sich an, als würden wir direkt mit der Website sprechen. In der Realität ist es aber keine direkte Verbindung. Unsere Kommunikation erfolgt über einen WLAN-Router, einen Internetanbieter und möglicherweise andere Vermittlungsproxy-Server zwischen Ihrem Gerät und der Website. Ohne HTTPS erfolgt die gesamte Kommunikation als Nur-Text.

Das Problem ist, dass Nutzer selten eine vollständige URL mit HTTPS eingeben oder auf einen Link mit HTTP klicken. Schlimmer noch: Es ist möglich, einen Man-in-the-Middle-Angriff zu starten und HTTPS durch HTTP zu ersetzen. Ein 2009 eingeführtes Tool namens SSLstrip macht genau das. Firesheep aus dem Jahr 2010 hat nur auf offene WLAN-Netzwerke geachtet, in denen Cookies im Klartext gesendet wurden. Das bedeutete, dass man Chats mitlesen oder sich im Facebook-Konto einer anderen Person anmelden konnte.

SSL ist jedoch (relativ) kostengünstig, schnell und einfach bereitzustellen (siehe ssllabs.com und das Buch „High Performance Browser Networking“ von Ilya Grigorik). Public Key Pinning soll Websitebetreibern die Möglichkeit geben, einzuschränken, welche Zertifizierungsstellen Zertifikate für ihre Websites ausstellen dürfen.

„Im Januar dieses Jahres (2010) wurde in Gmail standardmäßig auf HTTPS umgestellt. Dazu mussten wir keine zusätzlichen Maschinen und keine spezielle Hardware bereitstellen. Auf unseren Produktions-Frontend-Maschinen macht SSL weniger als 1% der CPU-Last, weniger als 10 KB Arbeitsspeicher pro Verbindung und weniger als 2% des Netzwerk-Overheads aus…

Wenn Sie jetzt aufhören zu lesen, müssen Sie sich nur eines merken: SSL ist nicht mehr rechenintensiv.“

Overclocking SSL, Adam Langley (Google)

Zum Schluss noch einige der häufigsten Fehler:

  • Gemischte Inhalte:Websites, auf denen sowohl HTTP als auch HTTPS verwendet wird. Nutzer sind genervt, wenn sie auf eine Berechtigungsschaltfläche klicken müssen, um Inhalte zu laden. (In Chrome und Firefox werden gemischte Inhalte in iFrames tatsächlich blockiert.) Achten Sie darauf, dass alle Ressourcen auf einer HTTPS-Seite über HTTPS geladen werden. Verwenden Sie dazu beispielsweise relative oder schemarelative URLs: <style src="//foo.com/style.css">
  • Unsichere Cookies:Sie werden unverschlüsselt über eine HTTP-Verbindung gesendet. Sie können dies verhindern, indem Sie das Attribut „secure“ für Cookie-Header festlegen. Sie können auch einen neuen „Strict Transport Security“-Header verwenden, um HSTS (HTTP Strict Transport Security) zu erzwingen.

Fazit

  • Wenn Ihnen der Schutz und die Integrität der Daten Ihrer Nutzer wichtig sind, müssen Sie SSL verwenden. Es ist schneller, einfacher und günstiger als je zuvor.
  • Vermeiden Sie häufige Implementierungsfehler wie Fehler bei gemischten Inhalten oder das Nichtfestlegen der richtigen HTTP-Header-Bits.
  • Verwenden Sie relative oder schemarelative URLs.
  • Sehen Sie sich einige der neuen coolen Funktionen an, z. B. HSTS und Cert Pinning.

Folien:SSL-Zertifikat vorhanden?

Media APIs für das Web auf mehreren Geräten

von Sam Dutton und Jan Linden

Neben der Zunahme neuer Geräte und Plattformen im Web verzeichnen wir ein enormes Wachstum bei Audio-, Video- und Echtzeitkommunikation. Online-Medien verändern die Art und Weise, wie wir Medien aller Art konsumieren.

Laut einer Studie der britischen Regierung nutzen 53% der Erwachsenen beim Fernsehen mehrere Geräte gleichzeitig, um Medien zu teilen und zu konsumieren. In vielen Ländern ist die Nutzung des Fernsehens rückläufig, während die Online-Nutzung zunimmt. In China beispielsweise sahen sich 2012 nur 30% der Haushalte in Peking das Fernsehen an, verglichen mit 70% im Jahr 2009. Laut W3C Highlights 2013 hat sich die Anzahl der Videoaufrufe auf Mobilgeräten im letzten Jahr verdoppelt. In diesem Jahr wird in den USA die durchschnittliche Zeit, die täglich mit digitalen Medien verbracht wird, die Zeit, die mit Fernsehen verbracht wird, übertreffen. Das Ansehen von Inhalten ist nicht mehr nur eine passive Tätigkeit. In den USA geben 87% der Unterhaltungskonsumenten an, dass sie beim Fernsehen mindestens ein Zweitgerät verwenden.“ Laut Cisco wird „Video … bis 2017 zwischen 80 und 90 % des globalen Datenverkehrs von Verbrauchern ausmachen“. Das entspricht fast einer Million Minuten Video pro Sekunde.

Was haben wir also für Webentwickler? Ein Ökosystem von Media-APIs für das offene Web: standardisierte, interoperable Technologien, die auf mehreren Plattformen funktionieren.

Fazit

  • WebRTC ermöglicht die Kommunikation in Echtzeit im Browser und wird mittlerweile auf Mobilgeräten und Computern weitgehend unterstützt. Insgesamt gibt es bereits über 1,2 Milliarden WebRTC-Endpunkte.
  • Web Audio bietet ausgefeilte Tools für die Audiosynthese und -verarbeitung.
  • Web MIDI ist in Web Audio integriert und ermöglicht die Interaktion mit MIDI-Geräten.
  • Die Audio- und Videoelemente werden jetzt von mehr als 85% der mobilen Browser und Desktopbrowser unterstützt.
  • Media Source Extensions können für adaptives Streaming und Time-Shifting verwendet werden.
  • EME ermöglicht die Wiedergabe geschützter Inhalte.
  • Transkripte, Untertitel und das track-Element ermöglichen Untertitel, Bildunterschriften, zeitgesteuerte Metadaten, Deeplinking und die Deep Search.

Präsentationen:Media APIs for the multi-device Web