ウェブ権限に関するおすすめの方法

権限プロンプトは、ユーザーのプライバシーとセキュリティに危険をもたらす可能性のある強力な機能を保護するためのウェブの主なメカニズムです。権限プロンプトを使用すると、リクエスト元のウェブサイトに該当する機能へのアクセスを許可する意思がユーザーにあることを確認できます。権限プロンプトは、メディアのキャプチャ(カメラとマイク)、位置情報、ストレージへのアクセス、MIDI、通知など、さまざまな API で使用されます(詳細については、MDN の Permissions API のドキュメントをご覧ください)。

このガイドでは、Chrome の使用状況統計とユーザー調査に基づいて、ユーザーに権限プロンプトを表示するためのベスト プラクティスについて説明します。これらのベスト プラクティスに従うと、ユーザーに不要なプロンプトが表示される回数が減り、デベロッパーが「ブロック」の判断を下す回数も減ります。最後に、権限制限付き API を操作するためのコードパターンと、ユーザーがブロックされた状態から復旧できるようにするためのベスト プラクティスについて説明します。

権限をリクエストするタイミングは、ユーザーがリクエストの理由と、許可することで得られるメリットを理解できるタイミングにする必要があります。可能であれば、ユーザーが別の方法で同じ機能を実行できるようにする必要があります。一般的なガイドラインとして、権限をリクエストするタイミングを慎重に選択してリクエストの頻度を減らすことで、ユーザーが回復が困難なブロック状態に陥る可能性を低減できます。次のベスト プラクティスでは、これらの推奨事項について詳しく説明します。

ページの読み込み時やユーザーの操作なしで尋ねない

ページの読み込み時にユーザーに権限を求めることは、実店舗に足を踏み入れたお客様に機密情報を尋ねるのと同じことです。許可プロンプト(ニュースレター登録や Cookie の同意に関する他の複数のプロンプトとともに表示される)は、非常に不快なものです。ユーザーが位置情報の提供を求められる理由と、位置情報の提供によって得られるメリットを理解していない。

特定の機能にアクセスしないとウェブアプリが動作しない場合は、その機能が必要な理由をユーザーに理解してもらう必要があります。たとえば、権限プロンプトの前に、権限の必要性を説明する独自のプロンプトを追加し、ユーザーに選択肢を提供します(可能であれば、同じ機能を実現するための代替手段を提供するなど)。ページの読み込み時以外に権限をリクエストするタイミングが思いつかない場合は、このガイドの後半にいくつかの例を示します。

権限をリクエストするのに適さない状況として、事前のユーザー操作がない状況(一時的なユーザー アクティベーション)も同様に挙げられます。Chrome テレメトリーによると、パソコン版 Chrome の権限プロンプトの 77% は、ユーザーの意図を示すこのような非常に基本的なシグナルなしで表示され、その結果、そのようなプロンプトの 12% のみが許可されています。ユーザーの操作後、許可率は 30% に増加します。そのため、ユーザーがなんらかの形でページを操作した後にのみ、権限をリクエストしてください。

ユーザーが質問の理由を理解できる場合にのみ質問する

権限に関する判断は、多くの場合プライバシーに関する判断です。コンテキスト整合性フレームワークに基づいて、プライバシーに関する判断はコンテキストに大きく依存することを認識しています。アクセスが必要な理由を理解することが、この点の重要な要素と考えられます。そのため、ユーザーに価値を提供するために必要な機能のみをリクエストしてください(ユーザーが実際に価値を得られることに同意する可能性が高い機能)。また、その機能が役に立つ理由がユーザーにとって明白なタイミングで権限をリクエストする必要があります。使用コンテキストをユーザーが簡単に理解できるようにすることが目的です。

Google のユーザー調査によると、サイトがアクセスを求める理由を理解し、メリットがあると認識しているユーザーは、アクセスを許可する可能性が大幅に高くなります。また、ユーザーは、アクセスを許可することで得られる価値をよりよく理解するために、まず見慣れないサイトを探索することを期待していることもわかっています。多くの場合、ユーザーは権限プロンプトを閉じたり無視したりします。1 回だけのアクセス許可では、最初に 1 回のアクセスを許可する場合があります。アプリはこれらの動作をサポートする必要があります。

可能であれば、同じ機能を実現する代替手段を提供します。

一部の機能の結果は、ユーザーにとって有益ではない場合があります。たとえば、GPS センサーのないデスクトップ デバイスの位置情報は、ユーザーが VPN に接続しているため、間違った位置情報を返すことがあります。他のユーザーは、これらのイベントを自分で制御し、キーの組み合わせで手動でトリガーすることを好むため、クリップボードへのアクセスを許可したくない場合があります。このような場合は、同じ結果を達成するための代替手段を提供することが重要です。たとえば、位置情報の権限をリクエストする場合は、ユーザーが郵便番号や住所を入力できるテキスト フィールドを用意します。クリップボードを使用する場合は、コピーする要素をキーの組み合わせまたはコンテキスト メニューで選択してコピーできることを確認します。通知では、プッシュ通知ではなくメールを受け取るようにユーザーに提示します。

