許可 — Permissions

1. 序論

各~仕様は、［ `強力な特能$として明示的に識別される特能 ］を定義し得る。 これらの特能が “強力” と称されるのは、［ ~privacy／~security／処理能 ］に有意な含意があることによる。 そのようなわけで、 利用者は，［ これらの特能を~siteが利用する能に対し，~UAが次を行う ］ことに依拠する： ◎ Specifications can define features that are explicitly identified as a powerful feature. These features are said to be "powerful" in that they can have significant privacy, security, and performance implications. As such, users rely on user agents＼

• 利用者が許可を表出するまでは、 この能を否認する。 ◎ to deny sites the ability to use these features until they have given express permission,＼
• 通例的に，この能を是認する時間を制限する。 ◎ and usually only granting this ability for a limited amount of time.＼

利用者が［ 強力な特能を利用することを~siteに許容する許可 ］を表出することは、 一般に，~browserの~UIを通して制御される — 以下に図解されるように。 ◎ Express permission to allow a site to use a powerful feature is generally given and controlled through browser UI, as illustrated below.

許可は、 このイミにおいて，［ ある種の型の特能 — 特に “強力な特能” — に対する利用者の同意 ］の現在の状態を表現する： ◎ In this sense, a permission represents the current state of user consent for certain types of features, and particularly "powerful features".＼

• 最終的には、 利用者が： ◎ Ultimately the user＼

  • これらの許可の制御を維持する。 ◎ retains control of these permissions＼
  • 選好を通して，これらの許可を手動で［ 是認する／否認する ］能を有する。 ◎ and have the ability to manually grant or deny permissions through user preferences.＼

• ~UAは、 許可の管理-法において，利用者を支援する — 例えば，次を行うことにより： ◎ Further, user agents assist users in managing permissions by, for example,＼

  • ある種の — さもなければ煩わしくなる — 許可~promptを隠す, あるいは自動的に否認する。 ◎ hiding and automatically denying certain permission prompts that would otherwise be a nuisance,＼
  • 利用者が~web~siteをしばらく訪問しなかった後には、 是認した許可を自動的に失効させる。 ◎ and automatically expiring granted permissions if a user doesn't visit a website for some time.

2. 用例

const { %state } = await navigator.permissions.query({
  name: "geolocation"
});
switch (%state) {
  case `granted$l:
    showLocalNewsWithGeolocation();
    break;
  case `prompt$l:
    showButtonToEnableLocalNews();
    break;
  case `denied$l:
    showNationalNews();
    break;
}

const %queryPromises = ["geolocation", "notifications"].map(
  %name => navigator.permissions.query({ %name })
);
for await (const %status of %queryPromises) {
  console.log(``^${%status.name}: ${%status.state}``^);
}

const %devices = await navigator.mediaDevices.enumerateDevices();

/* 
動画~入力のみに~filterしてから，~query~objに対応付ける
◎
filter on video inputs, and map to query object

const %queries = %devices
  .filter(({ %kind }) => %kind === "videoinput")
  .map(({ %deviceId }) => ({ name: "camera", %deviceId }));

const %promises = %queries.map((%queryObj) =>
  navigator.permissions.query(%queryObj)
);

try {
  const %results = await Promise.all(%promises);
  /* 
状態や各~cameraの~logをとる
◎
log the state of each camera

  %results.forEach(({ %state }, %i) => console.log("Camera", %i, %state));
} catch (%error) {
  console.error(%error);
}

3. ~model

この節は、［ ~Web~platformの`強力な特能$を利用する`許可$【！`許可~module$】 ］用の~modelを指定する。 ◎ This section specifies a model for permissions to use powerful features on the Web platform.

<iframe src="https://example.com/" allow="geolocation"></iframe>

dictionary SensesPermissionDescriptor : PermissionDescriptor {
  boolean canSmell = false;
  boolean canTaste = false;
};

/* 
強力な特能 `senses^l には，モノを~smellすることは許容されるか否か検査する
◎
Check if the "senses" powerful feature is allowed to smell things
 */
