Chrome Dev Summit - Overzicht van open webplatforms

door Greg Simon en Eric Seidel

Blink is de open-source rendering-engine van Chrome. Het Blink-team ontwikkelt het internet en pakt de problemen aan die ontwikkelaars tegenkomen.

Sinds onze lancering in april zijn er achter de schermen een aantal verbeteringen doorgevoerd.

Het eerste wat we deden was de helft van onze bron verwijderen, wat we niet per se nodig hadden. We zijn nog steeds niet klaar! En we doen dit niet blind: het verwijderen van de code is gebaseerd op anoniem gerapporteerde verzamelde statistieken van Chrome-gebruikers die zich hebben aangemeld voor rapportage.

We publiceren elke zes weken een nieuwe ontwikkelaars-API: hetzelfde als het verzendschema van Chrome.

Een grote verandering die we hebben doorgevoerd toen we van Blink afstapten, was het toevoegen van een intentiesysteem: elke keer voordat we het webplatform gaan veranderen, sturen we een openbare aankondiging naar Blink-ontwikkelaar waarin we onze intentie aankondigen om een ​​functie toe te voegen of te verwijderen. Dan gaan we op pad en coderen we het! En de volgende dag nadat de functie is ingecheckt, wordt deze al verzonden in onze Canary-builds. Deze functie is standaard uitgeschakeld, maar u kunt deze inschakelen met about:flags.

Vervolgens kondigen we op onze openbare mailinglijst aan dat we van plan zijn om te verzenden .

Op chromestatus.com kunt u de functies zien waaraan we hebben gewerkt, de functies die we hebben uitgebracht en de functies die we van plan zijn te beëindigen. Je kunt ook de Chromium Releases-blog raadplegen, die links naar bugs en naar ons tracker-dashboard bevat.

Een andere grote verandering is dat we WebKit-voorvoegsels verwijderen. De bedoeling is niet om Blink-voorvoegsels te gebruiken, maar om runtime-vlaggen te hebben (en niet alleen compile-time-vlaggen).

Android WebView was een grote uitdaging, maar HTML5Test laat zien dat de zaken steeds beter worden. We staan ​​veel dichter bij de desktop als het gaat om het feit dat we overal één set webplatform-API's hebben (webaudio is hier een goed voorbeeld van!)

Maar hoe werkt de worstmachine? Elke wijziging die we in Blink aanbrengen, wordt onmiddellijk aan meer dan 30.000 tests onderworpen, om nog maar te zwijgen van alle Chromium-tests die later worden uitgevoerd. We gebruiken 24-uurs sheriffing, met duizenden bots, duizenden benchmarks en systemen die miljoenen kapotte webpagina's naar onze engine gooien om ervoor te zorgen dat deze niet omvalt. We weten dat mobiel aanzienlijk langzamer is, en dit is iets waar we hard aan werken om dit te verbeteren.

Dus, wat is er nieuw?

  • Webcomponenten : bekijk de lezing van Eric Bidelman!
  • Webanimaties: complexe, gesynchroniseerde, hoogwaardige animaties die waar mogelijk gebruik maken van de GPU
  • Gedeeltelijke indeling: bereken alleen wat u nodig heeft!
  • CSS-raster
  • Responsieve afbeeldingen: srcset of srcN of ?
  • Snellere automatische aanpassing van tekst en consistente subpixellettertypen
  • Skia, het grafische systeem dat door Blink wordt gebruikt, stapt over van GDI naar DirectWrite op Windows

Wij willen weten wat u te zeggen heeft!

Als je C++ in je bloed voelt en met ons C++ wilt schrijven, staat al onze code open. U hoeft het aan niemand te vertellen of tegen ons te evangeliseren. U kunt eenvoudigweg een patch posten of een bug indienen !

Dia's: Knipperen

Beveiliging

van Parisa Tabriz

Tegenwoordig zijn meer mensen verbonden met internet dan ooit tevoren – en vanaf meer plaatsen.

We zijn verbonden met onze laptops, telefoons en tablets, en waarschijnlijk binnenkort ook met persoonlijke apparaten en accessoires. We hebben toegang tot internet via onbetrouwbare en soms zelfs vijandige netwerken. Omdat een groot deel van ons leven zich online afspeelt, is het absoluut noodzakelijk dat we stappen ondernemen om onze gegevens en de gegevens van onze gebruikers te beschermen.

Bovenal moeten we als ontwikkelaars de noodzaak en bruikbaarheid van SSL begrijpen.

Wat is SSL? Het staat voor Secure Sockets Layer en is een cryptografisch protocol dat is ontworpen om communicatiebeveiliging via internet te bieden. Het garandeert privacy, via encryptie en integriteit, om snuffelen of knoeien met uw internetverbinding te voorkomen. SSL heeft zijn gebreken, maar het is de leidende manier – en eigenlijk de enige manier – om elke vorm van beveiliging van datacommunicatie op internet te garanderen.

Volgens SSL Pulse hadden we een jaar geleden ongeveer 15% van de SSL-acceptatie; we hebben nu meer dan 50% adoptie.

Twee acroniemen:

  • TLS: voor de meeste doeleinden hetzelfde als SSL. Om precies te zijn, SSL 3.1 is hernoemd naar TLS en TLS is de IETF-standaardnaam. Maar ze zijn uitwisselbaar!

  • HTTPS: dit is HTTP over SSL, slechts de gelaagdheid van de beveiligingsmogelijkheden van SSL en standaard HTTP. Ten eerste de client-server-handshake, waarbij gebruik wordt gemaakt van cryptografie met publieke/private sleutels om een ​​gedeelde sleutel te creëren – die door het tweede deel van het SSL-protocol wordt gebruikt om de communicatie te coderen.

