Web5Gとはなんなのか

W3Cでは、「Web5G」を掲げ5G及び関連するネットワークの進化に向けて、それにあわせたWeb標準技術・APIを模索しているようである。

個人的な印象としては、ネットワークレイヤとWebアプリケーションレイヤが連携するようなイメージでいる。ネットワークを性能ごとに切り出して提供するネットワークスライスや、ネットワークエッジで処理を行うモバイルエッジコンピューティング(MEC)を具体的に想定しているものもあれば、そうでないものもある。

すでに幾つかの資料がネット上に上がっており、僕は5Gは全然詳しくないが、今回は「Web5G Roadmap」と「Web5G Workshop」を眺めつつ、どのような事が思い描かれているかみていく。

5Gとどのように関わるかわからないが、BBCのネットワークエッジまで HTTP over QUICマルチキャストで配信する例は非常に興味深い

Web5G Roadmap

W3Cのロードマップの中に「Web5G Roadmap」というページがある。既に標準化が進められている仕様の他に、「Features not covered by ongoing work」として将来思い描いている機能の一部が紹介されている。

特に「Network Control」に書かれている部分は興味深い

Real-time adaptative to live network conditions

エッジに設置され使用されるマルチアクセスエッジコンピューティング（MEC）によって、現在のネットワーク環境をリアルタイムにサーバ（クライアントへも？）に通知されるようなネットワークの登場が考えられている。そのときにブラウザはアプリケーションにどのような情報を提供すれば良いのか考えているようだ

セルラネットワークから、サーバへの情報提供可能にするメカニズムとプロトコルはIETFで議論されているようだ。
「Mobile Throughput Guidance Inband Signaling Protocol」

Adaptation to cost of network operations

以前書いた、Mobile Data Plan Sharing APIのように、ユーザでデータPlanと連携する仕組み。ユーザが使っていない時にあわせてバックグラウンドで同期する仕組みなどを一般化できるか考えているようだ
asnokaze.hatenablog.com

Network-provided optimizations

WebRTCでは、アプリケーションプロパイダがNATやファイアウォールを超えるためのリレーサーバ(TURNサーバ)を提供しています。

ネットワーク事業者がこれらをサービスとして提供できるようなる仕組みが、「Operator-Assisted Relay Service Architecture (OARS)」で考えられている

Prioritization in enterprise networks

AppleとCiscoは、ビジネスアプリケーションに最適化されたエンタープライズネットワークを提供するために協力してきました(URL)。これをWebアプリケーションへも拡張できるか？

Web5G Workshop

5/10 ~ 5/11にかけてイギリスで「W3C Web5G Workshop」が行われました。その資料が上がっているので幾つか絵を紹介する

Enabling the thrilling applications that will drive usage of 5G networks

Web技術やプロトコルの進化や利用の広がりがまとめられている(ppt URL)。その中で「Integration of the Network Protocol Layer」というスライド、Webとネットワーク制御レイヤが連携する図が出ている。

以下の図では2つの例が出ており、ブラウザからネットワークの情報を取得したりパラメータをセットする。

• ブラウザから、Network Controle Endpointに対し現在のネットワーク状況を問い合わせ取得する。取得した情報をJavaScript APIでアプリケーションに提供する
• ブラウザからNetwork Controle Endpointに対してnetwork adaptationを要求し、ネットワークに対してQoSが設定される

Network advances for Media: Server Push

BBCの発表(スライドURL)。動画は、MPEG-DASHでユニキャスト配信されており、その量が増えているという話のようだ。

そのなかで、ネットワークエッジにデバイスを設置し、そこまでマルチキャストで配信して、そこからユニキャストで配信などやっているようである。

BBCではQUICの利用を考えているようで、IETFでもQUICを用いたマルチキャストやサーバプッシュに関する拡張を提案している。

• Hypertext Transfer Protocol (HTTP) over multicast QUIC
• Unbound Server Push (USP) for HTTP/QUIC

workshopでのこの一枚が象徴的で、ネットワークエッジまで HTTP over QUICマルチキャストで配信し、そこから先をユニキャストで配信することを考えているようである

Immersive Web & 5G

サムスンのWeb, XR, 5Gに関する発表(スライドURL)。

おそらく、低レイテンシで帯域が増えるとゲームやXRにとって良いという話

The evolution of the Web to enable greater network collaboration