const %status = await navigator.permissions.query({
  name: "senses",
  canSmell: true,
});
/* 
%status について何か関心事を行う。
◎
Do something interesting with the status.
 */

4. 強力な特能の指定-法

ある適合な`仕様$が `強力な特能を指定する@ ときは、 当の`強力な特能$ — 以下、 %特能 と記す — に対し： ◎ When a conforming specification specifies a powerful feature it:

• %特能 に`名前$を — `~ASCII小文字~化$された形の文字列として — 与えなければナラナイ。 ◎ MUST give the powerful feature a name in the form of a ascii lowercase string.
• `PermissionDescriptor$I を継承する`許可~記述子~型$を定義してもヨイ。 ◎ MAY define a permission descriptor type that inherits from PermissionDescriptor.
• 0 個~以上の`側面$を定義してもヨイ。 ◎ MAY define zero or more aspects.
• 下に与える各［ ~algo, 型 ］を［ その既定が %特能 用には相応でない場合 ］には上書きしてもヨイ。 ◎ MAY override the algorithms and types given below if the defaults are not suitable for a particular powerful feature.
• %特能 を`許可~registry$に登録しなければナラナイ。 ◎ MUST register the powerful feature in the Permissions Registry.

新たに指定される`強力な特能$を`許可~registry$に登録することは、 この仕様の~WGが［ ~feedbackを供する／ この仕様との統合が有効に行われたことを検査する ］機会を与える。 ◎ Registering the newly specified powerful features in the Permissions Registry gives this Working Group an opportunity to provide feedback and check that integration with this specification is done effectively.

`許可~記述子~型@ ◎ A permission descriptor type:

`PermissionDescriptor$I, または その下位型。 ◎ PermissionDescriptor or one of its subtypes.＼

未指定な場合の既定は、 `PermissionDescriptor$I とする。 ◎ If unspecified, this defaults to PermissionDescriptor.

%特能 は、 記述子の各~instance間において `より強い@ と称される`半順序＠https://en.wikipedia.org/wiki/Partially_ordered_set$を定義できる。 ［ 記述子 %A は記述子 %B `より強い$ ］ならば、 次が満たされなければナラナイ：

• ［ %A の`許可~状態$ ~EQ `granted$l ］ならば［ %B の`許可~状態$ ~EQ `granted$l ］
• ［ %B の`許可~状態$ ~EQ `denied$l ］ならば［ %A の`許可~状態$ ~EQ `denied$l ］

◎ The feature can define a partial order on descriptor instances. If descriptorA is stronger than descriptorB, then if descriptorA's permission state is "granted", descriptorB's permission state must also be "granted", and if descriptorB's permission state is "denied", descriptorA's permission state must also be "denied".

半順序を定義する許可~記述子の例： `{name: midi, sysex: true}^c — “sysex を伴う~MIDI” — は `{name: midi, sysex: false}^c — “sysex を伴わない~MIDI” — `より強い$ので、 利用者が “sysex を伴わない~MIDI” への~accessを否認した場合、 ~UAは “sysex を伴う~MIDI” への~accessも否認しなければならない。 同様に，利用者が “sysex を伴う~MIDI” への~accessを是認した場合、 ~UAは “sysex を伴わない~MIDI” への~accessも是認しなければならない。 ◎ Example 6: A permission descriptor that defines a partial order ◎ {name: "midi", sysex: true} ("midi-with-sysex") is stronger than {name: "midi", sysex: false} ("midi-without-sysex"), so if the user denies access to midi-without-sysex, the UA must also deny access to midi-with-sysex, and similarly if the user grants access to midi-with-sysex, the user agent must also grant access to midi-without-sysex.

`許可~状態~拘束@ ◎ permission state constraints:

~UAが記述子の`許可~状態$として返せる値を拘束する。 ◎ Constraints on the values that the user agent can return as a descriptor's permission state.＼

既定では、 利用者の意図を超える拘束は無いとする。 ◎ Defaults to no constraints beyond the user's intent.

`~extra許可~data型@ ◎ extra permission data type:

