Blink
por Greg Simon e Eric Seidel
O Blink é o mecanismo de renderização de código aberto do Chrome. A equipe do Blink está evoluindo a Web e resolvendo os problemas encontrados pelos desenvolvedores.
Desde o lançamento em abril, fizemos várias melhorias nos bastidores.
A primeira coisa que fizemos foi excluir metade da nossa fonte, que não era necessária. Ainda não terminamos. E não estamos fazendo isso às cegas: a remoção de código é baseada em estatísticas agregadas relatadas de forma anônima dos usuários do Chrome que ativam o envio de relatórios.
Publicamos uma nova API para desenvolvedores a cada seis semanas, a mesma programação de lançamento do Chrome.
Uma grande mudança que fizemos ao bifurcar o Blink foi adicionar um sistema de intents: antes de mudar a plataforma da Web, enviamos um anúncio público ao Blink dev informando nossa intenção de adicionar ou remover um recurso. Depois vamos codificar. E no dia seguinte, depois que o recurso é enviado, ele já está sendo enviado nos nossos builds Canary. Esse recurso fica desativado por padrão, mas pode ser ativado usando about:flags.
Em seguida, na nossa lista de e-mails pública, anunciamos a intenção de enviar.
Em chromestatus.com, você pode conferir os recursos em que trabalhamos, os que enviamos e os que planejamos descontinuar. Também é possível conferir o blog de lançamentos do Chromium, que tem links para bugs e para nosso painel de controle do rastreador.
Outra grande mudança é a remoção dos prefixos do WebKit. A intenção não é usar prefixos do Blink, mas ter flags de execução (e não apenas de tempo de compilação).
O Android WebView foi um grande desafio, mas o HTML5Test mostra que as coisas estão melhorando. Estamos muito mais próximos do computador em termos de ter um conjunto de APIs da plataforma da Web em todos os lugares (o Web Audio é um ótimo exemplo disso).
Mas como a máquina de salsicha funciona? Todas as mudanças feitas no Blink são imediatamente submetidas a mais de 30.000 testes, sem mencionar todos os testes do Chromium que são executados posteriormente. Usamos a verificação 24 horas, com milhares de bots, milhares de comparativos e sistemas que geram milhões de páginas da Web com erros para garantir que o mecanismo não falhe. Sabemos que o acesso por dispositivos móveis é muito mais lento, e estamos trabalhando para melhorar isso.
O que há de novo?
- Componentes da Web: 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 ? - Autodimensionamento de texto mais rápido e fontes consistentes de subpixel
- O Skia, o sistema gráfico usado pelo Blink, está migrando do GDI para o DirectWrite no Windows
Queremos saber sua opinião.
Se você tem C++ no sangue e quer escrever em C++ com a gente, todo o nosso código está aberto. Você não precisa contar para ninguém ou nos evangelizar. Você pode postar uma correção ou registrar um bug.
Apresentações:Blink
Segurança
por Parisa Tabriz
Hoje, mais pessoas estão conectadas à Web do que nunca, e de mais lugares.
Estamos conectados com nossos laptops, smartphones e tablets e, em breve, com dispositivos e acessórios pessoais. A Internet é acessada de redes não confiáveis e, às vezes, até hostis. Como grande parte de nossas vidas está migrando para a Internet, é fundamental tomar medidas para proteger nossos dados e os dados dos nossos usuários.
Acima de tudo, como desenvolvedores, precisamos entender a necessidade e a praticidade do SSL.
O que é SSL? É a sigla de Secure Sockets Layer, um protocolo criptográfico projetado para garantir a segurança da comunicação pela Internet. Ele garante a privacidade, por meio de criptografia e integridade, para evitar a espionagem ou adulteração da sua conexão de Internet. O SSL tem falhas, mas é a principal maneira, e realmente a única, de garantir qualquer tipo de segurança de comunicação de dados na Internet.
De acordo com o SSL Pulse, há um ano tínhamos cerca de 15% de adoção do SSL. Agora, esse número é de mais de 50%.
Dois acrônimos:
TLS:para a maioria das finalidades, é o mesmo que SSL. Para ser mais preciso, o SSL 3.1 foi renomeado para TLS, e TLS é o nome padrão do IETF. Mas eles são intercambiáveis.
HTTPS:é o HTTP sobre SSL, apenas a estratificação dos recursos de segurança do SSL e do HTTP padrão. Primeiro, o handshake cliente-servidor, usando 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 falando diretamente com o site. Mas, na realidade, não é uma conexão direta. Nossas comunicações são enviadas por um roteador Wi-Fi, um ISP e, possivelmente, outros proxies intermediários entre seu dispositivo e o site. Sem HTTPS, todas as nossas comunicações são em texto simples.
O problema é que os usuários raramente digitam um URL completo que especifique HTTPS ou clicam em um link usando HTTP. Pior ainda, é possível montar um ataque intermediário e substituir o HTTPS por HTTP. Uma ferramenta chamada SSLstrip, lançada em 2009, faz exatamente isso. O Firesheep, de 2010, apenas ouvia as redes Wi-Fi abertas para cookies sendo enviados de forma clara: isso significa que você podia ouvir o chat ou fazer login na conta do Facebook de alguém.
No entanto, 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 que os operadores de sites possam restringir quais autoridades de certificação podem emitir certificados para os sites.
"Em janeiro deste ano (2010), o Gmail passou a usar HTTPS para tudo por padrão. Para isso, não precisamos implantar máquinas adicionais nem hardware especial. Nas máquinas de front-end de produção, o SSL representa 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, lembre-se de uma coisa: o SSL não é mais caro computacionalmente.
– Overclocking SSL, Adam Langley (Google)
Por fim, alguns dos bugs mais comuns:
- Conteúdo misto:sites que usam HTTP e HTTPS. O 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 bloqueiam o 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 esquema, por exemplo,
<style src="//foo.com/style.css">. - Cookies não seguros:são enviados sem criptografia por uma conexão HTTP. Para evitar isso, defina o atributo seguro nos cabeçalhos de cookies. Também é possível usar um novo cabeçalho "Strict Transport Security" para exigir a segurança de transporte SSL (HSTS).
Aprendizados
- Se você se preocupa com a privacidade e a integridade dos dados dos usuários, é necessário usar o SSL. É mais rápido, fácil e barato do que nunca.
- Evite armadilhas comuns de implementação, como bugs de conteúdo misto ou a não configuração dos bits de cabeçalho HTTP corretos.
- Use URLs relativos ou relativos ao esquema.
- Confira algumas das novidades, como HSTS e fixação de certificado
Slides:Você tem SSL?
APIs de mídia para a Web em vários dispositivos
por Sam Dutton e Jan Linden
Além da proliferação de novos dispositivos e plataformas na Web, estamos vendo um crescimento enorme em áudio, vídeo e comunicação em tempo real. A mídia on-line está transformando a maneira como consumimos mídia de todos os tipos.
Um estudo do governo do Reino Unido (link em inglês) descobriu que 53% dos adultos fazem "multitarefas de mídia" enquanto assistem TV: usam dispositivos móveis para compartilhar e consumir mídia. Em muitos países, a visualização de TV diminuiu e a visualização on-line aumentou. Na China, por exemplo, em 2012, apenas 30% das famílias em Pequim assistiam TV, uma queda de 70% em relação a 2009. De acordo com os Destaques do W3C 2013, "No ano passado, o consumo de vídeos em dispositivos móveis dobrou". Este ano, nos EUA, o tempo médio gasto com mídia digital por dia vai superar a visualização de TV. Assistir não é mais um ato passivo. Nos EUA, 87% dos consumidores de entretenimento dizem usar pelo menos um dispositivo de segunda tela enquanto assistem TV.' De acordo com a Cisco, "o vídeo vai representar de 80% a 90% do tráfego global de consumidores até 2017". Isso equivale a quase um milhão de minutos de vídeo por segundo.
O que temos para desenvolvedores Web? Um ecossistema de APIs de mídia para a Web aberta: tecnologias padronizadas e interoperáveis que funcionam em várias plataformas.
Aprendizados
- O WebRTC oferece comunicação em tempo real no navegador e agora tem suporte amplo para dispositivos móveis e computadores. No total, já existem mais de 1,2 bilhão de endpoints do WebRTC.
- O Web Audio oferece ferramentas sofisticadas para síntese e processamento de áudio.
- O Web MIDI, integrado ao Web Audio, permite a interação com dispositivos MIDI.
- Os elementos de áudio e vídeo agora têm suporte em 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 mudança de tempo.
- O EME permite a reprodução de conteúdo protegido.
- As transcrições, as legendas e o elemento de faixa permitem legendas, metadados temporizados, links diretos e pesquisa profunda.
Apresentações: APIs de mídia para a Web em vários dispositivos