Blink
de Greg Simon e Eric Seidel
O Blink é o mecanismo de renderização de código aberto do Chrome. A equipe do Blink está desenvolvendo a Web e resolvendo os problemas encontrados pelos desenvolvedores.
Tivemos diversas melhorias nos bastidores desde o lançamento em abril.
A primeira coisa que fizemos foi excluir metade da nossa fonte, que não era necessariamente necessário. Ainda não terminamos! E não estamos fazendo isso às cegas: a remoção do código é baseada em estatísticas agregadas anonimamente relatadas de usuários do Chrome que optaram por receber relatórios.
Publicamos uma nova API para desenvolvedores a cada seis semanas: a mesma programação de envios do Chrome.
Uma grande mudança que fizemos na bifurcação do Blink foi a adição de um sistema de intents: antes de mudar a plataforma da Web, enviamos um anúncio público para o Blink Dev anunciando nossa intenção de adicionar ou remover um recurso. Depois partemos e codificamos! No dia seguinte após a verificação do recurso, ele já estará disponível nas versões Canary. Esse recurso fica desativado por padrão, mas é possível ativá-lo usando about:flags.
Em seguida, em nossa lista de e-mails pública, anunciamos uma intenção de envio.
Em chromestatus.com, você encontra os recursos em que trabalhamos, os que enviamos e aqueles que planejamos suspender o uso. Também é possível acessar o blog de versões do Chromium, que tem links para bugs e para o nosso painel de rastreamento.
Outra grande mudança é a remoção dos prefixos do WebKit. A intenção não é usar prefixos do Blink, mas ter sinalizações no momento da execução (e não apenas flags de tempo de compilação).
O Android WebView tem sido um grande desafio, mas o HTML5Test mostra que as coisas estão melhorando. Estamos muito mais próximos do desktop em termos de ter um conjunto de APIs de plataforma da Web em todos os lugares (o Web Audio é um ótimo exemplo disso).
Mas como funciona a máquina de salsicha? Todas as mudanças feitas no Blink passam imediatamente por mais de 30.000 testes, sem contar os testes do Chromium que serão executados mais tarde. Usamos xerife 24 horas, com milhares de bots, milhares de comparativos de mercado e sistemas que lançam milhões de páginas da Web quebradas em nosso mecanismo para garantir que elas não caiam. Sabemos que o uso de dispositivos móveis é significativamente mais lento e isso é algo que estamos trabalhando duro para melhorar.
O que há de novo?
- Web Components: confira a palestra de Eric Bidelman.
- Animações da Web:animações complexas, sincronizadas e de alto desempenho que usam a GPU sempre que possível.
- Layout parcial:calcule apenas o que você precisa.
- Grade CSS
- Imagens responsivas:
srcset ou srcN ou ? - Texto com dimensionamento automático mais rápido e fontes consistentes de subpixels
- O Skia, o sistema gráfico usado pelo Blink, está mudando do GDI para o DirectWrite no Windows.
Queremos saber o que você tem a dizer.
Se você sente o C++ no sangue e quer escrever em C++ com a gente, todo o nosso código está aberto. Você não precisa contar a ninguém nem falar conosco. Basta postar um patch ou registrar um bug.
Apresentações:Blink
Segurança
de Parisa Tabriz
Cada vez mais pessoas estão conectadas à Web e em mais lugares.
Estamos conectados com nossos laptops, smartphones e tablets e, provavelmente, em breve, também com dispositivos pessoais e acessórios. Nós acessamos a Internet de redes não confiáveis e, às vezes, até hostis. Com grande parte das nossas vidas on-line, é fundamental tomar medidas para proteger nossos dados e os de usuários.
Acima de tudo, como desenvolvedores, precisamos entender a necessidade e a praticidade do SSL.
O que é SSL? A sigla em inglês significa "Secure Sockets Layer" e é um protocolo criptográfico projetado para fornecer segurança de comunicação na Internet. Ele garante a privacidade, usando criptografia e integridade, para evitar espionagem ou adulteração da sua conexão de Internet. O SSL tem suas falhas, mas é o principal, e realmente a única maneira, de garantir qualquer tipo de segurança de comunicação de dados na Internet.
De acordo com a SSL Pulse, há um ano, tínhamos pouco menos de 15% de adoção do SSL. Agora, estamos com mais de 50% de adoção.
Duas siglas:
TLS:para a maioria das intents e finalidades, é o mesmo que SSL. O SSL 3.1 foi renomeado como TLS, e TLS é o nome padrão IETF. Mas eles são intercambiáveis!
HTTPS: trata de HTTP sobre SSL, apenas a camada dos recursos de segurança do SSL e do HTTP padrão. Primeiro, o handshake de cliente-servidor, usando a criptografia de chave pública/privada para criar uma chave compartilhada, que é usada pela segunda parte do protocolo SSL para criptografar a comunicação.
Fazer networking na Internet pode parecer seguro, imediato e rápido. Parece que estamos conversando diretamente com o site. Mas, na realidade, não é uma conexão direta. Nossas comunicações passam por um roteador Wifi, um ISP e possivelmente outros proxies intermediários entre seu dispositivo e o site. Sem o HTTPS, todas as nossas comunicações são em texto simples.
O problema é que os usuários raramente digitam um URL completo especificando o HTTPS, ou clicam em um link usando HTTP. E, para piorar, é possível montar um ataque (wo)man-in-the-middle e substituir o HTTPS por HTTP. Uma ferramenta chamada SSLstrip, lançada em 2009, faz exatamente isso. A Firesheep, de 2010, só ouvia redes Wi-Fi abertas para que os cookies fossem enviados de forma clara: isso significava que você podia ouvir no bate-papo ou fazer login na conta do Facebook de alguém.
Mas o SSL é (relativamente) barato, rápido e fácil de implantar. Confira ssllabs.com e o livro High Performance Browser Networking de Ilya Grigorik. A fixação de chave pública foi criada para oferecer aos operadores de sites uma forma de restringir quais autoridades de certificação podem emitir certificados para os sites deles.
"Em janeiro deste ano (2010), o Gmail passou a usar HTTPS em tudo por padrão. Para isso, não tivemos que implantar máquinas adicionais nem hardware especial. Em nossas máquinas de front-end de produção, o SSL é responsável por menos de 1% da carga da CPU, menos de 10 KB de memória por conexão e menos de 2% da sobrecarga de rede...
Se você parar de ler agora, só vai precisar lembrar de uma coisa: o SSL não é mais caro do ponto de vista computacional.”
– Overclocking SSL, Adam Langley (Google)
Por último, alguns bugs que vemos com mais frequência:
- Conteúdo misto:sites que usam HTTP e HTTPS. Seu usuário vai ficar irritado porque precisa clicar em um botão de permissão para carregar o conteúdo. O Chrome e o Firefox, na verdade, impedem conteúdo misto de iframes. Verifique se todos os recursos em uma página HTTPS são carregados por HTTPS usando URLs relativos ou relativos a esquemas, por exemplo,
<style src="//foo.com/style.css">. - Cookies não seguros:são enviados claramente usando uma conexão HTTP. Para evitar isso, defina o atributo "secure" nos cabeçalhos de cookies. Também é possível usar um novo cabeçalho "Strict Transport Security" para exigir segurança de transporte SSL (HSTS).
Takeaways
- Se você se preocupa com a privacidade e a integridade dos dados dos usuários, é necessário usar SSL. Está mais rápido, fácil e barato do que nunca.
- Evite problemas comuns de implementação, como bugs de conteúdo misto ou não configurar os bits de cabeçalho HTTP corretos.
- Use URLs relativos de esquema ou relativos.
- Confira algumas novidades, como HSTS e fixação de certificados
Apresentações: Você tem SSL?
APIs Media para a Web para vários dispositivos
de Sam Dutton e Jan Linden
Junto com o crescimento de novos dispositivos e plataformas na Web, observamos um enorme crescimento em áudio, vídeo e comunicação em tempo real. As mídias on-line estão transformando a maneira como consumimos todos os tipos de mídia.
Um estudo do governo do Reino Unido descobriu que 53% dos adultos "realizam várias tarefas na mídia" enquanto assistem TV: usam dispositivos móveis para compartilhar e consumir mídia. Em muitos países, a TV diminuiu e a Internet aumentou. Na China, por exemplo, em 2012, somente 30% das famílias em Pequim assistiram TV, contra 70% em 2009. De acordo com os Destaques do W3C de 2013, "No último ano, as visualizações de vídeos em dispositivos móveis dobrou. Neste ano, nos EUA, o tempo médio gasto por dia com mídia digital vai superar o tempo que assiste TV. A visualização não é mais um ato passivo. Nos EUA, 87% dos consumidores de entretenimento afirmam que usam pelo menos um segundo dispositivo de tela enquanto assistem televisão. De acordo com a Cisco, "o vídeo vai estar na faixa de 80% a 90% do tráfego global do consumidor até 2017". Isso equivale a quase um milhão de minutos de vídeo por segundo.
Então, o que temos para os desenvolvedores da Web? Um ecossistema de APIs de mídia para a Web aberta: tecnologias padronizadas e interoperáveis que funcionam em várias plataformas.
Takeaways
- O WebRTC fornece comunicação em tempo real no navegador e agora é amplamente compatível com dispositivos móveis e computadores. Já existem no total mais de 1,2 bilhão de endpoints WebRTC.
- O Áudio da Web oferece ferramentas sofisticadas para síntese e processamento de áudio.
- Web MIDI, integrada ao Web Audio, permite a interação com dispositivos MIDI.
- Os elementos de áudio e vídeo agora são compatíveis com mais de 85% dos navegadores para dispositivos móveis e computadores.
- As extensões de origem de mídia podem ser usadas para streaming adaptável e time shifting.
- O EME permite a reprodução de conteúdo protegido.
- As transcrições, as legendas e o elemento track permitem a ativação de legendas, legendas, metadados com marcação de tempo, links diretos e pesquisa direta.
Apresentações:APIs de mídia para a Web em vários dispositivos