一部の`強力な特能$には、 `PermissionState$I 以外の情報も結付けられる。 そのような各~特能は、 `~extra許可~data型$を定義する。 ◎ Some powerful features have more information associated with them than just a PermissionState. Each of these features defines an extra permission data type.

注記： 例えば、 `getUserMedia()$m は，次を決定する必要がある ⇒ 利用者は、 `どの~camera^emに~accessする許可を是認したか ◎ Note For example, getUserMedia() needs to determine which cameras the user has granted permission to access.

ある文字列【！DOMString】 %名前 で`識別される特能$ %特能 の `~extra許可~data@ は、 所与の`環境~設定群~obj$ %設定群 （省略時は ε ）に対し， 次を走らせた結果で与えられる： ◎ If a DOMString name names one of these features, then name's extra permission data for an optional environment settings object settings is the result of the following algorithm:

1. ~IF［ %設定群 ~EQ ε ］ ⇒ %設定群 ~SET `現在の設定群~obj$ ◎ If settings wasn't passed, set it to the current settings object.

2. ~IF［ この~algoは、 以前に，同じ ( %名前, %設定群 ) で呼出された ］~AND［ ~UAは、 以前の時点から［ `利用者の意図についての新たな情報$ ］をまだ受取ってない ］ ⇒ ~RET 以前の時点における結果

   【 “以前” がどこまで遡れるかは、 少なくとも`存続期間$までに制限されよう。 】

   ◎ If there was a previous invocation of this algorithm with the same name and settings, returning previousResult, and the user agent has not received new information about the user's intent since that invocation, return previousResult.
3. ~RET 次を満たす［ %特能 の`~extra許可~data型$の~instance ］ ⇒ ［ ~UA視点による利用者の意図に合致する ］~AND［ %特能 の`~extra許可~data拘束$を満たす ］ ◎ Return the instance of name's extra permission data type that matches the UA's impression of the user's intent, taking into account any extra permission data constraints for name.

指定された場合、 %特能 の`~extra許可~data$を利用-可能になる。 ◎ If specified, the extra permission data algorithm is usable for this feature.

【 すなわち，既定では、 `~extra許可~data$は無い。 】【 この “~data型” に何らかの~IDLが含意されるかどうかは、 定かでない （この用語を利用している他の仕様を見なければ判明しない）。 】

`~extra許可~data拘束@ ◎ Optional extra permission data constraints:

~UAが %特能 の`~extra許可~data$として返せる値を拘束する。 ◎ Constraints on the values that the user agent can return as a powerful feature's extra permission data.＼

既定では、 利用者の意図を超える拘束は無いとする。 ◎ Defaults to no constraints beyond the user's intent.

`許可~結果型@ ◎ A permission result type:

`PermissionStatus$I または，その下位型。 ◎ PermissionStatus or one of its subtypes.＼

未指定な場合の既定は、 `PermissionStatus$I とする。 ◎ If unspecified, this defaults to PermissionStatus.

`許可~query~algo@ ◎ A permission query algorithm:

2 つの引数 ⇒＃ %特能 の`許可~記述子~型$の~instance, %特能 の`許可~結果型$の 新たな または既存の~instance ◎終 による~queryの結果で，後者の引数を更新する。 ［ `Permissions$I の `query()$m ~method ／ `許可~状態s更新~手続き$ ］で利用される。 ◎ Takes an instance of the permission descriptor type and a new or existing instance of the permission result type, and updates the permission result type instance with the query result. Used by Permissions' query(permissionDesc) method and the PermissionStatus update steps.＼

未指定な場合の既定は、 `既定の許可を~queryする~algo$とする。 ◎ If unspecified, this defaults to the default permission query algorithm.

`既定の許可を~queryする~algo@ は、 所与の ( `PermissionDescriptor$I %記述子, `PermissionStatus$I %状態s ) に対し ⇒ %状態s の `state$m ~SET `現在の許可~状態を取得する$( %記述子 ) ◎ The default permission query algorithm, given a PermissionDescriptor permissionDesc and a PermissionStatus status, runs the following steps: • Set status's state to permissionDesc's permission state.