アクセスが有益な理由を説明する際に、代替 UI を使用すると便利です。位置情報 API をトリガーするボタンの横に位置情報を入力するオプションが表示されている場合、ユーザーは住所を入力することもできることを理解しているため、何が起こるかを自分でコントロールしていると感じます。同様に、プッシュ通知とメールのどちらで通知を受け取るか、カメラとマイクのアクセスを許可せずに会議に参加するかを選択できる場合、ユーザーはトレードオフをより自然に理解できます。

ブロック状態に陥らないでください。復元は困難です

ユーザーが権限制限付きの機能へのアクセスを完全に許可しないように決定すると、ブラウザはその決定を尊重します。アクセスを繰り返し求めることができれば、悪意のあるサイトはユーザーにプロンプトを繰り返し表示できます。そのため、ブロックされた状態の権限から復元するには、ユーザーが意図的に少し手間をかけるようにしています。そのため、多くのユーザーがアクセスを許可しない可能性が高い状況では、ユーザーに権限を尋ねないでください。

一般的な方法は、いわゆる事前プロンプトを使用することです。事前プロンプトでは、これから何が起こるか、アプリがリクエストする機能が必要な理由をユーザーに説明します。ブラウザの権限プロンプトをトリガーするのは、ユーザーがこのような事前プロンプトに肯定的に反応した場合のみです。ユーザーがその状態から復元する必要がある正当な理由がある場合があります。詳しくは、ブロックされた状態からユーザーを復元するをご覧ください。

サードパーティのコンテンツに注意する

権限プロンプトの予期しないソースに注意が必要です。サイトにサードパーティ スクリプトを含めると、表示するつもりのない権限プロンプトがトリガーされる可能性があります。特に、そのようなプロンプトがすでに概説されているベスト プラクティスに従っていない場合、ウェブサイトのユーザー エクスペリエンスに影響する可能性があります。ユーザー エクスペリエンスを常に管理できるように、独自のコードに追加するサードパーティのライブラリとスクリプトのドキュメントをよく読んでください。

権限をリクエストするタイミング

以下に、すでに説明したベスト プラクティスに沿って、権限をリクエストするのに適したタイミングの例をいくつか示します。

  • ユーザーが、住所を手動で入力するためのフォーム フィールドの横にある [現在地を使用] ボタンをクリックした後。
  • ユーザーが動画チャンネルまたは投稿を定期購入した後、更新がメールまたは通知としてスマートフォンやパソコンに配信されることを説明するダイアログで肯定的なボタンをクリックした。
  • ユーザーがビデオ通話に参加するための準備ページにアクセスし、事前プロンプトで自分の映像と音声を共有することを肯定的に回答した後(Google Meet のケーススタディを参照)。

権限を求めるコードパターン

API の使用許可の取得方法は、API によって異なります。一部の(通常は古い)API では、API を初めて使用しようとしたときにブラウザが自動的に権限を要求するモデルが使用されます。たとえば、Geolocation API で navigator.geolocation.getCurrentPosition() を呼び出す場合です。

try {
  navigator
.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
  console
.error(error);
}

他の API は、静的メソッドを使用して最初に権限を明示的にリクエストする必要があるモデルを使用します。たとえば、通知を許可する Notification.requestPermission() や、Device Orientation Events API の一部であるあまり一般的でない DeviceOrientationEvent.requestPermission() などです。一部のブラウザでは、特定の API に対する権限が自動的に付与される場合があります。たとえば、Chrome ではデバイスの向きに常にアクセスできますが、Safari ではプロンプトが表示されます。

const result = await DeviceOrientationEvent.requestPermission();
console
.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
 
/* Use the API. */
}

権限の状態を確認する方法

特定の API を使用できるかどうかを確認するには、Permissions API の navigator.permissions.query() メソッドを使用します。

const result = await navigator.permissions.query({ name: 'geolocation' });
console
.log(`The result of querying for the Geolocation API is:
$
{result.state}.`);
if (result.state === 'granted') {
 
// Use the API.
}

対応ブラウザ

  • Chrome: 43.
  • Edge: 79.
  • Firefox: 46.
  • Safari: 16。

ソース

ブロックされた状態から復元できるようユーザーをサポートする

ユーザーがアクセスの問題をトラブルシューティングできるように、Permissions API を使用してアクセスがブロックされていることを検出し、設定を変更する方法に関するガイドをユーザーに提供します。たとえば、ユーザーが権限制限付きの機能に関連付けられた UI 要素を操作した場合は、前のセクションで説明したパターンを使用して、トラブルシューティング ダイアログを開きます。権限の状態を変更する手順はブラウザによって異なるため、ユーザー エージェント文字列と、プロダクトで最もよく使用されるブラウザに基づいて、一致する説明を提供することをおすすめします。

Chrome では、アドレスバーの左側にある [調整] アイコンをクリックして [サイト管理] に移動する必要があります。ここで、それぞれの権限をオンに切り替えることができます。場合によっては、この機能を利用する前にページを再読み込みする必要があります。その場合は、ウィンドウの上部にメッセージバーが表示され、対応するボタンをクリックすると再読み込みが提案されます。

Chrome ブラウザのサイト管理。

サイト管理ツールを使用して権限を変更した後の再読み込みプロンプト。

権限を制御するための同様の UI は他のブラウザにも存在します(Firefox での動作をご覧ください)。