Blink
作者: Greg Simon、Eric Seidel
Blink は Chrome のオープンソースのレンダリング エンジンです。Blink のチームはウェブを進化させ、デベロッパーが直面する問題に対処しています。
4 月のリリース以来、さまざまなバックグラウンドでの改善が行われてきました。
最初にやったのは、必ずしも必要のない情報源の半分を削除することでした。まだ終わりではありません。また、Google はこのような盲目的ではありません。コードの削除は、レポートにオプトインした Chrome ユーザーから匿名で報告される集計データに基づいています。
Chrome の出荷スケジュールと同じく、新しいデベロッパー API を 6 週間ごとに公開しています。
Blink からフォークしたときの大きな変更点の 1 つは、インテント システムを追加したことです。ウェブ プラットフォームを変更する前に、機能を追加または削除する計画を伝える公式発表を Blink dev に送信します。さて、次はコーディングします。機能がチェックインされた翌日には、Canary ビルドにすでに搭載されています。この機能はデフォルトではオフになっていますが、about:flags を使用することでオンにできます。
その後、Google の公開メーリング リストで出荷の意向を発表します。
chromestatus.com では、これまで対応してきた機能、リリース予定の機能、今後廃止を予定している機能をご確認いただけます。また、Chromium リリースブログも参照してください。バグやトラッカー ダッシュボードへのリンクが掲載されています。
もう一つの大きな変更点は、WebKit プレフィックスが削除されることです。その目的は、Blink の接頭辞を使用するのではなく、（コンパイル時フラグだけでなく）実行時フラグを含めることです。
Android WebView は大きな課題がありましたが、HTML5Test を見ると、状況は良くなっていることがわかります。1 つのウェブ プラットフォーム API セットをどこでも利用できるという点で、デスクトップにかなり近づいています（ウェブ オーディオはその好例です）。
ソーセージ マシンはどのような仕組みなのでしょうか。Blink に加えた変更はすべて、即座に 30,000 件以上のテストに実施されます。また、今後追加されるすべての Chromium テストは言うまでもなく、何千もの bot、何千ものベンチマーク、何百万もの破損したウェブページをエンジンでスローするシステムによる 24 時間の保安サービスを使用して、エラーを確実に阻止しています。モバイルの速度が大幅に低下していることを Google でも認識しており、この改善に取り組んでおります。
新機能
- ウェブ コンポーネント: Eric Bidelman の講演をご覧ください。
- ウェブ アニメーション: 可能な限り GPU を使用する、複雑で同期された高性能なアニメーション
- Partial Layout: 必要なものだけをコンピューティングします。
- CSS グリッド
- レスポンシブ画像:
srcset、srcN、? - テキストの自動サイズ調整が高速化され、サブピクセル フォントが一貫している
- Blink が使用しているグラフィック システムである Skia が、GDI から Windows 版 DirectWrite に移行されました。
皆様からのご意見をお待ちしております。
C++ を気に入ったら、ぜひ Google のコードをぜひお試しください。誰かに話したり、伝道させたりする必要はありません。パッチを投稿するか、バグを報告するだけで済みます。
スライド: 点滅
セキュリティ
アーティスト: Parisa Tabriz
今日、ウェブに接続する人々はかつてないほど増え、場所も増え続けています。
私たちはノートパソコン、スマートフォン、タブレットとつながっていますが、おそらくプライベートのデバイスやアクセサリーにもすぐにつながっています。インターネットには信頼できないネットワーク、場合によっては悪意のあるネットワークからアクセスします。私たちの生活の多くがオンラインで行われる中で、私たちのデータとユーザーのデータを保護するための措置を講じることが不可欠です。
とりわけ、開発者は SSL の必要性と実用性を理解する必要があります。
SSL とはセキュア ソケット レイヤ（Secure Sockets Layer）の略で、インターネット上での通信セキュリティを確保するために設計された暗号プロトコルです。暗号化と整合性によりプライバシーを保証し、インターネット接続の傍受や改ざんを防ぎます。SSL にも欠点がありますが、これはインターネット上のあらゆる種類のデータ通信セキュリティを確保するための、最先端の方法であり、まさに唯一の方法です。
SSL Pulse によると、1 年前には SSL の導入率が 15% 弱でしたが、現在は 50% を超えています。
2 つの頭字語:
TLS: ほとんどのインテントと目的において、SSL と同じです。正確に言うと、SSL 3.1 は TLS に名前変更され、TLS は IETF 標準の名前です。しかし、この 2 つは交換可能です。
HTTPS: HTTP over SSL です。SSL と標準 HTTP のセキュリティ機能がレイヤ化されています。まず、公開鍵/秘密鍵暗号を使用して、クライアントとサーバー間のハンドシェイクを行います。共有鍵は、SSL プロトコルの 2 番目の部分で通信の暗号化に使用されます。
インターネット上のネットワークは、安全で迅速、かつ高速であると感じるかもしれません。まるでウェブサイトに直接話しかけているように感じられます。しかし実際には、それは直接のつながりではありません。Google の通信は Wi-Fi ルーターや ISP を経由しており、また、ユーザーのデバイスとウェブサイトとの間の中継プロキシとなる場合もあります。HTTPS を使用していない場合、通信はすべて書式なしテキストで行われます。
問題は、ユーザーが HTTPS を指定して完全な URL を入力することがほとんどないか、HTTP を使用してリンクをクリックすることです。さらに悪いことに、（女性）中間者攻撃を仕掛けて HTTPS が HTTP に置き換わるおそれもあります。まさにそれを実現するのが、2009 年に導入された SSLstrip というツールです。2010 年以来、Firesheep は開いた Wi-Fi ネットワークを聞いて、クッキーがクリアな状態で送信されることを聞いていました。つまり、チャットを聴いたり、他人の Facebook アカウントにログインしたりできる、という意味でした。
しかし、SSL は（比較的）安価で迅速、デプロイが簡単です（ssllabs.com と Ilya Grigorik の書籍『High Performance Browser Networking』をご覧ください）。公開鍵のピン留めは、ウェブサイト事業者がサイトに対して実際に証明書を発行できる認証局を制限する手段を提供するように設計されています。
「今年（2010 年）1 月、Gmail はデフォルトで HTTPS の使用に切り替わりました。そのために、追加のマシンや特別なハードウェアをデプロイしなくてはなりませんでした。本番環境フロントエンド マシンでは、SSL は CPU 負荷の 1% 未満、接続あたりのメモリ容量は 10 KB 未満、ネットワーク オーバーヘッドの 2% 未満です。
ここで覚えておいていただきたいのは、SSL はもう計算処理に費用がかかるわけではない、ということです。」
– Overclocking SSL、Adam Langley（Google）
よくあるバグは次のとおりです。
- 混合コンテンツ: HTTP と HTTPS を使用するサイト。コンテンツを読み込む際に権限ボタンをクリックすることになるため、ユーザーにイライラします。（Chrome と Firefox では、実際に iframe から混合コンテンツが制限されます）。相対 URL またはスキーム連動 URL（例:
<style src="//foo.com/style.css">）を使用して、HTTPS ページ内のすべてのリソースが HTTPS で読み込まれるようにします。 - 安全でない Cookie: HTTP 接続を介して暗号化されていない状態で送信されます。これを回避するには、Cookie ヘッダーに Secure 属性を設定します。新しい「Strict Transport Security」ヘッダーを使用して、SSL トランスポート セキュリティ（HSTS）を要求することもできます。
テイクアウェイ
- ユーザーデータのプライバシーと完全性を重視する場合は、SSL を使用する必要があります。これまで以上に速く、簡単で、より低価格になりました。
- 混合コンテンツのバグや、適切な HTTP ヘッダービットの設定の失敗など、一般的な実装の問題を回避します。
- 相対 URL またはスキーム相対 URL を使用します。
- HSTS や証明書ピニングなど、新しい機能をご確認ください
スライド: SSL に対応していますか？
マルチデバイス ウェブ用のメディア API
作成者: Sam Dutton、Jan Linden
ウェブ上で新しいデバイスやプラットフォームが普及するのに伴い、音声、動画、リアルタイム コミュニケーションも急激に成長しています。オンライン メディアの登場により、あらゆる種類のメディアの消費方法が変わりつつあります。
英国政府の調査によれば、大人の 53% がテレビを見ながら「メディア マルチタスク」を行っている、つまりモバイル デバイスを使ってメディアを共有、視聴している。多くの国では、テレビの視聴が減少し、オンラインでの視聴が増加しています。たとえば、2012 年に中国でテレビを見るのは、北京の世帯の 30% だけで、2009 年の 70% から減少しています。W3C Highlights 2013 によると、「過去 1 年間でモバイル デバイスでの動画視聴は 2 倍になりました。今年の米国では、1 日あたりのデジタル メディアの平均利用時間はテレビの視聴を上回る。視聴はもはや受動的な行動ではありません。米国では、エンターテインメントを利用する消費者の 87% が、テレビを見ながら 2 台目のデバイスを少なくとも 1 台使用すると回答しています。Cisco によると、「video ... は 2017 年までに世界の消費者トラフィックの 80 ～ 90% の範囲内になる見込みです」。これは毎秒 100 万分近くの動画に相当します。
ウェブ デベロッパー向けに Google が提供しているものは何でしょうか？オープンウェブ向けのメディア API のエコシステム: 複数のプラットフォームで機能する標準化された相互運用可能なテクノロジー。
テイクアウェイ
- WebRTC は、ブラウザ内でのリアルタイムの通信を行うもので、現在、モバイルとパソコンに広くサポートされています。合計ですでに 12 億を超える WebRTC エンドポイントがあります。
- ウェブオーディオは、音声の合成と処理のための高度なツールを提供します。
- Web MIDI は Web Audio と統合されており、MIDI デバイスを操作できます。
- 現在、音声要素と動画要素は、モバイルとパソコンのブラウザの 85% 以上でサポートされています。
- Media Source Extensions は、アダプティブ ストリーミングとタイムシフトに使用できます。
- EME は、保護されたコンテンツの再生を可能にします。
- 文字起こし、キャプション、track 要素は、字幕、キャプション、タイムコード付きメタデータ、ディープリンク、ディープリンクを有効にします。
スライド: マルチデバイス ウェブ向けのメディア API