IETFでのworkの話。レイヤが違くてあまり良くわからない...

• IETF Work on network to application signaling
• An Architecture for Transport Services

Web5Gとはなんなのか

よく分からない

プロトコルにおける「堅牢性原則」は害悪か

Internet Architecture Board (IAB)でもあるMartin Thomson氏から「The Harmful Consequences of the Robustness Principle」という文書が提出されている。

これは、堅牢性原則(Robustness Principle)について言及している文書である

Robustness Principle

プロトコルの設計と実装に関する原則として、「送信するものに関しては厳密に、受信するものに関しては寛容に」と掲げる堅牢性原則(Robustness Principle)というものがある。

TCP/IP, SMTP, DNS, FTPなどの開発に関わった故ジョン・ポステル氏によって提唱され、ポステルの法則とも呼ばれている。

Wikipedia(ジョン・ポステル)によると

元々はポステルがTCPを規定した RFC793 において
相互運用性を確保するためにTCPの実装が持つべき性質として要約した節が
より一般化されて知られるようになったものである。

と書かれている。

当時の仕様の曖昧性や解釈の違い、実装のバグなどがあったとしても、極力通信が続けられるようにという原則である。プロトコルがデプロイされ使われるようにするため、このような原則となっている。

1996年に発行された RFC1958 Architectural Principles of the Internetでも「Be strict when sending and tolerant when receiving」と書かれている。

The Harmful Consequences of the Robustness Principle

提出された「The Harmful Consequences of the Robustness Principle」では、堅牢性原則(Robustness Principle)では、バグのある実装との通信を可能とするために受信側が寛容性を持つと、バグを定着させることになり、長期的なプロトコルのメンテナンス(拡張)を難しくすると述べています。

JSONの例があげられており、元の仕様であるRFC4627「The application/json Media Type for JSON」ではUnicodeの処理、オブジェクトメンバーの順序付け、数値のエンコーディングなど、詳細に書かれておらず、実装によってさまざまな解釈がされた。更新された RFC7159でも問題は解決されておらず、サブセットを定義し問題ある部分の仕様を禁止したRFC7493 I-JSON とも相互運用できていない。そのため、広くは使用されておらずJSONパーサは、[ECMA262]で指定されたより正確なアルゴリズムを実装している。

その他にもTLSのバグのある実装と通信を可能にするためのワークアラウンドが行われていることや、HTTP/1.1の仕様の曖昧性を無くすために数年の労力を要したことなどがあげられている。

そのためこの文書では、堅牢性原則(Robustness Principle)よりも、初期設計やデプロイを超えて長期的なプロトコルのメンテナンスの継続を推奨しています。

エラーハンドフィングとフィードバック

プロトコルのメンテナンスするうえで、実装しデプロイしている人からのフィードバックが重要です。

エラーハンドリングについては、仕様に不正状態の取扱について記述されていることが理想的です。そして実装は、エラー状態からの回復を試みるのではなく、致命的なエラーとすることでそれを改善する動機を与えます。

また、自動化されたエラーレポートの仕組みは、デプロイされたプロトコルのより良いフィードバックを得ることが出来ます。実装者に不具合をレポートする仕組みは優れていますが、ユーザのプライバシに留意する必要があります。

所感

ここ数年だけを外から見ても、ossification(硬直化)と言われているように、プロトコルのメンテナンスに対するコストは上がっているように見える。エラーハンドリングやレポーティングの仕組みが充実していくのは非常に喜ばしい一方で、やはり実際に通信するためバグ実装に対するワークアラウンドが出てくるのはどうしても不可避に感じる。

HTTPの仕様改定がまた始まっているように、プロトコルのメンテナンスは継続して進めていかれるのは明らかであるし、続けていかなければならない。そのために、より良い仕組みや考え方が広まっていけばいいなあと思いました。

TLSにおけるTicketRequest拡張の提案仕様 (RFC 9149)

(追記) 2022年、RFC 9149として標準化されました

==
Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。

TLSはあまり詳しくないのですが簡単に読む

TLS session ticket

まず、TLS session ticketとセッション再開について確認する

TLSでは一度ハンドシェイクを行った相手と、セッションを再開するための手順が用意されています。これにより処理量を少なくできます。

セッション情報を暗号化しTicketとしてクライアントに渡すことで、サーバ側はセッション再開のために情報を保持しておく必要がなくなります。

