Blink
por Greg Simon y Eric Seidel
Blink es el motor de renderización de código abierto de Chrome. El equipo de Blink está haciendo evolucionar la Web y abordando los problemas que encuentran los desarrolladores.
Desde el lanzamiento de abril, se implementaron varias mejoras en segundo plano.
Lo primero que hicimos fue borrar la mitad de nuestra fuente, que no necesitábamos necesariamente. Aún no terminamos. Y no lo hacemos a ciegas: la eliminación de código se basa en estadísticas agregadas informadas de forma anónima por los usuarios de Chrome que habilitan los informes.
Publicamos una nueva API para desarrolladores cada seis semanas, lo mismo que el programa de lanzamientos de Chrome.
Un gran cambio que hicimos cuando hicimos el fork de Blink fue agregar un sistema de intents: cada vez que vamos a cambiar la plataforma web, enviamos un anuncio público a los desarrolladores de Blink para anunciar nuestra intención de agregar o quitar una función. Luego, nos ponemos a codificarlo. Y al día siguiente de que se revisa la función, ya se envía en nuestras compilaciones de Canary. Esta función está desactivada de forma predeterminada, pero puedes activarla con about:flags.
Luego, en nuestra lista de distribución pública, anunciamos la intención de enviar.
En chromestatus.com, puedes ver las funciones en las que trabajamos, las que enviamos y las que planeamos dar de baja. También puedes consultar el blog de lanzamientos de Chromium, que tiene vínculos a errores y a nuestro panel de seguimiento.
Otro gran cambio es que quitaremos los prefijos de WebKit. El objetivo no es usar prefijos de Blink, sino tener marcas de tiempo de ejecución (y no solo marcas de tiempo de compilación).
Android WebView fue un gran desafío, pero HTML5Test muestra que las cosas están mejorando. Estamos mucho más cerca de las computadoras de escritorio en términos de tener un conjunto de APIs de plataformas web en todas partes (Web Audio es un gran ejemplo de esto).
Pero ¿cómo funciona la máquina de salchichas? Cada cambio que hacemos en Blink se ejecuta de inmediato en más de 30,000 pruebas, sin mencionar todas las pruebas de Chromium que se ejecutan más adelante. Usamos un servicio de supervisión las 24 horas, con miles de bots, miles de comparativas y sistemas que arrojan millones de páginas web dañadas a nuestro motor para asegurarnos de que no falle. Sabemos que la versión para dispositivos móviles es mucho más lenta, y estamos trabajando arduamente para mejorarla.
¿Qué hay de nuevo?
- Componentes web: Mira la charla de Eric Bidelman.
- Animaciones web: Animaciones complejas, sincronizadas y de alto rendimiento que usan la GPU siempre que sea posible.
- Diseño parcial: Solo calcula lo que necesitas.
- Cuadrícula de CSS
- Imágenes responsivas:
srcset o srcN o ? - Ajuste automático de texto más rápido y fuentes de subpíxeles coherentes
- Skia, el sistema gráfico que usa Blink, pasará de GDI a DirectWrite en Windows.
Queremos saber lo que piensas.
Si te apasiona C++ y quieres escribir en este lenguaje con nosotros, todo nuestro código es de acceso abierto. No tienes que contarle a nadie ni evangelizarnos. Puedes publicar un parche o informar un error.
Presentaciones: Blink
Seguridad
por Parisa Tabriz
Hoy en día, más personas que nunca están conectadas a la Web y desde más lugares.
Nos conectamos con nuestras laptops, teléfonos y tablets, y pronto también con dispositivos y accesorios personales. Accedemos a Internet desde redes no confiables y, a veces, incluso hostiles. Dado que gran parte de nuestras vidas se traslada a la Web, es fundamental que tomemos medidas para proteger nuestros datos y los de nuestros usuarios.
Por sobre todo, como desarrolladores, debemos comprender la necesidad y la practicidad de SSL.
¿Qué es SSL? Significa capa de conexión segura y es un protocolo criptográfico diseñado para proporcionar seguridad de las comunicaciones a través de Internet. Garantiza la privacidad a través de la encriptación y la integridad para evitar que se espíe o manipule tu conexión a Internet. SSL tiene sus defectos, pero es la forma principal (y, en realidad, la única) de garantizar cualquier tipo de seguridad de comunicación de datos en Internet.
Según SSL Pulse, hace un año teníamos alrededor de un 15% de adopción de SSL; ahora tenemos más del 50%.
Dos acrónimos:
TLS: En la mayoría de los casos, es lo mismo que SSL. Para ser más precisos, se cambió el nombre de SSL 3.1 a TLS, y TLS es el nombre estándar de IETF. Pero son intercambiables.
HTTPS: Es HTTP sobre SSL, solo la capa de las capacidades de seguridad de SSL y HTTP estándar. Primero, el protocolo de enlace cliente-servidor, que usa criptografía de clave pública/privada para crear una clave compartida, que usa la segunda parte del protocolo SSL para encriptar la comunicación.
Establecer redes en Internet puede ser seguro, inmediato y rápido. Parece que estamos hablando directamente con el sitio web. Pero, en realidad, no es una conexión directa. Nuestras comunicaciones pasan por un router Wi-Fi, un ISP y, posiblemente, otros proxies intermediarios entre tu dispositivo y el sitio web. Sin HTTPS, todas nuestras comunicaciones están en texto sin formato.
El problema es que los usuarios rara vez escriben una URL completa que especifique HTTPS o hacen clic en un vínculo con HTTP. Peor aún, es posible realizar un ataque de intermediario y reemplazar HTTPS por HTTP. Una herramienta llamada SSLstrip, que se presentó en 2009, hace exactamente eso. Firesheep, de 2010, solo escuchaba las redes Wi-Fi abiertas en busca de cookies que se enviaban de forma clara, lo que significaba que podías escuchar el chat o acceder a la cuenta de Facebook de alguien.
Sin embargo, SSL es (relativamente) económico, rápido y fácil de implementar (consulta ssllabs.com y el libro High Performance Browser Networking de Ilya Grigorik). El fijado de claves públicas está diseñado para brindar a los operadores de sitios web un medio para restringir qué autoridades certificadoras pueden emitir certificados para sus sitios.
"En enero de este año (2010), Gmail comenzó a usar HTTPS para todo de forma predeterminada. Para ello, no tuvimos que implementar máquinas adicionales ni hardware especial. En nuestras máquinas de frontend de producción, SSL representa menos del 1% de la carga de la CPU, menos de 10 KB de memoria por conexión y menos del 2% de la sobrecarga de red.
Si dejas de leer ahora, solo debes recordar una cosa: SSL ya no es costoso en términos de procesamiento”.
– Overclocking SSL, Adam Langley (Google)
Por último, estos son algunos de los errores más comunes que vemos:
- Contenido mixto: Son sitios que usan HTTP y HTTPS. El usuario se molestará porque tendrá que hacer clic en un botón de permiso para cargar contenido. (Chrome y Firefox, de hecho, bloquean el contenido mixto de los iframes). Asegúrate de que todos los recursos de una página HTTPS se carguen a través de HTTPS con URLs relativas o relativas al esquema, por ejemplo,
<style src="//foo.com/style.css">. - Cookies no seguras: Se envían sin encriptar a través de una conexión HTTP. Para evitar esto, configura el atributo seguro en los encabezados de cookies. También puedes usar un nuevo encabezado "Seguridad de transporte estricta" para exigir la seguridad de transporte SSL (HSTS).
Conclusiones
- Si te preocupa la privacidad y la integridad de los datos de tus usuarios, debes usar SSL. Es más rápido, fácil y económico que nunca.
- Evita errores comunes de implementación, como errores de contenido mixto o no configurar los bits de encabezado HTTP correctos.
- Usa URLs relativas o de esquema.
- Descubre algunas de las funciones nuevas y geniales, como HSTS y la fijación de certificados
Diapositivas: ¿Tienes SSL?
APIs de contenido multimedia para la Web multidispositivo
por Sam Dutton y Jan Linden
Junto con la proliferación de dispositivos y plataformas nuevos en la Web, observamos un gran crecimiento en el audio, el video y la comunicación en tiempo real. Los medios en línea están transformando la forma en que consumimos contenido de todo tipo.
Un estudio del Gobierno del Reino Unido reveló que el 53% de los adultos realizan varias tareas con contenido multimedia mientras miran TV: usan dispositivos móviles para compartir y consumir contenido multimedia. En muchos países, la visualización de TV disminuyó y la visualización en línea aumentó. En China, por ejemplo, en 2012, solo el 30% de los hogares de Pekín miraban TV, en comparación con el 70% de 2009. Según el informe W3C Highlights 2013, “en el último año, se duplicó la cantidad de videos que se miran en dispositivos móviles”. Este año, en EE.UU., el tiempo promedio que se dedica a los medios digitales por día superará el tiempo que se dedica a mirar TV. La visualización ya no es un acto pasivo. En EE.UU., el 87% de los consumidores de entretenimiento afirma que usa al menos un dispositivo de segunda pantalla mientras mira televisión. Según Cisco, "el video representará entre el 80 y el 90 por ciento del tráfico global de consumidores en 2017". Eso equivale a casi un millón de minutos de video por segundo.
¿Qué tenemos para los desarrolladores web? Un ecosistema de APIs de contenido multimedia para la Web abierta: tecnologías interoperables y estandarizadas que funcionan en varias plataformas.
Conclusiones
- WebRTC proporciona comunicación en tiempo real en el navegador y ahora es ampliamente compatible con dispositivos móviles y computadoras. En total, ya hay más de 1,200 millones de extremos de WebRTC.
- Web Audio proporciona herramientas sofisticadas para la síntesis y el procesamiento de audio.
- Web MIDI, integrado en Web Audio, permite la interacción con dispositivos MIDI.
- Los elementos de audio y video ahora son compatibles con más del 85% de los navegadores para computadoras y dispositivos móviles.
- Las Extensiones de fuente de contenido multimedia se pueden usar para la transmisión adaptativa y el cambio de hora.
- La EME permite la reproducción de contenido protegido.
- Las transcripciones, los subtítulos y el elemento de pista habilitan los subtítulos, las leyendas, los metadatos sincronizados, los vínculos directos y la búsqueda directa.
Diapositivas: APIs de medios para la Web multidispositivo