Netwerken op internet kan veilig, direct en snel aanvoelen. Het voelt alsof we rechtstreeks tegen de website praten. Maar in werkelijkheid is het geen directe verbinding. Onze communicatie verloopt via een wifi-router, een ISP en mogelijk andere tussenliggende proxy's tussen uw apparaat en de website. Zonder HTTPS is al onze communicatie in platte tekst.

Het probleem is dat gebruikers zelden een volledige URL intypen waarin HTTPS wordt gespecificeerd – of dat ze op een link klikken via HTTP. Erger nog, het is mogelijk om een ​​(wo)man-in-the-middle-aanval uit te voeren en HTTPS te vervangen door HTTP. Een tool genaamd SSLstrip, geïntroduceerd in 2009, doet precies dat. Firesheep uit 2010 luisterde alleen naar geopende wifi-netwerken voor cookies die in het openbaar werden verzonden: dat betekende dat je kon meeluisteren tijdens de chat of kon inloggen op iemands Facebook-account.

Maar SSL is (relatief) goedkoop, snel en gemakkelijk te implementeren (zie ssllabs.com en het boek High Performance Browser Networking van Ilya Grigorik). Public Key Pinning is ontworpen om website-exploitanten een middel te geven om te beperken welke certificeringsinstanties daadwerkelijk certificaten voor hun sites kunnen uitgeven.

"In januari van dit jaar (2010) schakelde Gmail standaard over op het gebruik van HTTPS voor alles. Om dit te doen hoefden we geen extra machines en geen speciale hardware in te zetten. Op onze productiefrontendmachines is SSL verantwoordelijk voor < 1% van de CPU-belasting, < 10 KB geheugen per verbinding en < 2% van de netwerkoverhead...

Als je nu stopt met lezen, hoef je maar één ding te onthouden: SSL is rekenkundig gezien niet meer duur.”

SSL overklokken , Adam Langley (Google)

Tenslotte nog een aantal bugs die we het meest tegenkomen:

  • Gemengde inhoud: sites die zowel HTTP als HTTPS gebruiken. Uw gebruiker zal geïrriteerd raken omdat hij op een toestemmingsknop moet klikken om inhoud te laden. (Chrome en Firefox blokkeren feitelijk gemengde inhoud van iframes.) Zorg ervoor dat al uw bronnen op een HTTPS-pagina worden geladen via HTTPS, door relatieve of schema-relatieve URL's te gebruiken, bijvoorbeeld <style src="//foo.com/style.css">
  • Onveilige cookies: verzonden via een HTTP-verbinding. Vermijd dit door het secure attribuut in te stellen op cookieheaders. U kunt ook een nieuwe header 'Strict Transport Security' gebruiken om SSL Transport Security (HSTS) te vereisen.

Afhaalrestaurants

  • Als u de privacy en integriteit van de gegevens van uw gebruikers belangrijk vindt, moet u SSL gebruiken. Het is sneller, eenvoudiger en goedkoper dan ooit.
  • Vermijd veelvoorkomende implementatieproblemen, zoals bugs met gemengde inhoud of het niet instellen van de juiste HTTP-headerbits.
  • Gebruik relatieve of schematische relatieve URL's.
  • Bekijk enkele van de nieuwe coole dingen, zoals HSTS en cert pinning

Dia's: SSL ontvangen?

Media-API's voor het web met meerdere apparaten

door Sam Dutton en Jan Linden

Samen met een toename van nieuwe apparaten en platforms op internet zien we een enorme groei in audio, video en realtime communicatie. Online media transformeren de manier waarop we allerlei soorten media consumeren.

Uit een onderzoek van de Britse overheid is gebleken dat 53% van de volwassenen tijdens het tv-kijken aan 'mediamultitasken' doet: mobiele apparaten gebruiken om media te delen en te consumeren. In veel landen is het tv-kijken afgenomen en het online kijken gestegen. In China keek in 2012 bijvoorbeeld slechts 30% van de huishoudens in Peking tv, tegen 70% in 2009. Volgens de W3C Highlights 2013 : 'Het afgelopen jaar is het kijken naar video's op mobiele apparaten verdubbeld . Dit jaar zal in de VS de gemiddelde tijd die per dag aan digitale media wordt besteed, het tv-kijken overtreffen . Kijken is niet langer een passieve handeling. In de VS zegt 87% van de entertainmentconsumenten dat ze ten minste één tweede schermapparaat gebruiken tijdens het televisiekijken.' Volgens Cisco 'zal video... in 2017 80 tot 90 procent van het wereldwijde consumentenverkeer uitmaken'. Dat komt neer op bijna een miljoen minuten video per seconde.

Dus wat hebben we voor webontwikkelaars? Een ecosysteem van media-API's voor het open web: gestandaardiseerde, interoperabele technologieën die op meerdere platforms werken.

Afhaalrestaurants

  • WebRTC biedt realtime communicatie in de browser en wordt nu breed ondersteund op mobiel en desktop. In totaal zijn er al ruim 1,2 miljard WebRTC-eindpunten.
  • Web Audio biedt geavanceerde tools voor audiosynthese en -verwerking.
  • Web MIDI, geïntegreerd met Web Audio, maakt interactie met MIDI-apparaten mogelijk.
  • De audio- en video-elementen worden nu ondersteund door meer dan 85% van de mobiele en desktopbrowsers .
  • Mediabronextensies kunnen worden gebruikt voor adaptieve streaming en timeshifting.
  • EME maakt het afspelen van beveiligde inhoud mogelijk.
  • Transcripties, bijschriften en het trackelement maken ondertitels, bijschriften, getimede metadata, deep links en deep search mogelijk.

Dia's: Media-API's voor het web met meerdere apparaten