Hatena::ブログ(Diary)

あすのかぜ Twitter

2016-06-15

iframeのアプリケーションにPermissionを委譲する仕様

Permission Delegation To Embedded Web Applications

iframeで埋め込まれたクロスオリジンのWebアプリケーションがPermissionを要求するとこともあります、しかしユーザにとっても分かりづらく、扱いづらい点があります。Googleの調査でも、ユーザはiframe内のアプリケーションによるPermission要求を正しく理解していないという結果が出ているようです。


W3Cでは、公式のドキュメントにはなってませんが、「Permission Delegation To Embedded Web Applications」という、 iframeなどで埋め込まれたWebアプリケーションへのPermission委譲の仕様が議論されています。Chromeでも実装への議論がメーリングリスト上で行なわれています。


基本的に、埋め込む側がPermissionを保持し、そのPermissionを埋め込まれた側に委譲する仕組みです。こうすることで、ユーザとしてもどのオリジンにPermissionを許可しているか分かりやすくなります。ブラウザがPermissionを記憶したり解除する際もiframeを埋め込んでいるオリジンの管理だけで良くなりますし、管理画面も分かりやすくなるでしょう。


さらに、今までは埋め込まれる側がPermissionを要求することを規制できませんでしたが、委譲方式をとることで埋め込む側がコントロールできるようになります。


ただし、互換性の問題や、ユーザは今まで通り自身でPermission管理を行いたいという要望もあるかもしれません。


委譲方法

委譲方法は、iframeの属性に指定する方法と、JavaScriptから実行する方法があります。


以下の通り、permissionsに要求するpermissionを指定することで委譲することが出来ます。

<iframe id="embedee" src="https://maps.example.com/" permissions="geolocation"></iframe>

また、Javascriptからnavigator.permissions.delegateと実行することで指定されたiframeにPermissionを委譲出来ます。

var iframe = document.getElementById('embedee');
navigator.permissions.delegate({embedee: iframe, name: 'geolocation'}).then(
  function() {
    // Delegated geolocation.
  }).catch(function() {
    // Delegation failed.
  });

JavaScriptからは委譲を辞めることも出来ます。

navigator.permissions.undelegate({embedee: iframe, name: 'geolocation'});

2016-06-13

Go実装のWebサーバ CaddyのQUICを試す

2016/060/15追記

  • alt-svcヘッダのセットは、有効な証明書を使用したhttpsで行う必要がありました
  • ブラウザは53.0.2768.0 (Official Build) canaryでのみ動作確認しました


Go実装のWebサーバであるCaddyが実験的にQUICのサポートをしました。簡単に動かしてみます。


Caddy

-quic オプションを指定して起動するだけでQUICが有効になります

go get github.com/mholt/caddy/caddy
GOPATH/bin/caddy -config Caddyfile -quic

Caddyfileは特殊なことはありませんが、ブラウザでアクセス出来るようにTLSの設定と、alt-svcヘッダでQUICに対応している事をブラウザに通知します

:443

tls server.crt server.key
header / {
  alt-svc "quic=\":443\"; ma=2592000; v=\"34,33,32\""
}

アクセスする

Chromeでアクセスると、こんな感じでQUICで通信していることが割ります。

f:id:ASnoKaze:20160613233843p:image


うまくいかない場合は

ブラウザのQUICが有効になっていること、alt-svcを読み込めてる事を確認すると良いと思います


Chromeはそれぞれ下記の内部ページを参照のこと

  • chrome://net-internals/#alt-svc
  • chrome://net-internals/#quic
  • chrome://flags/

2016-06-08

Feature Policy、ブラウザの特定機能を無効にする仕様

W3CでFeature Policyという仕様が議論されています。仕様は著者であるGoogleのIlya Grigorik氏のリポジトリ(URL)より確認できます。


このドキュメントはまだW3C公式のドキュメントとはなってはいませんが、先月行われたFace-to-Faceのミーティングでも議論がされています(議事録)


Feature Policy

セキュリティやパフォーマンスの観点で、Webデベロッパーがブラウザの特定のAPI(機能)を無効にしたい場合もあります。


そこで、 Feature-Policyヘッダを用いて以下のようにブラウザの機能を制限できるようにするのがこの仕様です。


また、このFeature-Policyヘッダは現在IETFで議論が行われている"A JSON Encoding for HTTP Header Field Values"(URL)というHTTPヘッダ値にjson形式を用いる仕様を利用している点も興味深いです。


なお、このFeature Policyを利用するためには、HTTPSである必要があります( HTTPS stateがmodernかつ、 potentially trustworthyなURL)


sample1

webrtc及び、geolocationを無効にする

  Feature-Policy: {"disable":["webrtc","geolocation"]}

sample2

https://example.comにおいてgeolocationを無効にし、javascriptからdocument.cookieへのアクセスがあった場合はレポートを送信する(ブロックは行わない)

レポートはReporting APIの仕様(URL) で定義されています。

  Feature-Policy: {"disable":["geolocation"], "target":["https://example.com"]},
          {"disable":["cookie"], "mode":"report", "report-to":"default"}

sample3

同期のxhr, asyncのないscript読み込み、document.writeを無効にし、違反があった場合はレポートする

  Feature-Policy: {"disable":["sync-xhr","sync-script","docwrite"], "report-to":"perf-violations"}

Directives

Feature-Policyでは、以下のディレクティブをして出来ます

  • mode: enforceかrepotを指定します。reportの場合はレポートのみを行うモードです
  • target: Feature-Policyを適応するオリジン配列
  • report-to: Reporting API(URL)で定義される、レポート先
  • disable: 無効にする機能

指定できるAPI

Feature-Policyで無効に出来る機能は、今のところ以下のとおりです

  • cookie: document.cookieへのアクセス
  • domain: document.domainへのアクセス
  • docwrite: document.writeへのアクセス
  • geolocation: Geolocation API
  • midi: Web MIDI API
  • notifications: Notification API
  • push: Push API
  • sync-script: sciprtタグで読み込まれるjsでasyncやdeferのついていないもの
  • sync-xhr: 同期xhr
  • webrtc: WebRTC