Ticketに関する拡張仕様は、RFC5077「TLS Session Resumption without Server-Side State」で標準化されていますし、TLS1.3の仕様でもTicketに関する定義がされています。

• TLS1.3の仕様では、最初のハンドシェイクの際にクライアントがFinishedを送った後に、サーバからNewSessionTicketメッセージでticketをクライアントに発行します。

• 以降セッションを再開する場合は、pre_shared_key拡張を付与してセッションの再開を行います。セッションの再開ですので、サーバから「Certificate」「CertificateVerify」は送信されません。

TicketRequest概要

現在の仕様でも複数のticketを発行できますが、その発行する数はサーバが決めています。

Appleの人らが提案している「TLS Ticket Requests」では、クライアント側からticketを要求できるようになっています。これによって、クライアント側から必要なだけticketをサーバに要求できます。

例えばHTTPSなどの通信では、同じサーバに対して複数のコネクションをはる場合もあります。それはクライアントが並列数を選ぶので、欲しいticketの数をクライアントが決めるのは合理的です。

同じticketは1回のみ使用されるべきですので、クライアント側から要求すればticketが少なすぎることもなくなりますし、逆にサーバ側から過剰にticketを発行することも防げます。

TicketRequest拡張

ハンドシェイク時にticket_request(TBD)拡張を送ることで、TicketRequestに対応しているかネゴシエーションを行います。

お互いに対応していれば、ハンドシェイク後にTicketRequestメッセージを送ることでticketを要求できます。

   struct {
       opaque identifier<0..255>;
       opaque context<0..2^16-1>;
   } TicketRequest;

Cross-Origin Read Blocking (CORB) とは

追記20180606
Chrome独自と書いていましたが、「Fetch Standard」に取り込まれていることを確認しました

---

すでに、Chromeで「Cross-Origin Read Blocking (CORB) blocked cross-origin response」というエラーが出るようになっております。imgタグからクロスオリジンでhtmlファイルを取得したり、タグとレスポンスのcontent-typeが一致してない場合に出ます。

もともと、このChromeにCross-Origin Read Blocking (CORB)という機能を実装するという議論が、blink-devのメーリングリストに投稿されています。

「Cross-Origin Read Blocking (CORB)」 に詳しい説明があるので、CORB とはなんぞやと簡単に説明を読んで見る。

CORBはまだChromeで議論されている仕組みであり、他のブラウザやクライアントでそのまま適応されるものではない点注意

Cross-Origin Read Blocking (CORB)

CORBとは、一言でいうと、ある種の攻撃を防ぐために、画像デコーダやJavaScriptエンジンがクロスオリジンのリソースを読み込む前にブロックする仕組みです。

imgタグやscriptタグは他のドメインのリソースを読み込むことが出来ます。これは、Cookieが付くのでそのユーザのみがアクセス出来るリソースだったり、そのユーザが属しているプライベートネットワークのみからアクセスできるリソースだったりします。

例えば、下記のように他ドメインのjsonファイルを読み込むような下記要素を用意します

<script src = "https://example.com/secret.json">

XSSI攻撃といった、JavaScript Arrayコンストラクタを上書きすることで内容を読みとることができたり。その他にも多くの攻撃手法が見つかっています。(参考PDF)

また、img要素でも、ロードしメモリ上に配置された後にサイドチャネル攻撃でその中身を読み取る方法も可能性としてあります。

<img src="https://example.com/secret.json">

CORBはクロスドメインのリソースにおいて、JavaScriptエンジンや画像デコーダが受取る前に読み込みをブロックする仕組みのようです。

CORBにおけるブロック

CORBによって保護される必要があると判定された時、レスポンスは以下のように変更されます

• レスポンスボディが空になる
• レスポンスヘッダは下記のものに絞られる
  • CORS-safelisted response-header
  • CORS response headers

対象となる読み込み方法

下記の手段で取得されるリソースが、CORB保護対象となり得る

• XHR and fetch()
• ping, navigator.sendBeacon()
• <link rel="prefetch" ...>
• “image” requests like <img> tag, /favicon.ico, SVG‘s <image>, CSS’ background-image, etc. script-like destinations like <script>, importScripts(), navigator.serviceWorker.register(), audioWorklet.addModule(), etc.
• “audio”, “video” or “track”
• “font”
• “style”
• “report” requests like CSP reports, NEL reports, etc.

