블링크(Blink) by +Greg Simon & +Eric Seidel
블링크는 크롬의 오픈소스 렌더링 엔진입니다. 블링크 팀은 개발자들이 부딪히는 이슈들을 고민하며 웹을 혁신하고 있습니다.
여기에는 지난 4월의 런칭으로부터 시작하는 수많은 감춰진 개선사항들이 있습니다.
첫번째로 우리는 더 이상 필요로 하지 않는 절반가량의 소스를 삭제했으며 아직도 이는 끝나지 않았습니다! 그리고 리포팅 의사 표시를 한 크롬 사용자들로부터 익명으로 리포팅된 종합적인 통계들에 기반한 코드 제거에 대해 묵과하지 않고 있습니다.
우리는 새로운 개발자 API를 크롬의 탑재 스케줄과 동일하게 매 6주마다 발행하고 있습니다.
블링크로부터 포크했을 때 가장 큰 변경은 다음과 같은 인텐트(Intent) 시스템을 추가하는 것입니다. 웹 플랫폼을 변경하려 하기 전 매번 우리는 기능의 추가나 삭제를 위한 우리의 의도를 표현하기 위해 블링크 개발자 그룹을 통해 공개 발표를 해왔습니다. 그리고나서 움직였고 코드를 작성했습니다! 그리고나서 기능을 체크인한 바로 다음날이면 카나리 빌드에 이미 탑재된 상태였습니다. 이러한 기능은 기본적으로 Off된 상태이지만 about:flags를 이용하여 이를 활성화할 수 있습니다.
그 후 우리는 공용 메일링 리스트 상에서 이에 대한 탑재 의도를 발표했습니다.
chromestatus.com에서 우리가 작업한 기능들, 탑재한 기능들, 제거할 계획을 가지고 있는 것들을 확인할 수 있습니다. 또한 크롬 배포 블로그에서 버그들에 대한 링크들과 추적 대쉬보드를 확인할 수도 있습니다.
또다른 큰 변경사항은 WebKit 접두어를 삭제하고 있는 것입니다. 의도는 블링크의 접두어를 사용하기 위함이 아니라 (그저 컴파일 시의 플래그만이 아닌) 런타임 플래그를 가지기 위함입니다.
안드로이드 웹뷰는 아주 커다란 도전이었습니다만 HTML5Test는 이들이 더 좋아졌음을 보여줍니다. 웹 플랫폼 API들이 어디에서나 하나의 세트를 가지는 관점에서 데스크탑에 훨씬 더 가까워졌습니다. (웹 오디오는 이에 대한 훌륭한 예제입니다!)
그러나 어떻게 소세지 기계가 동작하나요? 각각의 모든 변화들은 나중에 추가적으로 실행할 모든 크로미움 테스트는 말 할 필요도 없이 블링크가 30,000개 이상의 테스트를 즉시 거치도록 했습니다. 우리는 24시간 보안관, 수천개의 봇들, 수천개의 벤치마크 그리고 갑자기 중단되지 않음을 확신하기 위해 몇백만개의 깨진 웹 페이지를 엔진으로 던지는 시스템들을 사용하고 있습니다. 우리는 모바일이 두드러지게 느리고 이는 우리가 개선을 위해 훨씬 더 열심히 일해야한다는 뜻임을 알고 있습니다.
그럼 무엇이 새로워졌을까요?
- Web Components: +Eric Bidelman의 발표를 확인해보세요!
- Web Animations: 가능한한 GPU를 사용하는 복잡하고 동기화된 고성능 애니메이션
- Partial Layout: 필요한 것만 계산하는!
- CSS Grid
- Responsive images: srcset 혹은 srcN 또는?
- 더 빨라진 텍스트 자동 래스터 조정(Autosizing) 일관된 서브픽셀(Sub-pixel) 폰트
- 블링크의 그래픽 시스템인 SKIA가 윈도우즈용에서 GDI에서 DirectWrite로 이동
우리는 여러분들이 무엇을 말할지 알고 싶습니다!
만약 여러분이 혈관을 흐르는 C++을 느끼고 작성하고 싶다면, 우리의 모든 코드는 열려있습니다. 만약 누구에게도 말하지 않고 우리에게 전파를 할 수 있습니다. 그냥 패치를 포스팅하거나 버그를 정리해주세요!
슬라이드: Blink
보안(Security) by +Parisa Tabriz
오늘날은 그 언제보다도 더 많은 사람들이 더 많은 곳에서 웹으로 연결되어 있습니다.
우리는 랩탑, 휴대폰 그리고 태블릿으로 연결되어 있으며 아마도 곧 개인 디바이스들과 액세서리들로도 충분해질 것입니다. 우리는 신뢰할 수 없거나 가끔은 적대적인 네트워크로부터도 인터넷을 액세스합니다. 삶의 많은 부분이 온라인으로 이동하며 우리의 데이터와 우리 사용자의 데이터를 보호하기 위한 단계가 중요해졌습니다.
무엇보다 개발자로써의 우리는 SSL의 필요성과 실현 가능성에 대해 이해할 필요가 있습니다.
SSL이란 무엇일까요? 이는 전송 계층 보안(Secure Sockets Layer)를 의미하고 인터넷 간의 통신 보안을 제공하기 위해 디자인된 암호화 프로토콜입니다. 암호화와 완전성을 통해 인터넷 연결을 통한 스누핑(Snooping)이나 데이터 훼손(Tempering)을 방지하기 위한 프라이버시를 보장합니다. SSL은 결점이 있지만 주도적인 방식-그리고 실제로는 유일한 방식-이며 인터넷 상의 데이터 통신 보안의 어떠한 것이라도 보장할 수 있는 방식입니다.
SSL Pulse에 따르면 1년 전에는 우리의 SSL 적용은 15% 미만 밖에 안되었지만 현재는 50%가 넘습니다.
다음과 같이 2가지 약어(Acronyms)가 있습니다.
- TLS: SSL과 거의 마찬가지의 목적 및 의도를 가집니다. 보다 정확하게는 SSL 3.1의 명칭이 TLS로 변경되었으며 TLS는 IETF 표준 명칭입니다. 그러나 이는 교환 가능합니다!
- HTTPS: SSL를 통한 HTTP이며, 그저 SSL과 표준 HTTP의 보안 능력을 계층화한 것입니다. 처음 클라이언트-서버 간의 Handshake는 통신을 암호화하기 위한 SSL 프로토콜의 두번째 부분에서 사용되는 공용 키를 생성하기 위해 공용/개인 키 암호화를 사용합니다.
문제는 사용자가 아주 가끔 HTTPS를 정의하는 완전한 URL을 타이핑하거나 HTTP를 사용한 링크를 클릭하는 것입니다. 더 나쁘게 얘기하자면 중간자 공격을 시작하거나 HTTPS를 HTTP로 변경할 수 있습니다. 2009년에 소개된 SSLstrip으로 불리는 도구가 바로 그러한 일을 수행합니다. 2010년에 발표된 Firesheep은 열려있는 WiFi 네트워크에서 깔끔하게 전송된 쿠키들을 바로 청취할 수 있으며 이는 다른 사람의 페이스북 계정에 로그인하거나 채팅을 엿들을 수 있다는 것을 의미합니다.
그러나 SSL은 (비교적) 저렴하고 빠르며 배포하기 쉽습니다. (ssllabs.com과 +Ilya Grigorik 의 저서 '고성능 브라우저 네트워킹'을 확인해보시기 바랍니다.) 상용이 아닌 경우 여러분은 startsll.com으로 부터 무료로 인증을 받을 수도 있습니다! Public Key Pinning은 웹사이트 운영자들이 당사자들이 그들의 사이트 인증서를 실제로 이슈화할 수 있는 인증 범위를 제한할 수 있도록 디자인되었습니다.
"올해(2010) 1월, Gmail은 기본사항으로 모든 것에 대해 HTTPS를 사용하도록 변경되었습니다. ..이를 위해 우리는 추가적인 장치나 특별한 하드웨어 없이 이를 배포해야 했습니다. 우리의 프론트엔드 생성 장비들 상에서 SSL 계정들은 1% 이하의 CPU 부하와 10KB 이하의 연결당 메모리 사용량 그리고 2% 이하의 네트워크 부하를 차지하며...
만약 지금 여기까지만 읽고 싶으시다면 그냥 하나만 기억하세요. SSL은 더 이상 연산량에 있어 비싸지 않습니다." – Overclocking SSL, Adam Langley (Google)
마지막으로 우리가 일반적으로 볼 수 있는 몇가지 버그들은 다음과 같습니다.
- 혼합된 컨텐츠:
- HTTPS뿐만이 아니라 HTTP를 사용하는 사이트들. 컨텐츠가 로딩될 때 권한에 대한 클릭을 해야하므로 여러분의 사용자는 짜증이 날 수 있습니다. (크롬, 파이어폭스는 실제로 iframe들이 컨텐츠를 혼합하는 것을 막습니다.) 예를 들어 <style src="//foo.com/style.css">와 같이 HTTPS 페이지 내의 모든 리소스들을 상대 경로 혹은 상대-스키마(Scheme-Relative)를 사용하여 반드시 HTTPS로 로딩하도록 합니다.
- 안전하지 않은 쿠키들:
- HTTP 연결을 통해 깨끗하게 보내는 경우. 쿠키 헤더들 상의 보안 속성의 설정을 통해 이를 회피하도록 합니다. 여러분은 SSL 전송 보안(SSL Transport Security, HSTS)를 요구하도록 새로운 "Strict Transport Security"를 사용할 수도 있습니다.
요점(Takeaways)
- 만약 프라이버시와 사용자 데이터의 완전성을 관리하고 싶으시다면 SSL을 사용하여야 합니다.
- 이는 그 무엇보다 빠르고 쉬우며 저렴합니다.
- 혼합된 컨텐츠 버그나 올바른 HTTP 헤더 부분의 설정없는 일반적인 구현들을 회피하여야 합니다.
- 상대 경로 혹은 상대-스키마 URL을 사용합니다.
- HSTS와 인증서 피닝(Certification pinning)과 같은 훌륭한 신규 기능을 확인해보시기 바랍니다.
슬라이드: Got SSL?
멀티디바이스 웹을 위한 Media APIs by +Sam Dutton & +Jan Linden
웹 상의 새로운 디바이스나 플랫폼들의 확산 속에서 우리는 오디오, 비디오 그리고 실시간 통신의 커다란 성장을 보고 있습니다. 온라인 미디어는 모든 종류의 미디어를 우리가 소비할 수 있도록 방식을 바꾸고 있습니다.
영국 정부의 사례에서 53%의 성인이 TV를 보는 동안 모바일 디바이스를 사용하여 미디어를 소비하고 공유하는 '미디어 멀티-태스크'를 한다는 것을 발견할 수 있습니다. 많은 나라에서 TV를 보는 것은 감소하고 있고 온라인 시청은 증가하고 있습니다. 예를 들어 중국의 경우 2009년에 70% 달했던 베이징 가정의 TV 시청이 2012년 단 30%로 감소하였습니다. W3C 2013년 하이라이트에 따르면 '작년동안 모바일 장비에서의 비디오 시청이 2배로 증가하였습니다. 미국의 경우 올해 디지털 미디어의 일일 사용에 대한 평균 시간이 TV 시청을 넘었습니다. 시청은 더 이상 일반적인 행동이 아닙니다. 미국에서는 87%의 엔터테인먼트 소비자들이 TV를 시청하는 동안 최소한 1개 이상의 세컨-디바이스를 사용하고 있다고 말하고 있습니다.' Cisco에 따르면 '비디오는...2017년 글로벌 사용자 트래픽의 80%에서 90%를 차지할 것`이라고 합니다. 이는 매초마다 몇백만분의 비디오가 보여진다는 것과 거의 동일합니다.
그렇다면 웹 개발자들은 무엇을 해야 할까요? 오픈 웹을 위한 미디어 API의 생태계는 멀티플랫폼 간에 동작하는 표준화되고 상호 호환되는 기술입니다.
요점(Takeaways)
- WebRTC는 브라우저에서의 실시간 통신을 제공하며 이제 모바일과 데스크탑 상에서 폭넓게 지원됩니다. 전체적으로 이미 12억개 이상의 WebRTC 종단점들이 존재합니다.
- Web Audio는 오디오 통합 및 처리를 위한 이상적인 도구를 제공합니다.
- Web Audio와 통합된 Web MIDI는 MIDI 장치들과 상호작용을 할 수 있습니다.
- 오디오와 비디오 엘리먼트들은 이제 85% 이상의 모바일 및 데스크탑 브라우저에서 지원됩니다.
- 미디어 소스 확장(Media Source Extensions)은 적응형 스트리밍 및 타임 시프팅(Time Shifting)에서 사용할 수 있습니다.
- EME는 보호된 컨텐츠의 재생을 가능하게 합니다.
- 트랜스크립트(Transcript), 캡션 그리고 트랙(track) 엘리먼트는 자막, 캡션, 시간 메타데이터(Timed metadata), 딥 링크(Deep link, 페이지가 아닌 파일로의 링크) 및 딥 서치(Deep search)를 가능하게 합니다.
슬라이드: Media APIs for the multi-device Web
댓글 없음:
댓글 쓰기