`許可~key型@ ◎ A permission key type:

%特能 が利用する`許可~key$の型。 ◎ The type of permission key used by the feature.＼

未指定な場合の既定は、 `生成元$とする。 ◎ Defaults to origin.＼

~customな`許可~key型$を指定する特能は、 `許可~key生成~algo$も指定しなければナラナイ。 ◎ A feature that specifies a custom permission key type MUST also specify a permission key generation algorithm.

`許可~key生成~algo@ ◎ A permission key generation algorithm:

所与の`環境~設定群~obj$に対し，新たな`許可~key$を返す。 ◎ Takes an environment settings object, and returns a new permission key.＼

未指定な場合の既定は、 `既定の許可~key生成~algo$になる。 ◎ If unspecified, this defaults to the default permission key generation algorithm.＼

~customな`許可~key生成~algo$を指定する特能は、 `許可~key比較~algo$も指定しなければナラナイ。 ◎ A feature that specifies a custom permission key generation algorithm MUST also specify a permission key comparison algorithm.

`既定の許可~key生成~algo@ は、 所与の ( `環境~設定群~obj$ %設定群 ) に対し ⇒ ~RET %設定群 の`~top-level生成元$enV ◎ The default permission key generation algorithm, given an environment settings object settings, runs the following steps: • Return settings's top-level origin.

注記（許可の委任）： ほとんどの`強力な特能$は、 その許可を~top-level生成元に対し是認することに加え、 `許可~施策$cite を介して，それを要請している文書に~accessを委任する。 これは、 許可の委任とも呼ばれる。 ◎ Note: Permission Delegation Most powerful features grant permission to the top-level origin and delegate access to the requesting document via Permissions Policy. This is known as permission delegation.

`許可~key比較~algo@ ◎ A permission key comparison algorithm:

所与の 2 個の`許可~key$に対し，それらが等しいかどうかを示す`真偽値$を返す。 ◎ Takes two permission keys and returns a boolean that shows whether the two keys are equal.＼

未指定な場合の既定は、 `既定の許可~key比較~algo$とする。 ◎ If unspecified, this defaults to the default permission key comparison algorithm.

`既定の許可~key比較~algo@ は、 所与の ( `許可~key$ %key1, `許可~key$ %key2 ) に対し ⇒ ~RET ~IS［ ( %key1, %key2 ) は`同一-生成元$である ］ ◎ The default permission key comparison algorithm, given permission keys key1 and key2, runs the following steps: • Return key1 is same origin with key2.

`許可~revocation~algo@ ◎ A permission revocation algorithm:

引数はとらない。 実装における他の部分 — ［ `許可~状態$ ／ `~extra許可~data$ ］における変化との同期cが保たれる必要があるもの — があれば，それを更新する。 ◎ Takes no arguments. Updates any other parts of the implementation that need to be kept in sync with changes in the results of permission states or extra permission data.

未指定な場合の既定は、 `利用者により許可が~revokeされたとき反応する$†。

【† これは、 `許可~revocation~algo$を呼出すので，定義が循環している。 実際には、 その手続きの中の［ `許可~revocation~algo$を遂行する段 ］以外を遂行することになろう。 】

◎ If unspecified, this defaults to running react to the user revoking permission.

許可の`存続期間$ ◎ A permission lifetime:

`強力な特能$を定義する仕様は、 当の特能に対する`許可$の`存続期間$として， 最良に適するものを示唆するベキである。 下に、 許可~存続期間の決定-法に関する指導を — 特に，利用者の~privacyを重視して — いくつか注記する。 `存続期間$が指定されない場合、 ~UAが，それを供することになる。 ◎ Specifications that define one or more powerful features SHOULD suggest a permission lifetime that is best suited for the particular feature. Some guidance on determining the lifetime of a permission is noted below, with a strong emphasis on user privacy. If no lifetime is specified, the user agent provides one.

所与の`強力な特能$に対する［ ある生成元~用の許可 ］の`存続期間$が失効したときは： ◎ When the permission lifetime expires for an origin:

1. 当の許可の`状態$を，その既定の`許可~状態$（例： `~prompt$）に設定し直す ◎ Set the permission back to its default permission state (e.g., by setting it back to "prompt").
2. 当の生成元に属する ~EACH( `閲覧~文脈$ %閲覧~文脈 ) に対し ⇒ `大域~taskを~queueする$( `許可~task~source$, %閲覧~文脈 の`大域~obj$, 当の特能の`許可~revocation~algo$ ) ◎ For each browsing context associated with the origin (if any), queue a global task on the permissions task source with the browsing context's global object to run the permission revocation algorithm.

注記（許可の存続期間の決定-法） — `存続期間$は、 当の`強力な特能$や~UAに応じて様々になる： ◎ Note: Determining the lifetime of a permission

• 特に~privacyに敏感な特能 （例： `Media Capture and Streams$cite — これは、 利用者の［ ~camera, ~microphone ］への~accessを~web~appに供し得る） に対しては、 一部の~UAは， ~browser~UItabが閉じられるか`~navigate$され次第， `是認-$された許可を失効させる。 ◎ For particularly privacy-sensitive features, such as Media Capture and Streams, which can provide a web application access to a user's camera and microphone, some user agents expire a permission grant as soon as a browser tab is closed or navigated.＼
• 他の【~privacyに敏感な】特能 （例： `Geolocation API$cite ） に対しては、 ~UAは，当の許可を［ 当の~session ／ 1 日 ］に限り是認する~~選択肢を提供することが知られている。 ◎ For other features, like the Geolocation API, user agents are known to offer a choice of only granting the permission for the session, or for one day.＼
• 他のもの （例： `Notifications API$cite, `Push API$cite ） に対しては、 ~UAは，利用者の裁定を［ 不定な間／ 利用者が当の許可を手動で~revokeするまで ］覚える。 ◎ Others, like the Notifications API Standard and Push API APIs, remember a user's decision indefinitely or until the user manually revokes the permission.＼

許可の`存続期間$は、 ~UAごとに有意に変わり得ることに注意。 ◎ Note that permission lifetimes can vary significantly between user agents.

ある許可の存続期間~用に適当な~balanceを見出すことは、 たくさんの思考と試験結果が要求され， 何年か経つうちに発展することが多い。 実装者には、 次が奨励される： ◎ Finding the right balance for the lifetime of a permission requires a lot of thought and experimentation, and often evolves over a period of years. Implementers are encouraged＼

• ~UX~security~teamとともに作業して，［ `強力な特能$への~accessの容易さと （すなわち，許可~promptの回数を抑制すること）, 利用者の~privacyを尊重すること ］との適当な~balanceを見出すこと。 ◎ to work with their UX security teams to find the right balance between ease of access to a powerful feature (i.e., reducing the number of permission prompts), respecting a user's privacy,＼
• ある~web~appが 特定0の強力な特能を用立てたときは、 そのことを利用者が自覚できるようにすること （例：何らかの［ 視覚的／聴覚的 ］~UI指示子を介して）。 ◎ and making users aware when a web application is making use of a particular powerful feature (e.g., via some visual or auditory UI indicator).

ある`強力な特能$用に示唆する`存続期間$が不確かな場合、 `Privacy Interest Group＠https://www.w3.org/Privacy/IG/$en から指導を仰がれたし。 ◎ If you are unsure about what lifetime to suggest for a powerful feature, please contact the Privacy Interest Group for guidance.

`既定の許可~状態@ ◎ Default permission state:

`PermissionState$I 値のうち，［ %特能 に対する`許可$ ］の`既定の状態$として~serveするもの。 ◎ An PermissionState value that serves as a permission's default state of a powerful feature.

指定されていない場合、 【！`許可$の`既定の状態$は】 `prompt$l になるとする。 ◎ If not specified, the permission's default state is "prompt".

`既定の強力な特能@ とは、 `強力な特能$のうち，上の各種［ 型／~algo ］すべてが既定のそれらにされたものをいう。 ◎ A default powerful feature is a powerful feature with all of the above types and algorithms defaulted.

5. 許可と~interfaceするための~algo

6. 許可~API

[`Exposed$=(Window)]
partial interface `Navigator$I {
  [`SameObject$] readonly attribute `Permissions$I `permissions@m;
};