<iframe>, <object>, <embed>は別のセキュリティで保護されており、別のプロセスで実行されるため推測は困難（らしい

レスポンスがCORBで保護されるかの条件

レスポンスがJSON、HTML、XMLの場合に保護対象になります。

• X-Content-Type-Options: nosniffの場合、Content-TypeがHTML MIME type・JSON MIME type ・XML MIME type・text/plainの場合 (image/svg+xmlを除く)
• レスポンスが206の場合、Content-TypeがHTML MIME type・JSON MIME type ・XML MIME typeの場合 (image/svg+xmlを除く)
• それ以外の場合はレスポンスボディを確認します
  • HTML MIME type のうちHTMLとだと思われるもの
  • XML MIME typeのうちXMLだと思われるもの
  • JSON MIME typeのうちJSONだと思われるもの
  • text/plainのうちJSON, HTML, だと思われるもの

上記MIME typeの定義はこちら

• https://mimesniff.spec.whatwg.org/#html-mime-type
• https://mimesniff.spec.whatwg.org/#json-mime-type
• https://mimesniff.spec.whatwg.org/#xml-mime-type

demo

オプションを付けて起動すると動作するらしい
https://anforowicz.github.io/xsdb-demo/index.html

consoleに下記のように表示される

Blocked current origin from receiving cross-site document at https://www.chromium.org/ with MIME type text/html.

その他

ドキュメントには、現在のWebへの影響・互換性や、さらに詳しいアルゴリズムなどの解説などもある

Chromeにおいて非セキュアなHTTPで送信されたCookieの有効期限を短くする議論

暗号化してないHTTPで送信されたCookieの有効期限を短くしたいという議論は、Mozillaでも以前から行われてきました。「Intent to ship: Treat cookies set over non-secure HTTP as session cookies」。

もちろん、IETFでもMozillaのMartin Thomson氏らによって同様の提案がされています。
asnokaze.hatenablog.com

それに続く形で、Chromeでも非セキュアなHTTPで送信されたCookieの有効期限を短くするかという議論が行われています。

Intent to Deprecate: Nonsecurely delivered cookies.

Intent to Deprecate: Nonsecurely delivered cookies

この議論は、Webのセキュリティに関する標準化界隈で活発に活動されているGoogleのMike West氏によるMLへの投稿で始まっています。

非セキュアなHTTPで送信されたCookieの有効期限を、例えば1年にすることから初めて徐々に短くしていこうという話です。つまり、フルHTTPSにしてないサービスでは、ユーザは1年に1回ログインをし直す必要が出てきます。

(HSTSかsame-site属性がついてない場合は、第三者によって非セキュアなHTTPでCookieを送信させることが出来るのは、議論の一つとしてあります。)

送信されるCookieの何％が、非セキュアなHTTPで送信してからの時間が立っているかのパーセンタイルも共有されています。

Same-site Requests

• 20% = 0-1 days
• 40% = 2-3 days
• 60% = 37-42 days
• 80% = 120-135 days
• 90% = 273-307 days
• 93.88% = 345-388 days
• 95% = 437-492 days
• 99% = 701-789 days

Cross-site Requests

• 20% = 2-3 days
• 40% = 37-42 days
• 60% = 95-107 days
• 80% = 192-216 days
• 90% = 307-345 days
• 92.7% = 345-388 days
• 95% = 437-492 days
• 99% = 701-789 days

議論は始まったばかりですが慎重に進められていくでしょう。
Cookieのセキュリティに関する議論は根強く続けられていますが、すぐには解決できなく難しいですね。。。

ギガの減り方など、ユーザのデータプランを考慮して最適化するGoogleサービス

モバイル通信事業者が、ユーザのギガの残量やデータプランなどをGoogleと共有する、「Mobile Data Plan Sharing API」というものがあるらしい。

モバイル通信事業者に提供されているAPIであり、おそらく一般サービス運営者は利用することは出来ない。

GoogleではこのAPIを通してユーザのデータプランを共有し、様々な最適化を行っているようである。

• ユーザのデータ通信残量を考慮して通信の最適化を行う
• 通信のオフピークに通信を行う

