Blink
por Greg Simon & Eric seidel
O Blink é o mecanismo de renderização de código aberto do Chrome. A equipe da Blink está evoluindo a Web e resolvendo os problemas encontrados pelos desenvolvedores.
Houve uma série de melhorias nos bastidores desde nosso lançamento em abril.
A primeira coisa que fizemos foi excluir metade da nossa fonte, o que não era 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 de usuários do Chrome que optaram por gerar relatórios de forma anônima.
Publicamos uma nova API para desenvolvedores a cada seis semanas, igual à programação de envio do Chrome.
Uma grande mudança que fizemos ao bifurcar o Blink foi a adição de um sistema de intents: antes de mudarmos a plataforma da Web, enviamos um anúncio público para o Blink dev comunicando nossa intenção de adicionar ou remover um recurso. Depois a gente escreve e codifica! No dia seguinte após o check-in do recurso, ele já estará disponível para envio em nossos builds Canary. Esse recurso fica desativado por padrão, mas é possível ativá-lo usando about:flags.
Depois, na nossa lista de e-mails pública, anunciamos uma intenção de enviar.
Em chromestatus.com, é possível ver os recursos nos quais trabalhamos, os que já enviamos e aqueles que devem ser descontinuados. Você também pode consultar o blog de versões do Chromium (link em inglês), que tem links para bugs e para o painel do rastreador.
Outra grande mudança é a remoção dos prefixos do WebKit. A intenção não é usar prefixos Blink, mas ter flags de tempo de 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 tudo está melhorando. Estamos muito mais próximos dos computadores em termos de ter um conjunto de APIs de plataforma da Web em todos os lugares (Web Audio é um ótimo exemplo disso!)
Mas como funciona a máquina de salsicha? Cada mudança que fazemos no Blink passa imediatamente por mais de 30.000 testes, sem contar todos os testes do Chromium que serão executados depois. Usamos a verificação 24 horas, com milhares de bots, milhares de comparativos de mercado e sistemas que lançam milhões de páginas da Web corrompidas em nosso mecanismo para garantir que ele não caia. Sabemos que os dispositivos móveis são significativamente mais lentos, e estamos trabalhando duro para melhorar isso.
Quais são as novidades?
- 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, srcN ou ? - Dimensionamento automático de texto mais rápido e fontes de subpixel consistentes
- O Skia, o sistema gráfico usado pela Blink, está mudando de GDI para DirectWrite no Windows
Queremos saber o que você tem a dizer.
Se você sente C++ no seu sangue e quer escrever C++ conosco, todo o nosso código está aberto. Você não precisa contar a ninguém ou nos evangelizar. Basta postar um patch ou registrar um bug.
Apresentações: piscar
Segurança
por Parisa Tabriz
Hoje, mais pessoas do que nunca estão conectadas à Web e de mais lugares.
Estamos conectados com nossos laptops, telefones e tablets e provavelmente em breve com dispositivos e acessórios pessoais. Acessamos a Internet de redes não confiáveis e, às vezes, até mesmo hostis. Com a maior parte das nossas vidas on-line, é essencial proteger nossos dados e usuários dados.
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 criado para oferecer segurança de comunicação pela Internet. Ele garante privacidade, por meio de criptografia e integridade, para evitar espionagem ou adulteração da sua conexão de Internet. O SSL tem falhas, mas é a principal e a única forma 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 cerca de 15% de adoção do SSL. agora estamos mais de 50% de adoção.
Dois acrônimos:
TLS:para a maioria das intents, da mesma forma que o SSL. Na verdade, SSL 3.1 foi renomeado como TLS, e TLS é o nome padrão do IETF. Mas eles são intercambiáveis!
HTTPS: trata-se de HTTP sobre SSL, apenas a camada dos recursos de segurança de SSL e HTTP padrão. Primeiro, o handshake cliente-servidor, usando criptografia de chave pública/privada para criar uma chave compartilhada, que é utilizada pela segunda parte do protocolo SSL para criptografar a comunicação.
A rede na Internet pode parecer segura, imediata e rápida. Parece que estamos nos comunicando diretamente com o site. Mas, na realidade, não é uma conexão direta. Nossas comunicações acontecem 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 especificando HTTPS ou clicam em um link usando HTTP. Para piorar, é possível montar um ataque "mulher-man-in-the-middle" e substituir o HTTPS por HTTP. Uma ferramenta chamada SSLstrip lançada em 2009 faz exatamente isso. O Firesheep, de 2010, acabou de ouvir as redes Wi-Fi abertas para cookies sendo enviados claramente: isso significava que você podia ouvir no bate-papo ou fazer login na conta de 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 desenvolvida para que os operadores de sites restrinjam quais autoridades certificadoras podem emitir certificados para os sites deles.
"Em janeiro deste ano (2010), o Gmail passou a usar HTTPS para tudo por padrão. Para isso, não tivemos que implantar máquinas adicionais e nenhum hardware especial. Em nossas máquinas de front-end de produção, o SSL considera < 1% da carga da CPU, < 10 KB de memória por conexão e < 2% de sobrecarga da rede...
Se você parar de ler agora, só precisará lembrar de uma coisa: o SSL não é mais caro em termos computacionais."
– Overclock SSL, Adam Langley (Google)
Por fim, alguns bugs que encontramos com mais frequência:
- Conteúdo misto:sites que usam HTTP e HTTPS. O usuário ficará irritado porque precisa clicar em um botão de permissão para carregar o conteúdo. O Chrome e o Firefox na verdade barram conteúdo misto de iframes. Verifique se todos os recursos em uma página HTTPS são carregados por HTTPS. Para isso, use URLs relativos ou relativos a esquemas, por exemplo,
<style src="//foo.com/style.css">. - Cookies não seguros:são enviados livremente por uma conexão HTTP. Para evitar que isso aconteça, defina o atributo "secure" nos cabeçalhos de cookies. Também é possível usar uma nova para exigir o SSL Segurança de transporte (HSTS).
Aprendizados
- Se você se preocupa com a privacidade e a integridade dos recursos você precisa usar SSL. Está mais rápido, fácil e barato do que nunca.
- Evite pegadinhas comuns de implementação, como bugs de conteúdo misto ou não definir os bits corretos do cabeçalho HTTP.
- Use URLs relativos ou de esquema relativos.
- Confira algumas novidades interessantes, como HSTS e fixação de certificados
Apresentações: tem SSL?
APIs de mídia para a Web multidispositivo
por Sam Dutton e Jan linden
Junto com uma proliferação de novos dispositivos e plataformas na web, estamos vendo um grande crescimento em áudio, vídeo e comunicação em tempo real. A mídia on-line está 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 ao mesmo tempo enquanto assistem TV: usam dispositivos móveis para compartilhar e consumir mídia. Em muitos países, a visualização da TV está inativa e a visualização on-line aumentou. Na China, por exemplo, em 2012, apenas 30% das famílias em Pequim assistiram TV, uma queda em relação aos 70% em 2009. De acordo com os Destaques do W3C de 2013, "no ano passado, assistir vídeos em dispositivos móveis dobrou. Este ano, nos EUA, o tempo médio gasto com mídia digital por dia ultrapassará o tempo que as pessoas passam assistindo à 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 TV. De acordo com a Cisco, "o vídeo ... estará na faixa 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.
Então, o que temos para os 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 fornece comunicação em tempo real no navegador e agora é amplamente compatível com dispositivos móveis e computadores. No total, já existem mais de 1,2 bilhões de endpoints 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 são compatíveis com mais de 85% dos navegadores para dispositivos móveis e computadores.
- As extensões de fonte 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.
- Transcrições, legendas e o elemento track permite legendas, legendas, metadados com marcação de tempo, links diretos e pesquisa direta.
Apresentações: APIs de mídia para a Web multidispositivo