Blink
Greg Simon と Eric Seidel による
Blink は Chrome のオープンソース レンダリング エンジンです。Blink チームは、ウェブの進化とデベロッパーが直面する問題への対応に取り組んでいます。
4 月のリリース以降、裏側で多くの改善が行われています。
まず、不要なソースの半分を削除しました。まだ終わりではありません。コードの削除は、レポートを有効にしている Chrome ユーザーから匿名で報告された集計統計情報に基づいて行われます。
新しいデベロッパー API は、Chrome のリリース スケジュールと同じく 6 週間ごとに公開されます。
Blink からフォークした際の大きな変更のひとつが、インテント システムの追加です。ウェブ プラットフォームを変更する前に、機能の追加または削除の意図を Blink デベロッパーに公開します。その後、コードを記述します。機能がチェックインされた翌日には、その機能はすでに Canary ビルドに組み込まれています。この機能はデフォルトでオフになっていますが、about:flags を使用してオンにできます。
その後、公開メーリング リストで発送の意向を発表します。
chromestatus.com では、Google が取り組んでいる機能、リリース済みの機能、サポート終了予定の機能を確認できます。Chromium リリース ブログもご覧ください。バグやトラッカー ダッシュボードへのリンクが掲載されています。
もう 1 つの大きな変更は、WebKit 接頭辞の削除です。目的は、Blink 接頭辞を使用するのではなく、ランタイム フラグ（コンパイル時フラグだけでなく）を使用することです。
Android WebView は大きな課題でしたが、HTML5Test では改善が進んでいることが示されています。ウェブ プラットフォームの API がどこでも 1 つのセットで利用できる点では、パソコンに近づいています（Web Audio がその良い例です）。
では、ソーセージ マシンの仕組みはどのようなものなのでしょうか。Blink に加えた変更はすべて、すぐに 3 万件を超えるテストで実行されます。さらに、後で追加で実行されるすべての Chromium テストも行われます。Google は 24 時間体制で、数千もの bot、数千ものベンチマーク、数百万もの不正なウェブページをエンジンに投入するシステムを使用して、エンジンが停止しないようにしています。モバイルでは速度が大幅に低下していることは認識しており、改善に向けて取り組んでおります。
新機能
- ウェブ コンポーネント: Eric Bidelman の講演をご覧ください。
- ウェブ アニメーション: 可能な限り GPU を使用する、複雑で同期された高パフォーマンスのアニメーション
- 部分レイアウト: 必要なものだけを計算します。
- CSS グリッド
- レスポンシブ画像:
srcset または srcN または ? - テキストの自動サイズ調整の高速化と、サブピクセルのフォントの一貫性
- Blink で使用されるグラフィック システムである Skia が、Windows で GDI から DirectWrite に移行
ご意見をお待ちしております。
C++ を血に滲み込ませ、Google と一緒に C++ を記述したい場合は、すべてのコードがオープンソースです。誰かに伝えたり、Google に宣伝したりする必要はありません。パッチを投稿するか、バグを報告してください。
スライド: 点滅
セキュリティ
パリサ タブリーズ
かつてないほど多くの人が、より多くの場所からウェブに接続しています。
ノートパソコン、スマートフォン、タブレットと接続されており、近い将来には個人用デバイスやアクセサリーとも接続されるでしょう。信頼できないネットワーク、時には敵対的なネットワークからインターネットにアクセスします。生活の多くの部分がオンラインに移行する中、Google とユーザーのデータの保護に取り組むことは不可欠です。
デベロッパーは、SSL の必要性と実用性を理解する必要があります。
SSL とは何ですか？セキュア ソケット レイヤ（Secure Sockets Layer）の略で、インターネット経由の通信のセキュリティを確保するために設計された暗号化プロトコルです。暗号化と完全性によりプライバシーを保証し、インターネット接続の盗聴や改ざんを防ぎます。SSL には欠点がありますが、インターネット上であらゆる種類のデータ通信のセキュリティを確保するための主流の方法であり、実際には唯一の方法です。
SSL Pulse によると、1 年前は SSL を導入しているサイトは 15% 未満でしたが、現在は 50% を超えています。
次の 2 つの略語:
TLS: ほとんどの目的と用途では SSL と同じです。正確には、SSL 3.1 の名前が TLS に変更され、TLS が IETF 標準名になりました。でも、どちらも同じものです。
HTTPS: SSL を介した HTTP です。SSL と標準 HTTP のセキュリティ機能を重ねたものです。まず、クライアントとサーバーの handshake で、公開鍵/秘密鍵暗号を使用して共有鍵を作成します。この共有鍵は、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% 未満を占めています。
ここまで読んで、覚えておくべきことは 1 つだけです。SSL は計算コストが高くありません。」
– SSL のオーバークロック、Adam Langley（Google）
最後に、よく見られるバグをいくつかご紹介します。
- 混合コンテンツ: HTTP と HTTPS の両方を使用するサイト。コンテンツを読み込むために権限ボタンをクリックしなければならないため、ユーザーは不満を感じることになります。（Chrome と Firefox では、iframe からの混合コンテンツが実際にブロックされます）。
<style src="//foo.com/style.css">などの相対 URL またはスキーム相対 URL を使用して、HTTPS ページ上のすべてのリソースが HTTPS で読み込まれるようにします。 - 安全でない Cookie: HTTP 接続を介してクリアテキストで送信されます。これを回避するには、Cookie ヘッダーに secure 属性を設定します。新しい「Strict Transport Security」ヘッダーを使用して、SSL Transport Security（HSTS）を必須にすることもできます。
要点
- ユーザーデータのプライバシーと完全性を重視している場合は、SSL を使用する必要があります。これまで以上に迅速、簡単、低コストに。
- コンテンツの混在によるバグや、適切な HTTP ヘッダー ビットの設定不足など、実装によくある落とし穴を回避できます。
- 相対 URL またはスキーム相対 URL を使用する。
- HSTS や証明書の固定など、新しい機能の詳細を確認する
スライド: SSL を取得する
マルチデバイス ウェブ向けの Media API
Sam Dutton と Jan Linden による
ウェブ上の新しいデバイスやプラットフォームの急増に伴い、音声、動画、リアルタイム コミュニケーションが急速に拡大しています。オンライン メディアは、あらゆる種類のメディアの消費方法を変えています。
英国政府の調査によると、成人の 53% がテレビを見ながら「メディア マルチタスク」を行っています。つまり、モバイル デバイスを使用してメディアを共有、視聴しています。多くの国で、テレビ視聴は減少し、オンライン視聴は増加しています。たとえば中国では、2012 年に北京の世帯の 30% のみがテレビを視聴しており、2009 年の 70% から減少しています。W3C ハイライト 2013 によると、「過去 1 年間でモバイル デバイスでの動画視聴が 2 倍に増加しました。米国では、今年、デジタル メディアに費やす 1 日あたりの平均時間がテレビ視聴を上回ると予想されています。視聴はもはや受動的な行為ではありません。米国では、エンターテイメント コンシューマの 87% が、テレビを視聴する際に少なくとも 1 つのセカンド スクリーン デバイスを使用していると回答しています。」Cisco によると、「2017 年までに、動画は世界中の消費者トラフィックの 80 ～ 90% を占める」と予測されています。これは、1 秒あたり約 100 万分の動画に相当します。
ウェブ デベロッパー向けの機能はどのようなものがありますか？オープンウェブ向けのメディア API のエコシステム: 複数のプラットフォームで動作する標準化された相互運用可能なテクノロジー。
要点
- WebRTC はブラウザでのリアルタイム通信を可能にし、モバイルとパソコンで広くサポートされています。すでに 12 億を超える WebRTC エンドポイントが存在します。
- Web Audio は、音声合成と処理のための高度なツールを提供します。
- Web MIDI は Web Audio と統合されており、MIDI デバイスとのやり取りが可能です。
- 音声要素と動画要素は、モバイルとパソコンのブラウザの 85% 以上でサポートされるようになりました。
- メディアソース拡張機能は、アダプティブ ストリーミングとタイムシフトに使用できます。
- EME により、保護されたコンテンツの再生が可能になります。
- 文字起こし、字幕、トラック要素を使用すると、字幕、字幕、タイミング付きメタデータ、ディープリンク、ディープ検索を有効にできます。
スライド: マルチデバイス ウェブ向けの Media API