この連携を行うために、モバイル通信事業者が、DPAと呼ばれるデータプランをGoogleのサーバと共有するサービスや、PlanGloupIDを生成するPGID Endpointと呼ばれる機能を実装する必要がある。

すでに、インドの3通信事業者とYoutubeで非ピーク時にデータ通信をさせる実験済みらしい(Web5Gの文章より)。（YoutubeのSmart Offline）

もちろん、サービスやクライアントがどのように最適するかは実装依存である

Mobile Data Plan Sharing API

共有されるデータは、下記のようなデータで
byteBalanceとしてデータ通信残量や、その他データプランのカテゴリが共有される。

もちろん例の他にも、時間制限の場合は時間残量、最高トラフィック量や、制限を超えた場合のポリシーなどが共有される。
詳しくはレファレンスに記載されている。

{
  "planGroupId": "abcdef",
  "planGroup": {
    "dataPlans": [
      {
        "planName": "ACME Red",
        "planId": "turbulent1",
        "expirationTime": "2020-02-03T04:05:06Z",
        "planModules": [
          {
            "byteBalance": {
              "quotaBytes": "1000000000",
              "remainingBytes": "9876543210"
            },
            "trafficCategories": [
              "GENERIC"
            ],
            "expirationTime": "2020-02-03T04:05:06Z"
          }
        ]
      }
    ],
    "responseStaleTime": "2018-03-04T05:06:07Z"
  }
}

その他

正直自分でためせなさそうだし、資料も多くないので、、、
詳しい人がいたら教えてほしい。

HTTP Server Pushのセマンティクス拡張する、HTTP Server *ush の提案仕様

4/1 に「HTTP Server *ush」という提案仕様が、IETFに提出されています。

4/1にです。

HTTP Server *ush

「HTTP Server Push」の音節構造は非常に舌に馴染むものです。HTTP Server Pushの成功の一つの理由でしょう。

そこで、同じ音節構造を持つ様々な「HTTP Server *ush」を定義しようというのが、この提案です。

このドキュメントでは、HTTP/2でサーバプッシュを利用するのに使用された「SETTINGS_ENABLE_PUSH 」と同様に「SETTINGS_ENABLE_*USH 」というSETTINGSパラメータを定義します。

Server Cush

Server Cushはより豪華なHTTP Server Pushです。
SETTINGS_ENABLE_CUSHで有効にすることが出来ます。

Server Dush

Server Dushはより激しいhTTP Server Pushです。
SETTINGS_ENABLE_DUSHで有効にすることが出来ます。

Server Gush

Server Gushは突然のオーバーフローをサポートするHTTP Server Pushです。
SETTINGS_ENABLE_GUSHで有効にすることが出来ます。

Server Hush

Server Hushはより丁寧なHTTP Server Pushです。
SETTINGS_ENABLE_HUSHで有効にすることが出来ます。

Server Kush

Server Kushは適法性が地域によって異なるHTTP Server Pushです。
SETTINGS_ENABLE_KUSHで有効にすることが出来ます。

Server Lush

Server Lushは植物に関係するリソースのためのHTTP Server Pushです。
SETTINGS_ENABLE_LUSHで有効にすることが出来ます。

Server Mush

Mushにはネガティブな意味があります。このServer Pushは予約されており、使用できません

Server Rush

Server Rushはより迅速にプッシュできるHTTP Server Pushです。
SETTINGS_ENABLE_RUSHで有効にすることが出来ます。

Server Tush

Server Tushはサーバがプッシュプロミスに時間がかかりすぎると不賛成するHTTP Server Pushです。
SETTINGS_ENABLE_TUSHで有効にすることが出来ます。

Server Blush

Server Tushはクライアントが望まないプッシュをしてしまうとサーバは恥ずかしく感じるHTTP Server Pushです。
SETTINGS_ENABLE_BLUSHで有効にすることが出来ます。

Server Flush

Server Flushは北半球と南半球のコリオリ効果を考慮したServer HTTP Server Pushです。
SETTINGS_ENABLE_FLUSHで有効にすることが出来ます。

Server Plush

Server Cushと同義です

Server Slush

Server Slushは過度に感情的なServer HTTP Server Pushです。
SETTINGS_ENABLE_SLUSHで有効にすることが出来ます。

Server Smush

Server SmushはServer GushとServer Slushの論理和です
SETTINGS_ENABLE_SMUSHで有効にすることが出来ます。