Blink
di Greg Simon e Eric Seidel
Blink è il motore di rendering open source di Chrome. Il team di Blink sta migliorando il web e risolvendo i problemi riscontrati dagli sviluppatori.
Dal lancio di aprile, sono stati apportati diversi miglioramenti al dietro le quinte.
Per prima cosa abbiamo eliminato metà del codice sorgente, cosa di cui non avevamo necessariamente bisogno. Non abbiamo ancora finito. E non lo facciamo così: la rimozione del codice si basa su statistiche aggregate riportate in forma anonima degli utenti di Chrome che attivano la segnalazione.
Pubblichiamo una nuova API per sviluppatori ogni sei settimane, uguale alla pianificazione di spedizione di Chrome.
Un grande cambiamento che abbiamo apportato quando abbiamo creato il fork da Blink è stato l'aggiunta di un sistema di intent: ogni volta, prima di cambiare la piattaforma web, inviamo un annuncio pubblico a Blink dev per annunciare la nostra intenzione di aggiungere o rimuovere una funzionalità. Poi interrompiamo la programmazione, Il giorno successivo al controllo della funzionalità, è già disponibile la spedizione nelle nostre build canary. Questa funzionalità è disattivata per impostazione predefinita, ma puoi attivarla utilizzando about:flags.
Successivamente, sulla nostra mailing list pubblica annunciamo l'intenzione di spedire.
Su chromestatus.com puoi vedere le funzionalità a cui abbiamo lavorato, quelle che abbiamo fornito e quelle che abbiamo in programma di ritirare. Puoi anche consultare il blog Chromium Releases, che contiene link ai bug e alla nostra dashboard di tracker.
Un altro grande cambiamento è che stiamo rimuovendo i prefissi WebKit. L'intento non è quello di utilizzare prefissi Blink, ma di avere flag di runtime (e non solo flag di fase di compilazione).
Android WebView è stata una sfida impegnativa, ma HTML5Test mostra che le cose stanno migliorando. Siamo molto più vicini al desktop in termini di avere un set di API delle piattaforme web ovunque (l'audio web ne è un ottimo esempio!)
Ma come funziona la macchina per la salsiccia? Ogni singola modifica che apportiamo a Blink viene immediatamente sottoposta a oltre 30.000 test, per non parlare di tutti i test di Chromium che verranno eseguiti in seguito. Utilizziamo lo sceriffo 24 ore su 24, con migliaia di bot, migliaia di benchmark e sistemi che lanciano milioni di pagine web non funzionanti nel nostro motore per evitare che cadano. Sappiamo che i dispositivi mobili sono molto più lenti e che stiamo lavorando per migliorare questo aspetto.
Quali sono le novità?
- Componenti web: date un'occhiata alla presentazione di Eric Bidelman.
- Animazioni web: animazioni web complesse, sincronizzate e ad alte prestazioni che utilizzano la GPU quando possibile
- Layout parziale: calcola solo ciò che ti serve.
- Griglia CSS
- Immagini adattabili:
- Ridimensionamento automatico del testo più veloce e caratteri di pixel secondari coerenti
- Skia, il sistema grafico usato da Blink, passerà da GDI a DirectWrite su Windows
Vogliamo sapere cosa hai da dire.
Se senti C++ nel tuo sangue e vuoi scrivere C++ con noi, tutto il nostro codice è aperto. Non devi dirlo a nessuno o promuovere la tua conoscenza. Puoi semplicemente pubblicare una patch o segnalare un bug.
Presentazioni: Blink
Sicurezza
di Parisa Tabriz
Oggi più persone che mai si connettono al Web e da più posti.
Siamo collegati ai nostri laptop, telefoni e tablet e probabilmente abbastanza presto con dispositivi personali e accessori. Accediamo a internet da reti non attendibili e a volte anche ostili. Dato che gran parte delle nostre vite si sposta online, è imperativo adottare misure per proteggere i nostri dati e e i dati di Google Cloud.
Ma soprattutto, in quanto sviluppatori dobbiamo capire la necessità e la praticità di SSL.
Che cos'è SSL? Secure Sockets Layer (Secure Sockets Layer) ed è un protocollo crittografico progettato per garantire la sicurezza della comunicazione su internet. Garantisce la privacy, tramite crittografia e integrità, per impedire snooping o manomissioni della connessione a internet. SSL presenta i suoi difetti, ma è il metodo principale (e davvero l'unico) per garantire qualsiasi tipo di sicurezza delle comunicazioni dei dati su internet.
Secondo SSL Pulse, un anno fa abbiamo adottato circa il 15% di SSL; abbiamo superato il 50% dell'adozione.
Due acronimi:
TLS: per la maggior parte degli intent e degli scopi è uguale a quello di SSL. Per essere precisi, SSL 3.1 è stato rinominato TLS e TLS è il nome dello standard IETF. Ma sono intercambiabili!
HTTPS:si tratta di HTTP su SSL, è solo il livello delle funzionalità di sicurezza di SSL e HTTP standard. Innanzitutto, l'handshake client-server utilizza la crittografia a chiave pubblica/privata per creare una chiave condivisa, che viene utilizzata dalla seconda parte del protocollo SSL per criptare le comunicazioni.
La connessione su internet può risultare sicura, immediata e veloce. Abbiamo l'impressione di parlare direttamente con il sito web. Ma in realtà non si tratta di un collegamento diretto. Le nostre comunicazioni passano tramite un router Wi-Fi, un ISP e potenzialmente altri proxy intermedi tra il dispositivo e il sito web. Senza HTTPS, tutte le nostre comunicazioni sono in testo normale.
Il problema è che gli utenti raramente digitano un URL completo che specifica HTTPS oppure fanno clic su un link utilizzando HTTP. Peggio ancora, è possibile montare un attacco man in the middle e sostituire HTTPS con HTTP. Uno strumento chiamato SSLstrip introdotto nel 2009 proprio per questo. Firesheep, del 2010, ha appena ascoltato le reti Wi-Fi aperte per l'invio dei cookie in chiaro: questo significava che potevi ascoltare la chat o accedere all'account Facebook di qualcuno.
SSL è invece (relativamente) economico, veloce e facile da implementare (dai un'occhiata al sito ssllabs.com e al libro di Ilya Grigorik High Performance Browser Networking). Il blocco della chiave pubblica è progettato per offrire agli operatori dei siti web un mezzo per limitare le autorità di certificazione che possono effettivamente emettere certificati per i loro siti.
"A gennaio di quest'anno 2010, Gmail è passato a utilizzare HTTPS per tutto per impostazione predefinita. Per farlo abbiamo dovuto eseguire il deployment di nessun'altra macchina né di hardware speciale. Sulle nostre macchine frontend di produzione, il protocollo SSL < 1% del carico della CPU, < 10 kB di memoria per connessione e < 2% di overhead di rete...
Se smetti di leggere ora devi solo ricordare una cosa: SSL non è più costoso dal punto di vista del computing."
– Overclock SSL, Adam Langley (Google)
Infine, ecco un paio di bug che vediamo più di frequente:
- Contenuto misto: siti che utilizzano sia HTTP sia HTTPS. L'utente si infastidisce perché deve fare clic su un pulsante di autorizzazione per caricare i contenuti. Chrome e Firefox in realtà impediscono i contenuti misti dagli iframe. Assicurati che tutte le risorse su una pagina HTTPS siano caricate tramite HTTPS, utilizzando URL relativi o relativi allo schema, ad esempio
<style src="//foo.com/style.css">
. - Cookie non sicuri:inviati in chiaro tramite una connessione HTTP. Per evitare questo problema, imposta l'attributo secure sulle intestazioni dei cookie. Puoi anche utilizzare un nuovo criterio "Strict Transport Security" per richiedere SSL HSTS (Transport Security).
Concetti principali
- Se ti interessa la privacy e l'integrità dei tuoi utenti devi utilizzare SSL. È più veloce, più facile e più economico che mai.
- Evita di usare tecniche di implementazione comuni, come bug di contenuti misti o di non impostare i bit di intestazione HTTP corretti.
- Utilizza URL relativi o relativi allo schema.
- Dai un'occhiata ad alcune delle novità più interessanti, come HSTS e il blocco dei certificati
Presentazioni: SSL?
API multimediali per il web multi-dispositivo
di Sam Dutton e Jan Linden
Insieme alla proliferazione di nuovi dispositivi e piattaforme sul web, stiamo assistendo a una crescita enorme per quanto riguarda audio, video e comunicazioni in tempo reale. I media online stanno trasformando il modo in cui usiamo contenuti multimediali di ogni tipo.
Uno studio del governo del Regno Unito ha rilevato che il 53% degli adulti utilizza il "multi-tasking multimediale" mentre si guarda la TV: usa i dispositivi mobili per condividere e fruire di contenuti multimediali. In molti paesi le visualizzazioni TV sono diminuite, mentre quelle online sono aumentate. In Cina, ad esempio, nel 2012 solo il 30% dei nuclei familiari a Pechino guardava la TV, in calo rispetto al 70% del 2009. Secondo W3C Highlights 2013, "Lo scorso anno la visione di video su dispositivi mobili è raddoppiata. Quest'anno, negli Stati Uniti, il tempo medio giornaliero trascorso sui media digitali supererà le visualizzazioni della TV. La visualizzazione non è più un atto passivo. Negli Stati Uniti, l'87% dei consumatori dell'intrattenimento afferma di utilizzare almeno un secondo schermo mentre guarda la televisione. Secondo Cisco, "i video ..." rientrano tra l'80 e il 90% del traffico globale dei consumatori entro il 2017. Ciò equivale a quasi un milione di minuti di video al secondo.
Quali sono le informazioni a disposizione degli sviluppatori web? Un ecosistema di API multimediali per il web aperto: tecnologie standardizzate e interoperabili che funzionano su più piattaforme.
Concetti principali
- WebRTC, che fornisce comunicazione in tempo reale nel browser, ed è ora ampiamente supportato su dispositivi mobili e computer. In totale esistono già oltre 1,2 miliardi di endpoint WebRTC.
- Audio web fornisce strumenti sofisticati per la sintesi e l'elaborazione audio.
- Web MIDI, integrato con Web Audio, consente l'interazione con i dispositivi MIDI.
- Gli elementi audio e video sono ora supportati su più dell'85% dei browser mobile e desktop.
- È possibile usare le Media Source Extensions per lo streaming adattivo e il timeshift.
- La funzionalità EME consente la riproduzione di contenuti protetti.
- Le trascrizioni, i sottotitoli codificati e l'elemento traccia consentono di attivare sottotitoli, sottotitoli codificati, metadati sincronizzati, link diretti e ricerca diretta.
Presentazioni: API multimediali per il web multi-dispositivo