Chrome Dev Summit - オープン ウェブ プラットフォームの概要

制作: Greg Simon &Eric Seidel

Blink は Chrome のオープンソース レンダリング エンジンです。Blink チームは、ウェブを進化させ、デベロッパーが直面する問題に対処しています。

4 月のリリース以降、舞台裏では数多くの改善が行われています。

最初に行ったのは、必ずしも必要ではなかったソースの半分を削除することでした。改善の余地はまだ残されています。ただし、Google がこうした情報を見落としているわけではありません。コードの削除は、レポートを有効にしている Chrome ユーザーから匿名で報告される集計データに基づきます。

Chrome の配送スケジュールと同じく、6 週間ごとに新しいデベロッパー向け API を公開しています。

Blink からフォークしたときの大きな変更点は、インテント システムを追加したことです。ウェブ プラットフォームを変更する前に、Blink デベロッパーに一般公開のお知らせを送信し、機能の追加や削除の意向を発表しています。その後、コードを作成します。この機能がチェックインされた翌日には、すでに Canary ビルドに組み込まれています。この機能はデフォルトではオフになっていますが、about:flags を使用してオンにできます。

その後、公開メーリング リスト出荷の意向を発表します。

chromestatus.com では、これまでに開発された機能、これまでにリリースした機能、廃止が予定されている機能をご確認いただけます。また、Chromium リリースのブログではバグやトラッカー ダッシュボードへのリンクを掲載しています。

もう 1 つの大きな変更点は、WebKit 接頭辞を削除することです。目的は、Blink 接頭辞を使用することではなく、(コンパイル時フラグだけでなく)ランタイム フラグを使用することです。

Android WebView は大きな課題でしたが、HTML5Test によると、状況は改善しています。1 つのウェブ プラットフォーム API セットをどこでも利用できるという点で、デスクトップにかなり似ています(ウェブ オーディオはその好例です)。

では、ソーセージ マシンはどのように機能するのでしょうか。Blink に加えるすべての変更は、すぐに 30,000 件を超えるテストを経て実行されます。さらに、後で追加の Chromium テストが実行されることは言うまでもありません。何千ものボット、何千ものベンチマーク、システムを使用して 24 時間体制の保全を実施し、エンジンで膨大な数の壊れたウェブページを捨てて、サービスが行き詰まらないようにしています。Google では、モバイルの速度が非常に遅いことを認識しており、この点の改善に努めています。

何が新しいのでしょうか

  • ウェブ コンポーネント: Eric Bidelman の講演をご覧ください。
  • ウェブ アニメーション: 可能な限り GPU を使用する、複雑で同期された高パフォーマンスのアニメーション。
  • 部分レイアウト: 必要なもののみを計算します。
  • CSS グリッド
  • レスポンシブ画像: srcset、srcN、?
  • テキストの自動サイズ調整の高速化とサブピクセル フォントの一貫性
  • Blink で使用されているグラフィック システム Skia が Windows で GDI から DirectWrite に移行

ぜひお聞かせください。

C++ を身近に感じ、C++ を一緒に記述したいとお考えなら、コードはすべてオープンです。誰かに伝えたり、私たちに伝えたりする必要はありません。パッチを投稿するか、バグを報告するだけです。

スライド: Blink

セキュリティ

執筆者: Parisa Tabriz

今日、かつてないほど多くの人がウェブを利用するようになり、多くの場所から接続しています。

私たちはノートパソコン、スマートフォン、タブレットなど、個人所有のデバイスやアクセサリもすぐに接続できるようにしています。私たちは、信頼できないネットワークや、場合によっては悪意のあるネットワークからインターネットにアクセスしています。私たちの生活の多くがオンラインに移行しているため、データとユーザーのデータを保護するための措置を講じることが不可欠です。分析できます

何よりも、開発者は SSL の必要性と実用性を理解する必要があります。

SSL とはSecure Sockets Layer の略で、インターネット上で通信のセキュリティを確保するために設計された暗号化プロトコルです。暗号化と整合性を介してプライバシーを保証し、インターネット接続の傍受や改ざんを防ぎます。SSL には欠点がありますが、インターネット上でのあらゆるデータ通信のセキュリティを確保するための主要な手段であり、実際には唯一の方法です。

SSL Pulse によると、1 年前の SSL 導入率は約 15% 弱でした。導入率は 50% を超えています

2 つの頭字語:

  • TLS: ほとんどのインテントと目的において SSL と同じです。正確には、SSL 3.1 は TLS に名称変更され、TLS は IETF 標準の名前となっています。どちらも互換性があります。

  • HTTPS: SSL と標準 HTTP のセキュリティ機能の階層化された HTTP over SSL です。まず、クライアントとサーバーのハンドシェイクを行い、公開鍵/秘密鍵暗号を使用して共有鍵を作成します。これは、SSL プロトコルの 2 番目の部分で通信を暗号化するために使用されます。

インターネット上のネットワーキングは、安全で、即時、速いと感じられるかもしれません。ウェブサイトと直接やり取りしているような感覚です。しかし実際には、直接的なつながりはありません。Google の通信は Wi-Fi ルーター、ISP、場合によってはお客様のデバイスとウェブサイト間の仲介プロキシを経由して行われます。HTTPS を使用しないと、通信はすべて書式なしテキストになります。

