承認の要求

Geolocation API

[60] 利用者エージェントは、利用者のプライバシーを守るための仕組みを用意しなければなりません。利用者エージェントは、利用者の許可の表明なくして位置情報を提供してはなりません。 >>56

[57] 後段、なぜか禁止と推奨の2回同じような規定があります。禁止の方が強いです。

[61] 利用者エージェントは、利用者が予め設定している場合を除き、利用者インターフェイスを通じて利用者の許可を得なければなりません。当該許可取得利用者インターフェイスは、文書の URL のホストを含まなければなりません。 >>56

[62] 利用者インターフェイスを通じた許可であって現在閲覧セッションを超えて保持されるものは、取り消せなければなりません。利用者エージェントは取消を尊重しなければなりません。 >>56

[58] 例えば集中管理下にある端末で、特定の起源による位置情報取得を管理者が一括して許可しているようなとき、直接の利用者が個別に承認、不承認を変更できない仕組みがあり得ると思われます。

[59] 仕様書は、利用者エージェントによる利用者インターフェイスの違いの例として、 Webブラウザーなら利用者インターフェイスを表示するであろうところ、 VoIP 電話は緊急通報時に利用者インターフェイスを提示しなくても構わないのだと書いています。 >>56 VoIP 電話機能の実装に Geolocation API が使われた事例が実在するのかは謎です。そもそも Webブラウザー以外の実装まで想定して一般化する必要性が謎です。

[63] getCurrentPosition と watchPosition から呼び出されます。

Push API

[36] Push API における express permission とは、利用者による動作であって、例えば利用者インターフェイスやプラットフォーム機能を通じて、 Webアプリケーションが Push API を利用することを承認するものをいいます。 >>35

[39] 利用者エージェントは、利用者が express permission することなく Push API の機能を Webアプリケーションに提供してはなりません >>37。 subscribe メソッドでは、利用者インターフェイスで permission に同意を得るか、以前の同意が有効でなければなりません >>37, >>38。同意済みかの判定にはオプション群 (PushSubscriptionOptionsInit) を考慮できます >>37, >>41。利用者インターフェイスを提示しなければならない場合で、 subscribe がサービスワーカーから呼び出された場合には、拒否とみなさなければなりません >>38。

[55] Push API の permission は持続させる、つまり一旦許可されれば次の subscribe でも許可されているとみなすことができます。 >>45

[40] 現在の閲覧セッションを超えて有効な permission は、失効可能でなければなりません。 >>37 プッシュ購読

[44] PushManager インターフェイスの permissionState メソッドは、次のようにしなければなりません。 >>45

[46] 約束を、新しい約束に設定します。
[47] 約束を返します。

[48] 非同期的に、次のようにしなければなりません。 >>45

[49] 状態を、 Push API の permission の状態に設定します。
[50] 状態がエラーの場合、
1. [51] 約束を、拒絶します。
[52] それ以外の場合、
1. [53] 約束を、 状態 (PushPermissionState) で解決します。

[54] このメソッドは現在の状態をたずねるだけにも関わらず、非同期的な処理になっており、仕様書では要求が云々という記述もあります。 permission の取得に fetch が必要な場合や、プラットフォームの permission の確認に時間がかかることも想定しているのでしょうか。

[43] 列挙型 PushPermissionState は、次のいずれかの値です。 >>42

granted: permission を有します。
denied: permission を拒否されています。
prompt: permission をたずねる必要があります。

利用者インターフェイス

[22] Webサイトによっては、最初の表示の際に承認を要求するので、 Webブラウザーによっては大きく表示されてとても邪魔です。

[23] いくつかの読み物系のサイトは表示したときに通知権限を要求してきます。たまたま開いただけでどんな記事のあるサイトか知らないうちから通知の承認を求めるのは、ほとんど spam のようなものです。

[24] Chrome では承認のポップアップで許可ボタンにフォーカスが当たるので、うっかり Enter を連打していると意図せず承認してしまうことがあり、問題のあるインターフェイスです。 2016-09-28T06:26:57.500Z

