承認の要求

承認の要求

仕様書

Geolocation API

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

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

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

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

[58] 例えば集中管理下にある端末で、 特定の起源による位置情報取得を管理者が一括して許可しているようなとき、 直接の利用者が個別に承認、不承認を変更できない仕組みがあり得ると思われます。
[59] 仕様書は、 利用者エージェントによる利用者インターフェイスの違いの例として、 Webブラウザーなら利用者インターフェイスを表示するであろうところ、 VoIP 電話緊急通報時に利用者インターフェイスを提示しなくても構わないのだと書いています。 >>56 VoIP 電話機能の実装に Geolocation API が使われた事例が実在するのかは謎です。 そもそも Webブラウザー以外の実装まで想定して一般化する必要性が謎です。

[63] getCurrentPositionwatchPosition から呼び出されます。

Push API

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

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

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

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


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

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

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

  1. [49] 状態を、 Push APIpermission の状態に設定します。
  2. [50] 状態がエラーの場合、
    1. [51] 約束を、拒絶します。
  3. [52] それ以外の場合、
    1. [53] 約束を、 状態 (PushPermissionState) で解決します。
[54] このメソッドは現在の状態をたずねるだけにも関わらず、 非同期的な処理になっており、仕様書では要求が云々という記述もあります。 permission の取得に fetch が必要な場合や、 プラットフォームpermission の確認に時間がかかることも想定しているのでしょうか。

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

利用者インターフェイス

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

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

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

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

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

歴史

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

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

[3] Re: Rechartering: Permissions API ( (Mounir Lamouri 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0238.html

[4] The Permissions API ( ( 版)) https://w3c.github.io/permissions/

[5] The Permissions API ( ( 版)) http://www.w3.org/TR/2015/WD-permissions-20150407/

[6] dontcallmedom/web-permissions-req ( ( 版)) https://github.com/dontcallmedom/web-permissions-req/

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

[8] Notifications meetup outcome (Anne van Kesteren 著, 版) 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 ( ( 版)) http://www.w3.org/TR/2015/NOTE-api-perms-20150714/

[10] Permissions for Device API Access ( 版) http://www.w3.org/TR/2010/WD-api-perms-20101005/

[11] Permissions for Device API Access ( 版) http://dev.w3.org/2009/dap/api-perms/

[12] Runtime and Security Model for Web Applications ( 版) http://www.w3.org/TR/2015/NOTE-runtime-20150806/#permissions

[13] The Permissions API ( 版) https://w3c.github.io/permissions/

[14] Reuse PermissionState from the Permissions API · whatwg/storage@a5ca15e ( 版) https://github.com/whatwg/storage/commit/a5ca15e4322a9ef97026bfdd52e77fcf3dd9ebfa

[15] Rely on the Permissions API before it is ready · whatwg/storage@ed1e326 ( 版) https://github.com/whatwg/storage/commit/ed1e326951ea3a012477a4fb45471186bc72839b

[16] 1165263 – Use origin for nsIPermissionManager ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=1165263

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

[18] Add note about permissions ( (andrey-logvinov著, )) https://github.com/w3c/wake-lock/commit/440add20cd09d2c7a519ef9f77ccf9af707eda75

[19] Acknowledge that the permission prompt or heuristic might not result … (annevk著, ) https://github.com/whatwg/storage/commit/16cf7db48fec4425ac8a13b10a5bba10edf925eb

[20] Explain the intent behind the persistent permission (annevk著, ) https://github.com/whatwg/storage/commit/e1f556d4c62b7cb619048f853f6dd45bcf11bfb2

[21] Permissions store (Anne van Kesteren著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0002.html

[27] Requesting Permissions () https://jyasskin.github.io/permissions-request/

[28] Permissions () https://www.w3.org/TR/2017/WD-permissions-20170925/

[29] Update permission algorithm to link into Permission spec. (garykac著, ) https://github.com/w3c/clipboard-apis/commit/f3cf40df596ac8d9964b723187f9d801bd818538

[30] New in Chrome 63  |  Web  |  Google Developers () https://developers.google.com/web/updates/2017/12/nic63?utm_source=feed&utm_medium=feed&utm_campaign

[31] ビジネスパーソンに送るニュース情報サイト ビジネスジャーナル/Business Journal () http://biz-journal.jp/

[32] このサイト、ページ読み込み時の規制を回避する目的なのか、 Chrome の通知許可ダイアログに見せかけたものを viewport 内に表示するようです。まるでフィッシングサイトですね。

[33] はぜさんのツイート: "物件ファンさん @bukkenfan https://t.co/Iwo9HTJeeG のWebプッシュ通知バー良い. ほとんどのWebサイトが流入と同時にいきなり通知するか聞いてくるし最悪だけど, こういうのが広がってくれるととても嬉しい… https://t.co/otljEwdmIU" () https://twitter.com/haze_it_ac/status/967385442738843648

[64] Chromium Blog: Reducing abusive notification content (, ) https://blog.chromium.org/2020/10/reducing-abusive-notification-content.html