問題は、ユーザーが HTTPS を含む完全な URL を入力することはめったになく、HTTP を使用してリンクをクリックしてしまうことです。さらに悪いことに、中間者攻撃を仕掛けて HTTPS を HTTP に置き換えることも考えられます。そのためのツールが 2009 年に導入された SSLstrip というツールです。Firesheep は 2010 年に、オープンな Wi-Fi ネットワークで Cookie が平文で送信されるのを聞き取りました。つまり、ユーザーはチャットで聞いたり、誰かの Facebook アカウントにログインしたりできるということです。

しかし、SSL は(比較的)安価で、迅速かつ簡単に導入できます(ssllabs.com と Ilya Grigorik の著書「High Performance Browser Networking」を参照)。公開鍵のピン留めは、ウェブサイトの運営者がサイトの証明書を実際に発行できる認証局を制限するための機能です。

「今年の 1 月(2010 年)に、Gmail はすべてでデフォルトで HTTPS を使用するように変更されました。このために、追加のマシンや特別なハードウェアをデプロイする必要はありませんでした。Google の本番環境のフロントエンド マシンでは、CPU 負荷の 1% 未満接続あたり 10 KB のメモリネットワーク オーバーヘッドの 2%...

SSL は計算コストが高くないということを覚えておいてください。

Overclocking SSL、Adam Langley(Google)

最後に、最も一般的なバグをいくつか紹介します。

  • 混合コンテンツ: HTTP と HTTPS を使用しているサイト。コンテンツを読み込むには権限のボタンをクリックする必要があるため、ユーザーはイライラします。(Chrome と Firefox では、実際には iframe からの混合コンテンツは制限されます)。相対 URL またはスキーム相対 URL を使用して、HTTPS ページ上のすべてのリソースが HTTPS で読み込まれるようにします(例: <style src="//foo.com/style.css">)。
  • 安全でない Cookie: HTTP 接続を介して暗号化されていない状態で送信されます。Cookie ヘッダーに secure 属性を設定して、この問題を回避します。また、新しい「Strict Transport Security」を使用して、SSL を必須にするよう 。

要点

  • ユーザーのプライバシーと完全性を重視するのであれば、SSL を使用する必要がありますこれまで以上に速く、簡単、お手頃な料金で。
  • 混合コンテンツのバグや、適切な HTTP ヘッダービットの設定の誤りなど、実装における一般的な問題を回避してください。
  • 相対 URL またはスキーム相対 URL を使用します。
  • HSTS や証明書のピン留めなど、便利な新機能をお試しください

スライド: SSL 対応

マルチデバイス ウェブ向けのメディア API

執筆者: Sam Dutton &ヤン・リンデン

ウェブ上に新しいデバイスやプラットフォームが普及するのに伴い、音声、動画、リアルタイム コミュニケーションの分野でも飛躍的な成長を遂げています。オンライン メディアは、あらゆる種類のメディアの利用方法を変革しています。

英国政府の調査によると、成人の 53% が「メディア マルチタスク」を楽しんでいますモバイル デバイスを使用してメディアを共有、視聴する。多くの国では、テレビの視聴が減少し、オンライン視聴が増加しています。たとえば、中国では、2012 年の北京の世帯でテレビを視聴したのはわずか 30% で、2009 年の 70% から減少しています。W3C Highlights 2013 によると、「この 1 年で、モバイル デバイスでの動画視聴は 2 倍に増えました。米国では今年、1 日あたりの平均デジタル メディア利用時間がテレビの視聴時間を上回る。視聴はもはや受動的な行為ではなく、米国では、エンターテイメントの消費者の 87% が、テレビを見ながらセカンド スクリーン デバイスを 1 つ以上使用すると回答しています。Cisco によると、動画では...2017 年までに世界の消費者トラフィックの 80 ~ 90% の範囲になる見込みです。これは、毎秒約 100 万分の動画に相当します。

ウェブ デベロッパーには何があるでしょうか。オープンウェブ向けのメディア API のエコシステム: 複数のプラットフォームで動作する標準化された相互運用可能な技術。

要点

  • ブラウザでリアルタイム通信を提供する WebRTC が、モバイルとパソコンで広くサポートされるようになりました。WebRTC エンドポイントの数は、すでに合計で 12 億を超えています。
  • ウェブ オーディオは、音声の合成と処理のための高度なツールを提供します。
  • Web MIDI は Web Audio と統合されており、MIDI デバイスを操作できます。
  • 現在、音声要素と動画要素は、モバイルとパソコンのブラウザの 85% 以上でサポートされています。
  • Media Source Extensions は、アダプティブ ストリーミングとタイムシフトに使用できます。
  • EME は、保護されたコンテンツの再生を可能にします。
  • 文字起こし、字幕、track 要素により、字幕、字幕、時間指定メタデータ、ディープリンク、ディープリンクが有効になります。

スライド: マルチデバイス ウェブ向けのメディア API