ARTICLE

権限設計は後回しにしない

ブラウザUIを囲む権限スコープの抽象図。

Chrome拡張の権限は、実装の最後に足りないものを追加する項目ではありません。 権限は、ユーザーに何を許可してもらうのか、Chrome Web Storeにどのような目的の拡張として見られるのかに直結します。

Chrome拡張では、permissionshost_permissionsoptional_permissionsoptional_host_permissions などを使って、拡張が必要とするアクセス範囲を宣言します。 storage のようなChrome APIを使うための権限もあれば、特定のWebサイトへアクセスするためのhost permissionsもあります。

注意したいのは、広すぎるhost permissionsです。 たとえば、すべてのサイトを対象にしたいからといって最初から <all_urls> のような広い指定にすると、ユーザーに強い警告が出たり、審査時に「本当に必要なのか」を説明する必要が出たりします。 実際に必要なサイトが決まっているなら、そのサイトだけに絞るべきです。

権限の考え方は、機能から逆算すると整理しやすくなります。 ある機能が「現在開いているタブでユーザーがボタンを押したときだけ動く」なら、広いhost permissionではなく activeTab で足りるかもしれません。 特定サイトで常にContent scriptを動かす必要があるなら、そのサイトのmatch patternだけを指定します。 後からユーザーが許可できる設計にできるなら、optional permissionsを検討します。

有料Chrome拡張では、課金やライセンス確認のために外部APIと通信することがあります。 この場合も、拡張が扱うデータを最小限にすることが重要です。 ライセンス確認に必要なのがライセンスキー、匿名の端末識別子、拡張バージョンだけなら、閲覧ページの本文や履歴を送るべきではありません。

権限設計は、ユーザーへの説明文ともセットです。 Chrome Web Storeの説明、プライバシーポリシー、拡張内のUIで「何のためにこの権限が必要なのか」を一貫して説明します。 説明と実際の挙動がずれると、信頼だけでなくストア掲載にも影響します。

Chrome Extension Kit を使う場合でも、テンプレートの権限をそのまま残すのではなく、自分の拡張に必要な権限だけへ削ってください。 スターターキットは出発点であって、完成品の権限設計を肩代わりするものではありません。

References