[25] Webブラウザーは、 triggered by user activation でない限り、承認の要求を無視するか、目立たない表示にとどめておくべきだと思われます。

[34] Chrome の確認ポップアップはちょうどブックマークバーに重なるので、いちいち消さないと下が押せなくてうざい。 2018-04-21T04:24:18.400Z

歴史

[1] Proposal for a Permissions API ( (Mounir Lamouri 著, 2014-09-02 22:51:38 +09:00 版)) http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0389.html

[2] Permissions API - Google ドキュメント ( (2014-09-04 13:00:40 +09:00 版)) https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview

[3] Re: Rechartering: Permissions API ( (Mounir Lamouri 著, 2014-11-13 21:16:08 +09:00 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0238.html

[4] The Permissions API ( (2014-11-13 03:39:41 +09:00 版)) https://w3c.github.io/permissions/

[5] The Permissions API ( (2015-04-07 23:47:53 +09:00 版)) http://www.w3.org/TR/2015/WD-permissions-20150407/

[6] dontcallmedom/web-permissions-req ( (2014-08-13 09:56:34 +09:00 版)) https://github.com/dontcallmedom/web-permissions-req/

[7] Re: Permissions API vs local APIs (Jonas Sicking 著, 2015-05-06 06:54:43 +09:00 版) https://lists.w3.org/Archives/Public/public-webappsec/2015May/0010.html

[8] Notifications meetup outcome (Anne van Kesteren 著, 2012-05-01 06:03:37 +09:00 版) https://lists.w3.org/Archives/Public/public-web-notification/2012Apr/0018.html

We discussed the remaining two issues with the specification:
* Given that the DAP WG is no longer working on the permissions
specification we will go with the proposal from Apple to expose the
permission model as static members of the Notification object.

[9] Permissions for Device API Access ( (2015-07-13 14:01:13 +09:00 版)) http://www.w3.org/TR/2015/NOTE-api-perms-20150714/

[10] Permissions for Device API Access (2010-09-30 21:08:41 +09:00 版) http://www.w3.org/TR/2010/WD-api-perms-20101005/

[11] Permissions for Device API Access (2015-06-19 01:25:19 +09:00 版) http://dev.w3.org/2009/dap/api-perms/

[12] Runtime and Security Model for Web Applications (2015-08-04 19:31:42 +09:00 版) http://www.w3.org/TR/2015/NOTE-runtime-20150806/#permissions

[13] The Permissions API (2015-08-26 19:01:12 +09:00 版) https://w3c.github.io/permissions/

[14] Reuse PermissionState from the Permissions API · whatwg/storage@a5ca15e (2016-04-01 19:35:33 +09:00 版) https://github.com/whatwg/storage/commit/a5ca15e4322a9ef97026bfdd52e77fcf3dd9ebfa

[15] Rely on the Permissions API before it is ready · whatwg/storage@ed1e326 (2016-04-02 14:31:12 +09:00 版) https://github.com/whatwg/storage/commit/ed1e326951ea3a012477a4fb45471186bc72839b

[16] 1165263 – Use origin for nsIPermissionManager ( (2016-06-10 18:05:33 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1165263

[17] Re: VC meeting to discuss Permissions spec ( (Anne van Kesteren著, 2016-06-09 18:35:56 +09:00)) https://lists.w3.org/Archives/Public/public-webappsec/2016Jun/0036.html

[18] Add note about permissions ( (andrey-logvinov著, 2016-06-20 19:27:46 +09:00)) https://github.com/w3c/wake-lock/commit/440add20cd09d2c7a519ef9f77ccf9af707eda75

[19] Acknowledge that the permission prompt or heuristic might not result … (annevk著, 2016-06-24 17:10:59 +09:00) https://github.com/whatwg/storage/commit/16cf7db48fec4425ac8a13b10a5bba10edf925eb

[20] Explain the intent behind the persistent permission (annevk著, 2016-06-25 16:29:28 +09:00) https://github.com/whatwg/storage/commit/e1f556d4c62b7cb619048f853f6dd45bcf11bfb2