2.2 コンテンツ

メタデータの次は，そのURLから始まるコンテンツやサービス自体について考えてみましょう。

最もシンプルなのがHTTP GETによる情報の取得です。メソッド自体は今までのWebの世界と同じではありますが，この用途に最適なコンテンツの種別が今までとは違ったものになってくるでしょう。このあたりは第1回で説明したとおりです。

また，HTTP GETによる単純な情報取得で終わらず，ブラウザ内でWebアプリケーションを利用することも当然ながら可能になります。サービス提供者側は，リアルワールドにフックを仕込み，うまくWebサービスにつなげて行くようなサービス設計の発想が要求されます。

本領発揮するHTML5

上のメタデータの応用例で挙げたDeep Linkのように，アプリとの連動機能を利用する手もあるとは言え，基本的にはWebでのサービス提供をまず考えることになります。

WebブラウザまわりでもService WorkerやWeb Pushのようなイノベーションが進んでいて，従来ネイティブアプリに対して遜色のあった部分が徐々になくなってきつつあります。

Physical Webのようなプラットフォームも，そのような分野の進展と合わせ，Webへの回帰を推進するシナジーとなるかもしれません。

また，それだけでなく，今までになかったタイプのサービスが提供できるのではないかと考えられないでしょうか。

今までにないWebアプリケーション

あまり知られていませんが，例えばWebNFCと言ったような規格もあります。

イベント会場に近づくと，入り口に設置されたビーコンからイベントサービスのURIを受信し，そのWebページを開いて入り口にあるカードリーダーでNFCでチェックイン，と言うようなWebアプリケーションの提供も可能になるかもしれません。

またWeb Bluetoothと言うものも一応存在します。基本的にはiOSやAndroidのネイティブSDKにおけるBluetooth関係のAPIに相当するものをFirefox OSなどのOSで使うためのものであって，いわゆるWebブラウザのための機能ではないのですが，こういった機能がPhysical Webと連動するWebブラウザでも使えるようになると面白いのではないでしょうか。

家電に近づけばそこに仕込まれたビーコンが飛ばしたURLを拾います。Webブラウザで開くと，その家電をBluetoothで操作するコントローラがWebアプリケーションとしてそこに表示されている，と言うのはどうでしょう。Physical Webのブラウザを開けば，まわりにある機器のコントローラがすでに手元に集まっている，ということも可能になるかもしれません。

NFCやBluetoothなど，周囲のデバイスとのインタラクションを行う機能がWebブラウザに搭載されていても，今までは嬉しさがあまり無かったかもしれませんが，Physical Webと組み合わせることで価値が変わってくるものもあるでしょう。

課題

spamや不健全コンテンツ

情報のフックが増えてくるとspamの問題が出てきます。URIを受信したブラウザアプリケーション，第3回で紹介したMetadataのリゾルバの2箇所において，何らかのフィルタリング技術が求められるのではないかと考えられます。

また，アダルトコンテンツなどの不健全コンテンツがむやみに発信されるという可能性もあります。看板や張り紙などは，法律や条例で規制がされています。ビーコンを利用した場合も，公衆における情報配信になってしまうところもあるので，フィルタリングなどの技術だけでは解決できず，何らかの法律的な規制が必要になるのかもしれません。

パーソナライズされたサービスにおけるセキュリティ

フィッシング

ビーコンから始まるWebサービスなどでは，ログインが要求される事もあるでしょう。ダミーのログイン画面のURLを発信し，パスワードを抜き取ろうとするようなフィッシングビーコンの登場の可能性もあります。

自動化は出来ない？

あるビーコンの横を通ったら自動でチェックインさせられないか，というような種類の要求もあるでしょう。しかし特定URLへの1回のアクセスで何らかのデータ変更ができてしまう場合，CSRFと同じ問題が発生します。

ビーコンが発信してるURIさえわかれば，同じURIを発信するビーコンを用意して全然関係ない場所に置き，その横を通り過ぎたユーザにチェックインさせてしまうことが出来てしまいます。

ユーザがトリガーを引く画面は用意して，その裏ではCSRF対策と同じようにワンタイムトークンなどを利用した対策が必要になるでしょう。

また，Metadata Resolverを通すアーキテクチャは，そもそもが自動アクションには向いていません。

ビーコンの詐称

トークンを使った対策をすれば良いだけかというと別の問題もあります。本当にそのビーコンの横を通ったかと言うチェックのことを考えなければなりません。クーポンのように積極的にばらまいても良いものなら問題ないですが，「⁠必ずそこを通った人にだけ特典を与えたい」という場合，その保証は簡単ではありません。

ビーコンが発信しているURLを確認し，同じURLを発信するビーコンを別の場所に用意する，と言うことが簡単に出来てしまうからです。

あくまで応急処置的な一例ではありますが，次のようなものも考えられるでしょう。

ビーコンは定期的に有効期限に制限のついたトークンをバックエンドのサーバに発行してもらい，そのトークンを含めたURLを発信するようにします。

ユーザからアクセスを受けたWebサービスは，そのtokenが有効なものかどうか検証を行います。

ビーコン自体の盗難や，ビーコンが行うバックエンドのやり取りが漏れる可能性にも注意を払わなければなりません。

これらのように，今までのWebのサービスとはちょっと違うタイプの課題があり，それらを解決していかなければなりません。