[`Exposed$=(Worker)]
partial interface `WorkerNavigator$I {
  [`SameObject$] readonly attribute `Permissions$I `~permissions0@m;
};

[`Exposed$=(Window,Worker)]
interface `Permissions@I {
  `Promise$<`PermissionStatus$I> `query$m(`object$ %permissionDesc);
};

dictionary `PermissionDescriptor@I {
  required `DOMString$ `name@mb;
};

[`Exposed$=(Window,Worker)]
interface `PermissionStatus@I : `EventTarget$I {
  readonly attribute `PermissionState$I `state$m;
  readonly attribute `DOMString$ `name$m;
  attribute `EventHandler$I `onchange$m;
};

enum `PermissionState@I {
  `granted$l,
  `denied$l,
  `prompt$l,
};

適合性

【 この節の他の内容は、 `~W3C日本語訳 共通~page＠~W3Ccommon#conformance$ に移譲。 】

この仕様への適合性を主張できる製品には、 次に挙げる 2 種の~classがある ⇒ `~UA$, および他の `仕様@ （すなわち，`~W3C技術-報告＠~TR/$のうち，この仕様の要件に適合する方式で`強力な特能を指定する$もの）。 ◎ Two classes of product can claim conformance to this specification: user agents and other specifications (i.e., a technical report that specifies a powerful feature in a manner that conforms to the requirements of this specification).

A. 許可~施策~仕様との関係性

この仕様, `許可~施策$cite 仕様は、 どちらも，各種 “許可” を処するものであるが、 それぞれ，~platformにおける別個な目的を~serveする。 だとしても、 この 2 つの仕様には，重合する所も明示的にある。 ◎ Although both this specification and the Permissions Policy specification deal with "permissions", each specification serves a distinct purpose in the platform. Nevertheless, the two specifications do explicitly overlap.

この仕様が専ら懸念する`強力な特能$は、 その~accessが［ ~UAが仲介する許可~UI ］を通して管理されるものである （すなわち、 利用者の同意は，［ 当の特能が利用されようとする前に，利用者が許可を与える ］ことにより表出され、 どの利用者も，理由を問わず［ その許可をいつでも否認する能 ］を維持する）。 これらの`強力な特能$は、 `許可~registry$内に登録される。 ◎ On the one hand, this specification exclusively concerns itself with powerful features whose access is managed through a user-agent mediated permissions UI (i.e., permissions where the user gives express consent before that feature can be used, and where the user retains the ability to deny that permission at any time for any reason). These powerful features are registered in the Permissions Registry.

他方，`許可~施策$cite 仕様は、 `許可~施策$【！`許可~施策$doc】を通して，`施策により制御される特能$を選択的に［ 可能化する／不能化する ］ことを開発者に許容する（~HTTP~header, `allow$a 属性どちらにせよ）。 `許可~施策$cite は、［ このイミにおいて，この仕様を組み込むもの ］であり，［ ある特能が可用になるかどうか ］をこの仕様とは まったく独立に統治する。 これらの`施策により制御される特能$もまた、 `許可~registry$内に登録される。 ◎ On the other hand, the Permissions Policy specification allows developers to selectively enable and disable policy-controlled features through a "permissions policy" (be it a HTTP header or the allow attribute). In that sense, the Permissions Policy subsumes this specification in that Permissions Policy governs whether a feature is available at all, independently of this specification. These policy-controlled features are also registered in the Permissions Registry.

`許可~施策$cite 仕様により不能化される`強力な特能$は、 この仕様においては，その`許可~状態$は常に `denied$l （否認された）として反映される。 このことは、［ `現在の許可~状態を取得する$ことが `HTML$r の “`利用は許容されて$いるかどうか” の検査に依拠する ］ことから生じる — この検査~自体も，`許可~施策$cite 仕様の中へ~callする。 ここでの重要な注意点は、 許可の名前が両~仕様にて共有されることである。 この仕様, `許可~施策$cite 仕様は、 どちらも［ 許可の名前~群, `名前$ ］を定義している他の仕様に依拠し， それらは通例的に同じモノを命名する （例： `Geolocation API$cite の `geolocation^l, 等々）。 ◎ A powerful feature that has been disabled by the Permissions Policy specification always has its permission state reflected as "denied" by this specification. This occurs because reading the current permission relies on [HTML]'s "allowed to use" check, which itself calls into the Permissions Policy specification. Important to note here is the sharing of permission names across both specifications. Both this specification and the Permissions Policy specification rely on other specifications defining the names of the permission and name, and they are usually named the same thing (e.g., "geolocation" of the Geolocation API, and so on).

最後に，ある`強力な特能$が［ `許可~施策$cite 仕様が供する手段を通して`是認-$されるようになる ］ことはアリでない。 `是認-$され得る仕方は、 利用者が`許可を表出する$ことによるか，何らかの~UA施策による他にない。 ◎ Finally, it's not possible for a powerful feature to ever become "granted" through any means provided by the Permissions Policy specification. The only way that a powerful feature can be "granted" is by the user giving express permission or by some user agent policy.

B. 自動化された~test法

この文書は、 ~UAの自動化と~appを~testする目的で，［ `WebDriver$r, `WebDriver-BiDi$r ］各~仕様に対する拡張を定義する。 ~UAがそれを~supportするのは、 任意選択~である。 ◎ For the purposes of user-agent automation and application testing, this document defines extensions to the [WebDriver] and [WebDriver-BiDi] specifications. It is OPTIONAL for a user agent to support them.

dictionary `PermissionSetParameters@I {
  required `object$ `descriptor@mb;
  required `PermissionState$I `state@mb;
};

【 この訳では、 この節に利用される `WEBDRIVER$r 用の用語に以下に挙げる表記を用いる： 】

• `~error@wdr( %~code ) ⇒ `~error~code＠~WEBDRIVER#dfn-error-code$ %~code を伴う`~error＠~WEBDRIVER#dfn-error$
• `成功@wdr( %~data ) ⇒ ~data~fieldに %~data を伴う`成功＠~WEBDRIVER#dfn-success$

{
  "descriptor": {
    "name": "midi",
    "sysex": true
  },
  "state": "granted"
}

PermissionsCommand = (
  permissions.setPermission
)

permissions.PermissionDescriptor = {
  name: text,
}

permissions.PermissionState = "granted" / "denied" / "prompt"

C. 許可~registry

D. ~privacyの考慮点

ある敵対者は、 末端利用者に対応する “指紋” を作成するための要素として， `許可~状態$も利用できる。 敵対者は，実際に~APIを利用して すでに許可の状態を決定できるが、 それは，末端利用者に対し~UI~promptが呈示される結果に至ることが多い （その許可が すでに`是認-$された場合を除き）。 この~APIは、 ~web~siteに新たな指紋収集~情報を公開することはないが， 敵対者にとって この情報への目立たない~accessを容易にする。 ◎ An adversary could use a permission state as an element in creating a "fingerprint" corresponding to an end-user. Although an adversary can already determine the state of a permission by actually using the API, that often leads to a UI prompt being presented to the end-user (if the permission was not already "granted"). Even though this API doesn't expose new fingerprinting information to websites, it makes it easier for an adversary to have discreet access to this information.

~UAは、 所与の`生成元$【`許可~key$】に結付けられた`強力な特能$に対し， その`許可$がとる`状態$を［ 考査する, 更新する, 設定し直す ］ための手段を利用者~向けに供するベキである。 ◎ A user agent SHOULD provide a means for the user to review, update, and reset the permission state of powerful features associated with an origin.

E. ~securityの考慮点

現時点では、 文書化された~security考慮点は無い。 読者には、 代わりに， `§ ~privacyの考慮点＠#privacy-considerations$ を読むことが奨励される。 ◎ There are no documented security considerations at this time. Readers are instead encouraged to read section C. Privacy considerations.

謝辞