PEPC explainerを読む
ken7253PEPC
ken7253目的
現在のパーミッションリクエストと比べて下記の項目を目指すことを目的としているっぽい。
- よりアクセシブルなUI
- より安全な権限許可の方法
ken7253今のパーミッションリクエストはChromeであればパーミッションが必要なAPIがコールされるとオムニボックス周辺に許可を求めるプロンプトが現れるという流れになっているがwindowに対して絶対位置なので、イベントを発火させる要素との距離が遠い場合ユーザーがそれを認識しづらいという問題点がある。
explainerより引用
ken7253User Agent abuse mitigations
この章では現在のブラウザのパーミッションモデルの問題点を提起している？
Many user agents implement a "permanent deny" policy, and other user agents offer it as an option in the permission prompt. This means that a site will not be able to ask for permission again after the user has blocked it. Sometimes this is for some fixed (or increasing) duration, not strictly speaking permanent. This helps prevent unwanted permission prompt spam though it can sometimes lead to user confusion if they wish to change their mind later as it requires them to discover the appropriate UI that allows them to make the change manually.
翻訳
多くのユーザーエージェントは "permanent deny "ポリシーを実装しており、他のユーザーエージェントは許可プロンプトのオプションとして提供している。 これは、ユーザーがブロックした後、サイトが再び許可を求めることができないことを意味します。 これはある一定の（または増加する）期間であり、厳密に言えば永久的なものではない。 これは不要なパーミッションプロンプトスパムを防ぐのに役立ちますが、後で変更したい場合、手動で変更できる適切なUIを見つける必要があるので、ユーザーを混乱させることがあります。
ユーザーが許可するまでプロンプトを出し続けるというスパムができないように、一度拒否した権限リクエストはアプリケーション側から再度リクエストができないようになっている。
これは安全であるが間違えて拒否した場合などにユーザーが適切に設定を見つけて権限を有効化する必要があるがそれが難しいよねって話っぽい。
ken7253従来の権限リクエスト
PEPCでの権限リクエスト
A permission model designed to be initiated by the user would solve these issues.
とあるように、従来のパーミッションリクエストはアプリケーションが起点となり権限のリクエストを行うがPEPCではユーザーの権限許可の起点としていることが異なる。
ken7253このようにパーミッションの起点が変わることによって今までは非同期処理で行っていた権限が必要な処理も単純にイベントハンドラーとして実装できるようになるので簡潔に実装できるメリットがありそう。
一方でスタイルやテキストをアプリケーション側で自由に変更できるようにしてしまうと、ユーザーが権限の許可と認識できずに許可ボタンを押してしまう可能性がある。
詳しくはSecurityセクションに記載されているが下記のような対策がされている。
Locking the PEPC style
Permission要素に対してのスタイリングを制限する。
- opacity: Should never be anything other than 1, for the PEPC and all its ancestors.
- cursor: Any values other than the predefined cursors won't have effect (no custom cursors).
Synthetic click events
アプリケーション側で合成したイベントは許可しないようにする。
const permissionButton = document.querySelector('permission');
permissionButton.click(); // NG
実装側
HTML/DOM
permission要素というのが用意されている。
CSS
権限を許可しているかどうかを表す:grantedという疑似セレクタ
スタイルの定義に関してはユーザーエージェント側で制限が課せられる。
User agents should lock down the styling of the PEPC in regards to the color, size, border, rounding, contents, icon, etc. of the PEPC, as outlined below.
記述は見つけられないけどおそらくセキュリティ面などが原因っぽい？
ken7253Standard position
Webkit
Given the above, we are "opposed" to this proposal as it currently stands, but would like to continue to collaborate on a solution.
Mozilla
一度Negativeになったけど撤回された。
ken7253Mozillaのstandard-positionのCloseコメントが結構そうだよねって感じのことを書いている。
追求されている指標は、ユーザーを犠牲にしてウェブサイトを優遇しているようです。コンバージョン率が低いのは、パーミッションが機能している証拠です。コンバージョン率が高いのは、機能していない証拠です。PEPC は後者を追求しているようです。
- ユーザーは以前の「拒否」決定を元に戻すことはできますが、「許可」決定を元に戻すことはできません (Web サイトにはこのオプションを表示する動機がありません)。
- 許可のプライミング フローは、エージェントとユーザーのやり取りを妨害します。ブラウザより先に Web サイトが通知の許可を求めるのは、誰もがよく知っていることです。拒否すると、Web サイトは後で自由に迷惑をかけることができます。許可すると、再度尋ねられ、クリックが無駄になります (1 回許可するブラウザでは、訪問のたびに)。悪質な Web サイトをブロックするのは、専門家の仕事になります (ブロック オプションが表示される目に見えない橋を渡るには、目を閉じて [許可] を押します)。目標は、プライミングを減らすことでしょうか、増やすことでしょうか。
- プライミングと後悔の根本的な原因は解決されていません。なぜ、どのウェブサイトもユーザーをスクリーン共有にプライミングしないのでしょうか? getDisplayMedia は Chrome ではまだ一時的なアクティベーションを必要としないので、それが原因ではないでしょう。Chrome はユーザーの否定的な反応でスクリーン共有をブロックしないからでしょうか? これは、ウェブサイトのプライミングが Chrome UX への反応であることを示唆しています。Chrome UX の修正により、他のブラウザで標準化することなく、この問題に対処できるでしょうか? たとえば、UA は一時的なアクティベーションや、以前のブロックを元に戻す意図を示すその他の肯定的なシグナルを自由に含めることができます。
ken7253補足資料