webappsec-permissions-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Permissions（日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<style>
samp {
	white-space: nowrap;
	background: var(--bg-color-1);
	margin-left: 0.5em;
	margin-right: 0.5em;
}

@supports (grid-template-columns: subgrid) and (display: contents) {

._registry-table {
	grid-template-columns: 4em 8em 8em 1fr;
	width: 32em;
	max-width: 60em;
	margin-top: 2em;

	tr {
		grid-template-areas:
			"識別子 識別子 仕様 仕様"
			". 施策 強力 実装"
		;
		> *:nth-child(1) {
			border-left-width: 0;
			grid-area: 識別子;
		}
		> *:nth-child(2) {
			grid-area: 施策;
		}
		> *:nth-child(3) {
			grid-area: 強力;
		}
		> *:nth-child(4) {
			border-left-width: 0;
			grid-area: 仕様;
		}
		> *:nth-child(5) {
			grid-area: 実装;
		}
	}
}

}
</style>

<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>
Util.ready = function(){
	const source_data = {
		toc_main: 'MAIN0',
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.*?)([$@^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!indicator) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#bib-${key.toLowerCase()}`;
	break;
case 'l':
	text = `"<code class="literal">${key}</code>"`;
	break;
case 'm':
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
		text = key + text.slice(n).replace(/\w+/g, '<var>$&</var>');
	}
	break;
case 'sl':
	text = `[[${key}]]`;
	break;
case 'en':
	text = `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}
</script>


<script type="text/plain" id="_source_data">


●●options

spec_title:Permissions
spec_date:2024-12-20
trans_update:2024-12-21
source_checked:230612
page_state_key:WEBAPPSEC
original_url:https://w3c.github.io/permissions/
	abbr_url:PERMISSIONS
spec_status:ED
ref_id_prefix:bib-
ref_id_lowercase:true
	conformance:w3c
copyright:2024,permissive
trans_1st_pub:2017-03-14


●●class_map
et:event-type
e:element
a:attr
sl:js-slot
E:error
hm:method
jt:js-type
jA:abstract

●●tag_map
p:var
a:code
E:code
I:code
m:code
mb:code
et:code
hm:code
sl:span
e:code
c:code
jt:code
jA:span
i:i
cite:cite

●●original_id_map

	重複 id
	automation-webdriver:automated-testing-with-webdriver
	webdriver-command-set-permission:set-permission
	automation-webdriver-bidi:automated-testing-with-webdriver-bidi
	webdriver-bidi-module-permissions:the-permissions-module
	webdriver-bidi-module-permissions-definition:definition
	webdriver-bidi-module-permissions-types:types
	webdriver-bidi-type-permissions-PermissionDescriptor:the-permissions-permissiondescriptor-type
	the-permissions-permissionstate-type:webdriver-bidi-type-permissions-PermissionState
	webdriver-bidi-module-permissions-commands:commands
	webdriver-bidi-command-permissions-setPermission:the-permissions-setpermission-command

●●mdn_urls
dom-permissions:API/Permissions
dom-permissionstatus:API/PermissionStatus
	dom-permissiondescriptor:API/PermissionDescriptor
	dom-permissionstate:API/PermissionState

●●link_map

	●IDL
SameObject:~WEBIDLjs#SameObject
Exposed:~WEBIDLjs#Exposed

boolean:~WEBIDL#idl-boolean
DOMString:~WEBIDL#idl-DOMString
object:~WEBIDL#idl-object
Promise:~WEBIDL#idl-promise

E.TypeError:~WEBIDL#exceptiondef-typeerror
E.InvalidStateError:~WEBIDL#invalidstateerror

I.Permissions:#dom-permissions
I.PermissionDescriptor:#dom-permissiondescriptor
I.PermissionState:#dom-permissionstate
I.PermissionStatus:#dom-permissionstatus
I.PermissionSetParameters:#dom-permissionsetparameters

I.EventHandler:~WAPI#eventhandler
I.EventTarget:~DOM4#eventtarget
I.Navigator:~HTMLnavigator#navigator
I.WorkerNavigator:~WORKERS#workernavigator
I.Window:~WINDOW#window

l.denied:#dom-permissionstate-denied
l.granted:#dom-permissionstate-granted
l.prompt:#dom-permissionstate-prompt

m.query:#dom-permissions-query

m.name:#dom-permissionstatus-name
m.onchange:#dom-permissionstatus-onchange
m.state:#dom-permissionstatus-state

m.permissions:#dom-navigator-permissions
m.~permissions0:#dom-workernavigator-permissions

m.getUserMedia:~MEDIACAPTURE#dom-mediadevices-getusermedia

mb.name:#dom-permissiondescriptor-name

mb.descriptor:#dom-permissionsetparameters-descriptor
mb.state:#dom-permissionsetparameters-state

	●code 他
sl.query:#dfn-query
c.deviceId:~MEDIACAPTURE#dom-mediadeviceinfo-deviceid

e.dfn:~HEtextlevel#the-dfn-element
e.iframe:~HEembed#the-iframe-element
a.allow:~HEembed#attr-iframe-allow

jA.Get:~TC39#sec-get-o-p

	●用語

許可:#dfn-permission
名前:#dfn-name
側面:#dfn-aspects
状態:#dfn-states
~prompt:#dfn-prompt
是認-:#dfn-granted
否認-:#dfn-denied
許可~状態:#dfn-permission-state
既定の状態:#dfn-default-state
既定の許可~状態:#dfn-default-permission-state
許可を表出-:#dfn-express-permission
許可を表出する:#dfn-express-permission
許可を設定する:#dfn-set-a-permission
	許可を設定する:#dfn-set-permission
	許可を設定する:#dfn-set-permission-0

許可~store:#dfn-permission-store
許可~store~entry:#dfn-permission-store-entry
合致する許可~store~entry:#_matched-permission-store-entry
psE.記述子:#dfn-descriptor
psE.~key:#dfn-key
psE.状態:#dfn-state
許可~key:#dfn-permission-key
同等な許可~key:#dfn-is-equal-to
許可~key型:#dfn-permission-key-type
許可~key比較~algo:#dfn-permission-key-comparison-algorithm
許可~key生成~algo:#dfn-permission-key-generation-algorithm
既定の許可~key生成~algo:#dfn-default-permission-key-generation-algorithm
既定の許可~key比較~algo:#dfn-default-permission-key-comparison-algorithm

許可~store~entryを取得する:#dfn-get-a-permission-store-entry
許可~store~entryを設定する:#dfn-set-a-permission-store-entry
許可~store~entryを除去する:#dfn-remove-a-permission-store-entry

許可~記述子~型:#dfn-permission-descriptor-type
許可~query~algo:#dfn-permission-query-algorithm
許可~結果型:#dfn-permission-result-type
許可~revocation~algo:#dfn-permission-revocation-algorithm
許可~状態~拘束:#dfn-permission-state-constraints
存続期間:#dfn-lifetime
現在の許可~状態を取得する:#dfn-getting-the-current-permission-state
~extra許可~data拘束:#dfn-extra-permission-data-constraints
~extra許可~data型:#dfn-extra-permission-data-type
~extra許可~data:#dfn-extra-permission-data
強力な特能:#dfn-powerful-feature
強力な特能を指定する:#dfn-specifies-a-powerful-feature
既定の強力な特能:#dfn-default-powerful-feature
識別される特能:#_powerful-feature-by-name
選ぶよう利用者に~promptする:#dfn-prompt-the-user-to-choose
利用する許可を要請する:#dfn-request-permission-to-use
暗黙的な兆候:#dfn-implicit-signals

既定の許可を~queryする~algo:#dfn-default-permission-query-algorithm
許可~状態sを作成する:#dfn-create-a-permissionstatus
許可~状態s更新~手続き:#dfn-permissionstatus-update-steps
利用者の意図についての新たな情報:#dfn-new-information-about-the-user-s-intent
より強い:#dfn-stronger-than
利用者により許可が~revokeされたとき反応する:#dfn-react-to-the-user-revoking-permission

許可~task~source:#dfn-permissions-task-source
許可を~queryする:#dfn-query-a-permission

許可~module:#dfn-permissions

仕様:#dfn-specifications

	●用語（registry

変更~過程:#dfn-change-process
既定の許容list:~PERMISSIONS-POLICY#policy-controlled-feature-default-allowlist
標準~化された許可たちが成す表t:#dfn-table-of-standardized-permissions-of-the-web-platform
暫定的な許可たちが成す表t:#dfn-table-of-provisional-permissions
標準~化された許可:#dfn-standardized-permission
許可~registry:#permissions-registry
	cite.許可~registry:https://w3c.github.io/permissions-registry/

cite.Geolocation:~GEOLOCATION
cite.Notifications API:~NOTIFICATIONS
cite.Push API:~TR/push-api/
cite.許可~施策:~PERMISSIONS-POLICY
cite.許可:#
	cite.許可:~PERMISSIONS

	●用語（外部

~UA:~INFRA#user-agent
~ASCII小文字~化:~INFRA#ascii-lowercase
~list:~INFRA#list
~size:~INFRA#list-size
付加する:~INFRA#list-append
置換する:~INFRA#list-replace
除去する:~INFRA#list-remove
~tuple:~INFRA#tuple
真偽値:~INFRA#boolean

~realm:~TC39#realm

列挙:~WEBIDL#dfn-enumeration
辞書:~WEBIDL#dfn-dictionary
diC.継承-:~WEBIDL#dfn-inherit-dictionary
~IDL値に変換する:~WEBIDLjs#dfn-convert-javascript-to-idl-value
新たな~promise:~WEBIDLjs#a-new-promise
却下される~promise:~WEBIDLjs#a-promise-rejected-with
~promiseを解決する:~WEBIDLjs#resolve

~eventを発火する:~DOM4#concept-event-fire
~event~listener:~DOM4#concept-event-listener

許可~施策:~PERMISSIONS-POLICY#permissions-policy
	doc.許可~施策:~HTMLdom#concept-document-permissions-policy

利用は許容されて:~HEembed#allowed-to-use
利用は許容され:~HEembed#allowed-to-use
並列的:~HTMLINFRA#in-parallel

生成元:~ORIGIN#concept-origin
同一-生成元:~ORIGIN#same-origin
文書:~DOM4#concept-document
結付けられた文書:~WINDOW#concept-document-window
対応する閲覧~文脈:~WINDOW#window-bc
閲覧~文脈:~HTMLds#browsing-context
~top-level閲覧~文脈:~HTMLds#top-level-browsing-context
全部的に作動中:~HTMLds#fully-active
内容~文書:~HTMLds#concept-bcc-content-document
~navigate:~HTMLnav#navigate

関連な設定群~obj:~WAPI#relevant-settings-object
現在の設定群~obj:~WAPI#current-settings-object
環境~設定群~obj:~WAPI#environment-settings-object
大域~obj:~WAPI#global-object
関連な大域~obj:~WAPI#concept-relevant-global
enV.生成元:~WAPI#concept-settings-object-origin
enV.~top-level生成元:~WAPI#concept-environment-top-level-origin
enV.大域~obj:~WAPI#concept-settings-object-global
enV.担当の~event~loop:~WAPI#responsible-event-loop
enV.~secureな文脈:~WAPI#secure-context
~event~handler~event型:~WAPI#event-handler-event-type
~event~handler:~WAPI#event-handlers
~task:~WAPI#concept-task
~task~source:~WAPI#task-source
~taskを~queueする:~WAPI#queue-a-task
大域~taskを~queueする:~WAPI#queue-a-global-task

施策により制御される特能:~PERMISSIONS-POLICY#policy-controlled-feature

~installされ:~APPMANIFEST#dfn-installed-web-application

局所~端:~WEBDRIVER#dfn-local-ends
~remote端:~WEBDRIVER#dfn-remote-ends
拡張~command:~WEBDRIVER#dfn-extension-commands
~URI~template:~WEBDRIVER#dfn-extension-command-uri-template
~remote端~手続き:~WEBDRIVER#dfn-remote-end-steps
無効な引数:~WEBDRIVER#dfn-invalid-argument

wdr.~error:#_webdriver-error
wdr.成功:#_webdriver-success
	~error:~WEBDRIVER#dfn-error
	~error~code:~WEBDRIVER#dfn-error-code
	成功:~WEBDRIVER#dfn-success
~session:~WEBDRIVER-BIDI#modules-session
拡張~module:~WEBDRIVER-BIDI#extension-modules
~remote端~定義:~WEBDRIVER-BIDI#remote-end-definition
~command:~WEBDRIVER-BIDI#command
利用者~文脈:~WEBDRIVER-BIDI#user-context
利用者~文脈~ID:~WEBDRIVER-BIDI#user-context-id
既定の利用者~文脈:~WEBDRIVER-BIDI#default-user-context


●●words_table1
W3C-Process:https://www.w3.org/policies/process/
MEDIACAPTURE:https://www.w3.org/TR/mediacapture-streams/
	MEDIACAPTURE:https://w3c.github.io/mediacapture-main/
WEBDRIVER:https://w3c.github.io/webdriver/
	WEBDRIVER:https://www.w3.org/TR/webdriver1/
	WEBDRIVER:https://www.w3.org/TR/webdriver2/
WEBDRIVER-BIDI:https://w3c.github.io/webdriver-bidi/
WEBSHARE:web-share-ja.html

permissions0:permissions

●●words_table

	●名称
WebDriver:
WebDriver-BiDi:WebDriver BiDi

	●仕様
下位型:subtype::~
	による:reason
推定-:infer:~
曖昧:vague:~
末端利用者:end user:~:::エンドユーザ
略記:shorthand:~
選択:selection:~
選択的:selective:~
選択肢:option:~
	~~選択肢:choice
見越して:anticipateして:~
集成-:aggregate:~
探求-:explore:~
学習-:learn:~
解決策:solution:~
申請-:file:~
仲介-:mediate:~
重合する:overlapする:重なり合う
同意:consent:~
維持-:retain:~
処する:dealする:~
専ら:exclusiveに:~
突止める:ascertainする:突き止める
思考:thought:~
試験結果:experimentation:~
尊重-:respect:~
不確か:unsure:~
発展-:evolve:~
team::::チーム
的確:right:~
balance::::バランス
読む:readする:~
故意:deliberate:~
自由度:freedom:~
有効に:effectiveに:~
模倣-:simulate:~
オン:on:~
製品:product:~
mockup::::モックアップ
素描:sketch:~
図解-:illustrate:~
粒度:granularity:~
為す:makeする:~
為され:makeされ:~

	用例:Examples of usage
	とされる:marked as
	~web~site:website
	視点で:notion
	視点による:impression
	裁定を下した:made 〜 decision
	至る:lead
	満た:satisfy
	〜も満たす:taking into account
	-:aware
	収まらな:fit
	~~伝える:contact
	処する:deal with
	どちらにせよ:be it 〜 or
	だとしても:nevertheless
	いつでも:at any time
	ようになる:ever become
	組み込む:subsume
	注意点:note
	最後に:finally
	目立たない:discreet
	指す:refer
	類別される:class
	選ぶ:choose
	選べる:choose
	どちらを選んだか:choice
	選びとる:pick and choose
	ある仮の:hypothetical
	関心事:interesting
	~Web~IDL:WebIDL
	~Web~IDL用の:WebIDL interface's
	たくさんの:a lot of
	何年か経つうち:over a period of years
	覚える:remember
	容易さ:ease of
	できるようにする:making
	適する:suited
	仰がれ:contact
	特に〜重視-:with strong emphasis
	大きく:greatly
	変わる:vary
	留意すべき:notable
	〜以外の:have more 〜 than just a
	図:figure

	Notifications API:Notifications API Standard

	●registry
repository::::リポジトリ
保守者:maintainer:~
付随-:accompany:~
過程:process:~
暫定的:provisional:~
確約-:assure:~
揺籃期:incubation phase:~
参照r:refer:参照
成熟-:mature:~
	に成熟したもの:maturity of
分類-:classify:~
識別用の:identifying:~
埋める:fillする:~

	埋める:filling out
	当の:your
	中心的な場:centralized place
	し易く:help
	すること。:make sure
	標準~化:standardized
	デモれ:demonstrably
	GitHub
	`許可^cite:Permissions
	`許可~施策^cite:Permissions Policy
	現れる:appearする
	欄:column
	ごく:very
	あらゆるもの:everything
	~link可能:linkable
	まだ:still
	にまたがって:across

	●処理
	~call元:caller
	~call元:calling
	invocation
	設定群:target
	~Web~IDL:~WebIDL
	設定し直す:Set 〜 back to
	設定し直す:reset
	時点:moment

	記述子 %A:descriptorA
	記述子 %B:descriptorB
	%記述子:descriptor
	%許可~記述子:permissionDesc
	%根~記述子:rootDesc
	%許可~名:permission name
	-:previousResult
	%有型~記述子:typedDescriptor
	%新たな~entry:newEntry
	%~key:key
	%key1:key1
	%key2:key2
	%~parameter群:parameters
	%~parameter辞書:parametersDict
	%~command~parameter群:command parameters
	%設定群:settings
	%~task:task
	-:tasks
	%~task~source:-
	%複数を許容するか:allowMultiple
	%状態:state
	%状態s:status
	%現在の状態:current state
	%特能:-
	%生成元:origin
	%生成元:target origin
	%~UA:user agent
	%利用者~文脈~ID:user context id

	●許可／保安
許容list:allowlist::許容 list:許容リスト
revokeされ::取り消され
revokeする::取り消す
revocation::取り消し
	~revokeされたとき:revoking
結果型:result type::~
指紋:fingerprint::~
敵対者:adversary:~
兆候:signals::~
頻繁:frequent:~
近過去:recent:~
	frequency and recency
extra::追加の
個人:person:~
store::::ストア
私的:private::~

	recency
	可能性が高い:more likely to
	勧める:advised
	~~注意深くあたる:exercise caution
	^e:iframe
	~keyを二重化する:double-keying
	同等:is equal to
	許可~状態s:PermissionStatus

	●許可対象

Permissions:
bluetooth:
MIDI:
NFC:
地理所在:geolocation:~
環境光:ambient light:~
camera::::カメラ
microphone::::マイク
地域news:local news:::地域ニュース:ローカルニュース

	●存続期間
存続期間:lifetime::~
	期間:duration
失効-:expire:~
不定:indefinite:~
	不定な間:indefinitely
	日:day
	され次第:as soon as
	戻す:back

	●UI
聴覚的:auditory:~
復帰-:revert:~
閉じら:closeさ:~
UX:
隠す:hideする:~
支援-:assist::~
camera::::カメラ
microphone::::マイク
motion::::モーション
sensor::::センサー
	煩わしい:nuisance
	時間~切れ:time out

	●未分類
端:end::~
半順序:partial order:~
URI:
template:
列挙型:enum::~
列挙値:enum value:enum 値:~

food:
taste:
smell:
sense:
検出器:detector::~
量:amount:~
保たれ:keepされ:~
稼働-:run:~

	モノ:thing
	在る:exist
	-:contain
	-:made
	-:client
	-:parameter
	読取n法:reading
	渡-:pass

	geolocation
	midi
	-:moment

	●指示語
	回数:number of
	一つ:one
	いくつも:many
	当の:relevant
	この時点で:now has
	数多の:lots of
	前もって:beforehand
	他の部分:any other parts
	最後に:latest
	同時:simultaneously
	近く:near
	最終的には:ultimately
	しばらく:some time

●●images
＠webappsec-permissions/
permission-settings｜height:15rem｜｜.webp
sample-prompts｜height:15rem｜｜.webp

●●ref_data
PERMISSIONSREGISTRY=副   ~/webappsec-permissions-registry-ja.html

●●ref_normative

[dom]
    ＜DOM Standard＞. Anne van Kesteren.  WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[ecma-262]
    ＜ECMAScript Language Specification＞.  Ecma International. URL: https://tc39.es/ecma262/multipage/
[HTML]
    ＜HTML Standard＞. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters.  WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
    ＜Infra Standard＞. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[Notifications]
    ＜Notifications API Standard＞. Anne van Kesteren.  WHATWG. Living Standard. URL: https://notifications.spec.whatwg.org/
[Permissions-Policy]
    ＜Permissions Policy＞. Ian Clelland.  W3C. 25 September 2024. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
[permissions-registry]
    ＜Permissions Registry＞.  W3C. Draft Registry. URL: https://w3c.github.io/permissions-registry/
[RFC2119]
    ＜Key words for use in RFCs to Indicate Requirement Levels＞. S. Bradner.  IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
    ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞. B. Leiba.  IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WebDriver]
    ＜WebDriver＞. Simon Stewart; David Burns.  W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/webdriver1/
[WebDriver-BiDi]
    ＜WebDriver BiDi＞. James Graham; Alex Rudenko; Maksim Sadym.  W3C. 6 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/webdriver-bidi/
[webdriver2]
    ＜WebDriver＞. Simon Stewart; David Burns.  W3C. 12 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/webdriver2/
[WEBIDL]
    ＜Web IDL Standard＞. Edgar Chen; Timothy Gu.  WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/
    

●●ref_informative

[appmanifest]
    ＜Web Application Manifest＞. Marcos Caceres; Kenneth Christiansen; Diego Gonzalez-Zuniga; Daniel Murphy; Christian Liebel.  W3C. 7 November 2024. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
[Geolocation]
    ＜Geolocation＞. Marcos Caceres; Reilly Grant.  W3C. 16 September 2024. W3C Recommendation. URL: https://www.w3.org/TR/geolocation/
[GETUSERMEDIA]
    ＜Media Capture and Streams＞. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet.  W3C. 5 December 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
[local-font-access]
    ＜Local Font Access＞.  WICG. cg-draft. URL: https://wicg.github.io/local-font-access/
[orientation-event]
    ＜Device Orientation and Motion＞. Marcos Caceres; Reilly Grant.  W3C. 21 November 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/orientation-event/
[Permissions]
    ＜Permissions＞. Marcos Caceres; Mike Taylor.  W3C. 19 March 2024. W3C Working Draft. URL: https://www.w3.org/TR/permissions/
[push-api]
    ＜Push API＞. Peter Beverloo; Martin Thomson; Marcos Caceres.  W3C. 3 September 2024. W3C Working Draft. URL: https://www.w3.org/TR/push-api/
[w3c-process]
    ＜W3C Process Document＞. Elika J. Etemad (fantasai); Florian Rivoal.  W3C. 3 November 2023. URL: https://www.w3.org/policies/process/
[Web-Share]
    ＜Web Share API＞. Matt Giuca; Eric Willigers; Marcos Caceres.  W3C. 30 May 2023. W3C Recommendation. URL: https://www.w3.org/TR/web-share/
[window-management]
    ＜Window Management＞. Joshua Bell; Mike Wasserman.  W3C. 7 June 2024. W3C Working Draft. URL: https://www.w3.org/TR/window-management/


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより編集者草案として公開された
<a href="~SPEC_URL">Permissions</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/permissions/
公表履歴
	https://www.w3.org/standards/history/permissions/
編集者草案
	https://w3c.github.io/permissions/
commit 履歴
	https://github.com/w3c/permissions/commits/main
編集
	<a href="https://marcosc.com">Marcos Cáceres</a> (Apple Inc.)
	<a href="https://miketaylr.com/posts/">Mike Taylor</a> (Google LLC)
前任編集者
	Mounir Lamouri (Google LLC)
	Jeffrey Yasskin (Google LLC)

フィードバック
	<a href="https://github.com/w3c/permissions/">GitHub w3c/permissions</a> (<a href="https://github.com/w3c/permissions/pulls/">pull requests</a>, <a href="https://github.com/w3c/permissions/issues/new/choose">new issue</a>, <a href="https://github.com/w3c/permissions/issues/">open issues</a>)
ブラウザサポート
	https://caniuse.com/permissions-api

公表者
	<a href="https://www.w3.org/groups/wg/webappsec">Web Application Security WG</a>

</script>

<body>

<header>
	<hgroup>
<h1>許可 — Permissions</h1>
<p title="Interacting with Permissions for Powerful Features">強力な特能用の許可とのやりとり法</p>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
この仕様は、
他の仕様が~browser許可とヤリトリするために利用できる共通な基盤を定義する。
これらの許可は、
利用者が［
~web~platformが “強力な特能” に~accessする許可
］を［
許容する, 否認する
］どちらを選んだかを表現する。
開発者~向けには、
この仕様は，［
強力な特能の許可~状態を~queryして，［
それを利用する許可の状態が変化したとき，通知される
］ようにする
］ための~APIを標準~化する。
◎
This specification defines common infrastructure that other specifications can use to interact with browser permissions. These permissions represent a user's choice to allow or deny access to "powerful features" of the platform. For developers, the specification standardizes an API to query the permission state of a powerful feature, and be notified if a permission to use a powerful feature changes state.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
これは、編集者草案の公な複製です…
【以下、この節の他の内容は，~SOTD-W3Cに移譲。】
</p>

	</section>

<main id="MAIN0">
	<section>
<h2 title="Introduction">1. 序論 </h2>

◎非規範的

<p>
各~仕様は、［
`強力な特能$として明示的に識別される特能
］を定義し得る。
これらの特能が “強力” と称されるのは、［
~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＼
</p>
<ul>
	<li>
利用者が許可を表出するまでは、
この能を否認する。
◎
to deny sites the ability to use these features until they have given express permission,＼
</li>
	<li>
通例的に，この能を是認する時間を制限する。
◎
and usually only granting this ability for a limited amount of time.＼
</li>
</ul>

<p>
利用者が［
強力な特能を利用することを~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.
</p>

<figure id="fig-sketches-of-possible-permission-prompt-types">
<div class="alt" id="_dgm-sample-prompts">
<p>
図左：
通知~promptの~mockupは、
2 つの~button “許容しない”, “許容する” を伴う。
この~promptは、
“~web~site `example.com^c は、あなたに通知を送信したがっています”
と言明する。
◎
On the left, a mockup of a notifications prompt with an allow and don't allow buttons that states 'the website example.com would like to send you notifications'.＼
</p>

<p>
図右：
~URL~barの近くにある~promptは、［
~cameraと~microphoneを利用する許可
］を `example.com^c ~siteに与えるよう依頼している。
◎
On the right, a prompt near the URL bar asking to give permission to the camera and microphone to the example site.
</p>
</div>
<figcaption>
許可~promptの型としてアリなもの 2 つの素描
◎
Figure 1 Sketches of possible permission prompt types
</figcaption></figure>

<p>
許可は、
このイミにおいて，［
ある種の型の特能
— 特に “強力な特能” —
に対する利用者の同意
］の現在の状態を表現する：
◎
In this sense, a permission represents the current state of user consent for certain types of features, and particularly "powerful features".＼
</p>
<ul>
	<li>
<p>
最終的には、
利用者が：
◎
Ultimately the user＼
</p>
		<ul>
			<li>
これらの許可の制御を維持する。
◎
retains control of these permissions＼
</li>
			<li>
選好を通して，これらの許可を手動で［
是認する／否認する
］能を有する。
◎
and have the ability to manually grant or deny permissions through user preferences.＼
</li>
		</ul>
	</li>
	<li>
<p>
~UAは、
許可の管理-法において，利用者を支援する
— 例えば，次を行うことにより：
◎
Further, user agents assist users in managing permissions by, for example,＼
</p>
		<ul>
			<li>
ある種の
— さもなければ煩わしくなる —
許可~promptを隠す, あるいは自動的に否認する。
◎
hiding and automatically denying certain permission prompts that would otherwise be a nuisance,＼
</li>
			<li>
利用者が~web~siteをしばらく訪問しなかった後には、
是認した許可を自動的に失効させる。
◎
and automatically expiring granted permissions if a user doesn't visit a website for some time.
</li>
		</ul>
	</li>
</ul>

<figure id="fig-a-sketch-of-a-possible-site-specific-permissions-controls-ui">
<p class="alt" id="_dgm-permission-settings">
ある設定群~pageの~mockup
— それは、［
所在,
~camera,
~microphone,
~motion~sensor,
通知
］用の許可の既定を［
設定する／設定し直す
］ことを利用者に許容する。
◎
A mockup of a settings page that would allow a user to set or reset defaults for location, camera, microphone, motion sensors, and notifications permissions.
</p>

<figcaption>
~siteに特有な許可~制御~UIとしてアリなものの素描
◎
Figure 2 A sketch of a possible site-specific permissions controls UI
</figcaption></figure>

	</section>
	<section id="examples-of-usage">
<h2 title="Examples of usage">2. 用例</h2>

◎非規範的

<div class="example" id="example-using-state-attribute">
<p>
次の例は、
`許可~API＠#permissions-api$を利用して，［
`Geolocation$cite を利用して地域newsを示すべき
］か, または［
当の特能を追加する~buttonを提供する
］かどうかを裁定する。
◎
This example uses the Permissions API to decide whether local news should be shown using the Geolocation API or with a button offering to add the feature.
◎
Example 1: Using .state attribute
</p>

<pre class="lang-js">
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;
}
</pre>
</div>

<div class="example" id="example-checking-the-state-of-multiple-permissions">
<p>
次の例は、［
`geolocation^l, `notifications^l
］で`識別される特能$の状態を同時に検査する：
◎
This example simultaneously checks the state of the "geolocation" and "notifications" powerful features:
◎
Example 2: Checking the state of multiple permissions
</p>

<pre class="lang-js">
const %queryPromises = ["geolocation", "notifications"].map(
  %name =&gt; navigator.permissions.query({ %name })
);
for await (const %status of %queryPromises) {
  console.log(``^${%status.name}: ${%status.state}``^);
}
</pre>
</div>

<div class="example" id="example-checking-permission-state-of-multiple-cameras">
<p>
次の例は、
可用な各~cameraの`許可~状態$を検査する。
◎
This example is checking the permission state of the available cameras.
◎
Example 3: Checking permission state of multiple cameras
</p>

<pre class="lang-js">
const %devices = await navigator.mediaDevices.enumerateDevices();

/* <span class="comment">
動画~入力のみに~filterしてから，~query~objに対応付ける
◎
filter on video inputs, and map to query object
</span>
const %queries = %devices
  .filter(({ %kind }) =&gt; %kind === "videoinput")
  .map(({ %deviceId }) =&gt; ({ name: "camera", %deviceId }));

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

try {
  const %results = await Promise.all(%promises);
  /* <span class="comment">
状態や各~cameraの~logをとる
◎
log the state of each camera
</span>
  %results.forEach(({ %state }, %i) =&gt; console.log("Camera", %i, %state));
} catch (%error) {
  console.error(%error);
}
</pre>
</div>

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

		<section id="permissions">
<h3 title="Permissions">3.1. 許可</h3>

<p>
`許可@
は、［
ある`強力な特能$を利用することを~web~appに許容する
］ことに対する利用者の裁定を表現する。
この裁定は、
許可がとる`状態$として表現される。
◎
A permission represents a user's decision to allow a web application to use a powerful feature. This decision is represented as a permission state.
</p>

<p>
`許可を表出する@
とは、利用者が［
~web~appが`強力な特能$を利用する能
］を`是認-$することを指す。
◎
Express permission refers to the user granting the web application the ability to use a powerful feature.
</p>

<div class="note" id="issue-container-generatedID">
<p>注記（制限と拡張能）：
現在の~Web~APIには、
いくつかの異なる［
許可を処する仕方
］がある。
例えば `Notifications API$cite は、
開発者が明示的に許可を要請して，
許可~状態sを検査できるようにする。
~APIを利用しようと試行したときに限り，
許可~状態sを~web~pageに公開するものもある。
例えば `Geolocation$cite は、
開発者が前もって検査するのを許容することなく，
許可が是認されていなければ失敗する。
◎
Note: Limitations and extensibility
◎
Current Web APIs have different ways to deal with permissions. For example, the Notifications API Standard allows developers to request a permission and check the permission status explicitly. Others expose the status to web pages only when they try to use the API, e.g., the Geolocation which fails if the permission was not granted without allowing the developer to check beforehand.
</p>

<p>
この文書に述べる解決策は，拡張できるように意味されているが、
~web~platformにて可用な［
現在の／将来の
］許可~すべてに適用-可能になるとは期待されてはいない。
許可~modelを孕む仕様を策定している~WGは，
その~modelが この文書に述べる~modelに収まらないときには、
`課題を申請して＠https://github.com/w3c/permissions/issues$，
そのことを編集者に~~伝えるべきである。
◎
The solution described in this document is meant to be extensible, but isn't expected to be applicable to all the current and future permissions available in the web platform. Working Groups that are creating specifications whose permission model doesn't fit in the model described in this document should contact the editors by filing an issue.
</p>
</div>

<p>
`強力な特能$ %特能 用の`許可$は、
概念的には，次に挙げるいずれかの
`状態@
をとり得る
【括弧内は、対応する `PermissionState$I 値】：
◎
Conceptually, a permission for a powerful feature can be in one of the following states:
</p>
<dl>
	<dt>
`否認-@
された
（ `denied$l ）
◎
"denied":
</dt>
	<dd>
利用者は，または［
利用者に利するためとして，~UA
］は、
%特能 への~accessを否認した。
~call元は、
%特能 を利用-可能でなくなる。
◎
The user, or the user agent on the user's behalf, has denied access to this powerful feature. The caller won't be able to use the feature.
</dd>

	<dt>
`是認-@
された
（ `granted$l ）
◎
"granted":
</dt>
	<dd>
利用者は，または［
利用者に利するためとして，~UA
］は、
%特能 を利用する`許可を表出-$した。
~call元は、
%特能 を
— 場合によっては，`~UA$が利用者に許可を依頼することなく —
利用-可能になる。
◎
The user, or the user agent on the user's behalf, has given express permission to use a powerful feature. The caller will be able to use the feature possibly without having the user agent asking the user's permission.
</dd>

	<dt>
`~prompt@
（ `prompt$l ）
◎
"prompt":
</dt>
	<dd>
利用者は、
まだ， %特能 を利用する`許可を表出-$していない
（すなわち，`否認-$されたときと同じになる）。
それはまた、
次を意味する
⇒
~call元が %特能 を利用しようと試みた場合、［
`~UA$は，許可について利用者に~promptする
］ことになるか，さもなければ［
%特能 への~accessは`否認-$される
］ことになる。
◎
The user has not given express permission to use the feature (i.e., it's the same as "denied"). It also means that if a caller attempts to use the feature, the user agent will either be prompting the user for permission or access to the feature will be "denied".
</dd>
</dl>

<p>
~UAは、
`利用者の意図についての新たな情報@
を突止めるときは，
利用者の意図nについての情報を収集して解釈してもヨイ。
この情報は、［
明示的な利用者-動作
］から来ることもあれば，［
当の利用者や他の利用者たちの挙動,
この仕様が見越していない
`暗黙的な兆候@
］を集成して得られることもある。
◎
To ascertain new information about the user's intent, a user agent MAY collect and interpret information about a user's intentions. This information can come from explicit user action, aggregate behavior of both the relevant user and other users, or implicit signals this specification hasn't anticipated.
</p>

<p class="note">注記（何が`暗黙的な兆候$を成すか？）：
`暗黙的な兆候$には，例えば、
どの~web~appが`~installされ$ていて, どの程度［
頻繁／近過去
］に訪問しているか，などが挙げられる
— 利用者が自身が~installした~web~appを より［
近過去／頻繁
］に利用しているほど，それを信用している可能性が高い。
実装には、
暗黙的な兆候に依拠するときには，~~注意深くあたることを勧める。
◎
Note: What constitutes an implicit signal?
◎
The implicit signals could be, for example, the installation status of a web application or frequency and recency of visits. A user that has installed a web application and used it frequently and recently is more likely to trust it. Implementations are advised to exercise caution when relying on implicit signals.
</p>

<p>
どの`許可$にも，
`存続期間@
がある
— それは、
特定0の許可が［
`既定の状態$へ復帰する前に，`是認-$された状態であり続ける期間
］である。
`存続期間$は、［
特定0の`~realm$が破壊されるまで／
特定0の`~top-level閲覧~文脈$が破壊されるまで／
特定0の量の時間／
無限
］いずれにもなり得る。
存続期間は、
末端利用者が
— 通例的に，何らかの［
許可~UI／`~UA$定義な施策
］を介して —
`強力な特能$を利用する`許可を表出する$ときに，
当の利用者と~UAの間で折衝される。
◎
Every permission has a lifetime, which is the duration for which a particular permission remains "granted" before it reverts back to its default state. A lifetime could be until a particular Realm is destroyed, until a particular top-level browsing context is destroyed, a particular amount of time, or be infinite. The lifetime is negotiated between the end-user and the user agent when the user gives express permission to use a feature—usually via some permission UI or user-agent defined policy.
</p>

<p>
どの`許可$にも
`既定の状態@
がある
（通例的には`~prompt$）
— それは、
次のいずれかに該当するとき，当の許可がとる`状態$である
⇒＃
利用者は、まだ当の`強力な特能$を利用する`許可を表出-$していない／
当の許可は、その`存続期間$が失効したために設定し直された
◎
Every permission has a default state (usually "prompt"), which is the state that the permission is in when the user has not yet given express permission to use the feature or it has been reset because its lifetime has expired.
</p>

		</section>
		<section id="permission-store">
<h3 title="Permission Store">3.2 許可~store</h3>

<p>
~UAは、
1 個の
`許可~store@
を保守する。
それは、
`許可~store~entry$たちが成す`~list$である。
この~listにおいては、
それを成すどの`許可~store~entry$も，この~list内で［
その ( `記述子$psE, `~key$psE ) に`合致する許可~store~entry$
］は自身のみに限られる†。
◎
The user agent maintains a single permission store which is a list of permission store entries. Each particular entry denoted by its descriptor and key can only appear at most once in this list.
</p>

<p class="trans-note">【†
これは、［
`許可~store~entryを設定する$, `許可~store~entryを除去する$
］~algoにより施行される。
】</p>

<p>
~UAは、
`許可~store$を成す どの`許可~store~entry$ %~entry に対しても
⇒
%~entry の`記述子$psEで`識別される特能$に対する`許可$の`存続期間$が失効したときには、
`許可~store$から %~entry を除去してヨイ。
◎
The user agent MAY remove entries from the permission store when their respective permission's lifetime has expired.
</p>

<div class="p">
<p>
`許可~store~entry@
は、次に挙げるものからなる`~tuple$である：
</p>
<ul>
	<li>
`記述子@psE
⇒
`PermissionDescriptor$I
</li>
	<li>
`~key@psE
⇒
`許可~key$
</li>
	<li>
`状態@psE
⇒
`状態$
</li>
</ul>
◎
A permission store entry is a tuple of PermissionDescriptor descriptor, permission key key, and state state.
</div>

<p>
所与の`許可~store~entry$ %~entry が所与の
( `PermissionDescriptor$I %記述子, `許可~key$ %~key )
に
`合致する許可~store~entry@
であるとは、
次を満たすことをいう
⇒
［
%~entry の`記述子$psE ~EQ %記述子 †
］~AND［
`同等な許可~key$( %記述子, %~entry の`~key$psE, %~key ) ~EQ ~T
］
</p>

<p class="trans-note">【
この定義は、
以下の記述を集約するための，この訳による追加
】【†
記述子どうしの比較は、
それらを成す~memberごとの比較に基づくと思われるが，
この仕様のみからは判別し得ない。
】</p>

<div class="algo">
<p>
`許可~store~entryを取得する@
~algoは、
所与の
( `PermissionDescriptor$I %記述子, `許可~key$ %~key )
に対し：
</p>
<ol>
	<li>
%~entry群 ~LET ~UAの`許可~store$内の［
( %記述子, %~key ) に`合致する許可~store~entry$
］たちが成す~list
</li>
	<li>
~Assert：
%~entry群 の`~size$ ~LTE 1
</li>
	<li>
~RET %~entry群 の`~size$に応じて
⇒＃
0 ならば ~NULL ／
1 ならば %~entry群[ 0 ]
</li>
</ol>
◎
To get a permission store entry given a PermissionDescriptor descriptor and permission key key:
• If the user agent's permission store contains an entry whose descriptor is descriptor, and whose key is equal to key given descriptor, return that entry.
• Return null.
</div>

<div class="algo">
<p>
`許可~store~entryを設定する@
~algoは、
所与の
( `PermissionDescriptor$I %記述子, `許可~key$ %~key, `状態$ %状態 )
に対し：
◎
To set a permission store entry given a PermissionDescriptor descriptor, a permission key key, and a state state, run these steps:
</p>
<ol>
	<li>
%新たな~entry ~LET 新たな`許可~store~entry$
— その
⇒＃
`記述子$psE ~SET %記述子,
`~key$psE ~SET %~key,
`状態$psE ~SET %状態
◎
Let newEntry be a new permission store entry whose descriptor is descriptor, and whose key is key, and whose state is state.
</li>
	<li>
~UAの`許可~store$の中で［
( %記述子, %~key ) に`合致する許可~store~entry$
］を %新たな~entry で`置換する$
◎
If the user agent's permission store contains an entry whose descriptor is descriptor, and whose key is equal to key given descriptor, replace that entry with newEntry＼
↓ and abort these steps.
</li>
	<li>
~IF［
前~段にて置換された~entryは無い
］
⇒
~UAの`許可~store$に %新たな~entry を`付加する$
◎
Append newEntry to the user agent's permission store.
</li>
</ol>
</div>

<div class="algo">
<p>
`許可~store~entryを除去する@
~algoは、
所与の
( `PermissionDescriptor$I %記述子, `許可~key$ %~key )
に対し：
◎
To remove a permission store entry given a PermissionDescriptor descriptor and permission key key, run these steps:
</p>
<ol>
	<li>
~UAの`許可~store$から［
( %記述子, %~key ) に`合致する許可~store~entry$
］を`除去する$
◎
Remove the entry whose descriptor is descriptor, and whose key is equal to key given descriptor, from the user agent's permission store.
</li>
</ol>
</div>

<p>
`許可~key@
【がとり得る値】の型は、
【それを利用する】特能の`許可~key型$により定義される。
◎
A permission key has its type defined by a feature's permission key type.
</p>

<p class="note">注記：
許可~keyは、
許可を是認する視野を定義する
— この視野は、
通例的には`生成元$ごとになる。
`強力な特能$は、
`許可~key型$を~customな許可~keyを指定するよう上書きし得る。
これは、［
許可の粒度を追加的な文脈に基づいて変更したいと求める特能
］用に有用になる
— ［
埋込まれた【内容の】生成元, ~top-level【の内容の】生成元
］両者で~keyを二重化するなど。
◎
Note

The permission key defines the scope of a permission grant, which is usually per-origin. Powerful features may override the permission key type to specify a custom permission key. This is useful for features that want to change the granularity of permissions based on additional context, such as double-keying on both an embedded origin and a top-level origin.
</p>

<div class="algo">
<p>
`同等な許可~key@
かどうか決定するときは、
所与の
( `PermissionDescriptor$I %記述子, `許可~key$ %key1, `許可~key$ %key2 )
に対し，次の手続きを走らす：
◎
To determine whether a permission key key1 is equal to a permission key key2, given a PermissionDescriptor descriptor, run the following steps:
</p>
<ol>
	<li>
%特能 ~LET %記述子 で`識別される特能$
◎
↓</li>
	<li>
~IF［
%key1 は %特能 の`許可~key型$の値でない
］~OR［
%key2 は %特能 の`許可~key型$の値でない
］
⇒
~RET ~F
◎
If key1 is not of descriptor's permission key type or key2 is not of descriptor's permission key type, return false.
</li>
	<li>
~RET %特能 の`許可~key比較~algo$( %key1, %key2 )
◎
Return the result of running the permission key comparison algorithm for the feature named by descriptor's name, passing key1 and key2.
</li>
</ol>
</div>

		</section>
		<section id="powerful-features">
<h3 title="Powerful features">3.3. 強力な特能</h3>

<p>
`強力な特能@
とは、
~web~platform特能のうち，［
それを利用できるようになる前に，利用者が`許可を表出する$必要があるもの
］（通例的には、ある~API）である。
少数の留意すべき例外（例： `Notifications API$cite ）を除く，
ほとんどの強力な特能は、
`施策により制御される特能$でもある。
`許可~施策$cite 仕様 `Permissions-Policy$r は、
所与の，そのような特能~用に［
`文書$には，その`利用は許容され$るかどうか
］を制御する。
すなわち、［
ある`強力な特能$が，利用者に`許可を表出する$よう要請できる
］のは，当の`文書$が［
対応する`施策により制御される特能$（下の例を見よ）を介して委任された許可
］を有する場合に限られる。
当の特能に対する後続な~accessは、［
利用者が許可を`是認-$した，あるいは［
`是認-$されたのと等価な何らかの判定基準
］が満たされている
］かどうかにより決定される。
◎
A powerful feature is a web platform feature (usually an API) for which a user gives express permission before the feature can be used. Except for a few notable exceptions (e.g., the Notifications API Standard), most powerful features are also policy-controlled features. For powerful features that are also policy-controlled features, [Permissions-Policy] controls whether a document is allowed to use a given feature. That is, a powerful feature can only request express permission from a user if the document has permission delegated to it via the corresponding policy-controlled feature (see example below). Subsequent access to the feature is determined by the user having "granted" permission, or by satisfying some criteria that is equivalent to a permission grant.
</p>

<div class="example" id="example-powerful-features-are-policy-controlled-features">
<p>
`施策により制御される特能$でもある`強力な特能$の例。
</p>

<p>
この例は、［
`allow$a 属性を通して設定された許可~施策
］が［
`iframe$e には、
`強力な特能$の`利用は許容されて$いるかどうか
］を どう制御するかを示す。
</p>

<pre class="html-code">
&lt;iframe src="https://example.com/" allow="geolocation"&gt;&lt;/iframe&gt;
</pre>

<p>
`geolocation^l 【により`識別される特能$】は許容されるので、
`iframe$e の文書【`内容~文書$】は，
`Geolocation$cite を利用する許可を利用者に要請できる
（すなわち、
利用者に対し，［
自身の所在~情報への~accessに対する`許可を表出する$か
］について~promptすることになる）。
しかしながら，他の特能は、
`allow$a 属性~内に挙げられていないので，［
それを利用するために許可を要請することは、
自動的に否認される
］ことになる。
</p>

<p>
さらなる情報は、
`§ 許可~施策~仕様との関係性＠#relationship-to-permissions-policy$
を見よ。
</p>

◎
Example 4: Powerful features are policy-controlled features
◎
This example shows how the permissions policy set through the allow attribute controls whether the iframe is allowed to use a powerful feature. Because "geolocation" is allowed, the iframe's document can request permission from the user to use the Geolocation (i.e., it will prompt the user for express permission to access their location information). However, requesting permission to use any other feature will be automatically denied, because they are not listed in the allow attribute.
◎
&lt;iframe src="https://example.com/" allow="geolocation"&gt;
&lt;/iframe&gt;
◎
See A. Relationship to the Permissions Policy specification for more information.
</div>

<p>
`強力な特能$は、
文字列（例： `geolocation^l ）として与えられる
`名前@
により識別される
⇒
所与の`名前$で
`識別される特能@
は、
そのように識別される`強力な特能$を指す。
所与の `PermissionDescriptor$I %記述子 で`識別される特能$は、
%記述子[ "`name$mb" ] で`識別される特能$を指す。
◎
A powerful feature is identified by its name, which is a string literal (e.g., "geolocation").
</p>

<p class="trans-note">【
“〜で`識別される特能$” は、
他所を［
明確化する／簡便に記す
］ための，この訳による追加。
】</p>

<p>
~UAは、［
利用者が
どの`強力な特能$に利用する`許可$を
— `環境~設定群~obj$を介して —
与えているか
］について追跡することになる。
◎
The user agent tracks which powerful features the user has permission to use via the environment settings object.
</p>

			<section id="aspects">
<h4 title="Aspects">3.3.1. 側面</h4>

<p>
各 `強力な特能$は、
0 個以上の追加的な
`側面@
を定義できる。
各`側面$は、［
`PermissionDescriptor$I を`継承-$diCする~Web~IDL`辞書$
］により定義され，
~Web~IDL用の`許可~記述子~型$として~serveする。
◎
Each powerful feature can define zero or more additional aspects. An aspect is defined as WebIDL dictionary that inherits from PermissionDescriptor and serves as a WebIDL interface's permission descriptor type.
</p>

<div class="example" id="example-defining-your-own-permission-descriptor-type">
<p>
自前の`許可~記述子~型$を定義する例。
ある仮の`強力な特能$ “~food検出器~API” が，
2 つの`側面$
— ［
~taste, ~smell
］を~senseすることを許容する側面 —
を伴うとする
【すなわち、この~APIは，名前 `senses^l で`識別される特能$であるとする】。
当の仕様は、［
`PermissionDescriptor$I を`継承-$diCする新たな辞書
］として，次を定義することになろう：
◎
Example 5: Defining your own permission descriptor type
◎
A hypothetical powerful feature "food detector API" has two aspects that allow sensing taste and smell. So, a specification would define a new WebIDL interface that inherits PermissionDescriptor:
</p>

<pre>
dictionary SensesPermissionDescriptor : PermissionDescriptor {
  boolean canSmell = false;
  boolean canTaste = false;
};
</pre>

<p>
それは、
次の仕方で，~APIを介して~queryされることになろう：
◎
Which would then be queried via the API in the following way:
</p>

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

<p>
利用者は、
強力な特能 `senses^l を `taste^l に限るよう制約し得る
— その事例では、
上の `PermissionStatus$I 【すなわち %status 】の `state$m は `denied$l になる。
◎
A user can restrict the "senses" powerful feature to only "taste", in which case the PermissionStatus's state above would be "denied" .
</p>
</div>

			</section>
		</section>
		<section id="permissions-task-source">
<h3 title="Permissions task source">3.4. 許可~task~source</h3>

<p>
`許可~task~source@
は、
`~task~source$であり，
この仕様にて許可に関係する`~task$を遂行するために利用される。
◎
The permissions task source is a task source used to perform permissions-related tasks in this specification.
</p>

		</section>
	</section>
	<section id="specifying-a-powerful-feature">
<h2 title="Specifying a powerful feature">4. 強力な特能の指定-法</h2>

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

<p class="advisement">
新たに指定される`強力な特能$を`許可~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.
</p>

<dl>
	<dt>
`許可~記述子~型@
◎
A permission descriptor type:
</dt>
	<dd>
`PermissionDescriptor$I, または その下位型。
◎
PermissionDescriptor or one of its subtypes.＼
</dd>
	<dd>
未指定な場合の既定は、
`PermissionDescriptor$I とする。
◎
If unspecified, this defaults to PermissionDescriptor.
</dd>
	<dd>
<p>
%特能 は、
記述子の各~instance間において
`より強い@
と称される`半順序＠https://en.wikipedia.org/wiki/Partially_ordered_set$を定義できる。
［
記述子 %A は記述子 %B `より強い$
］ならば、
次が満たされなければナラナイ：
</p>
		<ul>
			<li>
［
%A の`許可~状態$ ~EQ `granted$l
］ならば［
%B の`許可~状態$ ~EQ  `granted$l
］
</li>
			<li>
［
%B の`許可~状態$ ~EQ `denied$l
］ならば［
%A の`許可~状態$ ~EQ `denied$l
］
</li>
		</ul>
◎
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".
</dd>
	<dd class="example" id="example-stronger-than">
半順序を定義する許可~記述子の例：
`{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.
</dd>

	<dt>
`許可~状態~拘束@
◎
permission state constraints:
</dt>
	<dd>
~UAが記述子の`許可~状態$として返せる値を拘束する。
◎
Constraints on the values that the user agent can return as a descriptor's permission state.＼
</dd>
	<dd>
既定では、
利用者の意図を超える拘束は無いとする。
◎
Defaults to no constraints beyond the user's intent.
</dd>

	<dt>
`~extra許可~data型@
◎
extra permission data type:
</dt>
	<dd>
<p>
一部の`強力な特能$には、
`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.
</p>

<p class="note">注記：
例えば、
`getUserMedia()$m は，次を決定する必要がある
⇒
利用者は、
`どの~camera^emに~accessする許可を是認したか
◎
Note

For example, getUserMedia() needs to determine which cameras the user has granted permission to access.
</p>
	</dd>
	<dd class="algo">
<p>
ある文字列【！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:
</p>
		<ol>
			<li>
~IF［
%設定群 ~EQ ε
］
⇒
%設定群 ~SET `現在の設定群~obj$
◎
If settings wasn't passed, set it to the current settings object.
</li>
			<li>
<p>
~IF［
この~algoは、
以前に，同じ
( %名前, %設定群 )
で呼出された
］~AND［
~UAは、
以前の時点から［
`利用者の意図についての新たな情報$
］をまだ受取ってない
］
⇒
~RET 以前の時点における結果
</p>

<p class="trans-note">【
“以前” がどこまで遡れるかは、
少なくとも`存続期間$までに制限されよう。
】</p>
◎
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.
</li>
			<li>
~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.
</li>
		</ol>
	</dd>
	<dd>
指定された場合、
%特能 の`~extra許可~data$を利用-可能になる。
◎
If specified, the extra permission data algorithm is usable for this feature.
</dd>
	<dd class="trans-note">【
すなわち，既定では、
`~extra許可~data$は無い。
】【
この “~data型” に何らかの~IDLが含意されるかどうかは、
定かでない
（この用語を利用している他の仕様を見なければ判明しない）。
】</dd>

	<dt>
`~extra許可~data拘束@
◎
Optional extra permission data constraints:
</dt>
	<dd>
~UAが %特能 の`~extra許可~data$として返せる値を拘束する。
◎
Constraints on the values that the user agent can return as a powerful feature's extra permission data.＼
</dd>
	<dd>
既定では、
利用者の意図を超える拘束は無いとする。
◎
Defaults to no constraints beyond the user's intent.
</dd>

	<dt>
`許可~結果型@
◎
A permission result type:
</dt>
	<dd>
`PermissionStatus$I
または，その下位型。
◎
PermissionStatus or one of its subtypes.＼
</dd>
	<dd>
未指定な場合の既定は、
`PermissionStatus$I とする。
◎
If unspecified, this defaults to PermissionStatus.
</dd>

	<dt>
`許可~query~algo@
◎
A permission query algorithm:
</dt>
	<dd>
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.＼
</dd>
	<dd>
未指定な場合の既定は、
`既定の許可を~queryする~algo$とする。
◎
If unspecified, this defaults to the default permission query algorithm.
</dd>
	<dd class="algo">
`既定の許可を~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.
</dd>

	<dt>
`許可~key型@
◎
A permission key type:
</dt>
	<dd>
%特能 が利用する`許可~key$の型。
◎
The type of permission key used by the feature.＼
</dd>
	<dd>
未指定な場合の既定は、
`生成元$とする。
◎
Defaults to origin.＼
</dd>
	<dd>
~customな`許可~key型$を指定する特能は、
`許可~key生成~algo$も指定しなければナラナイ。
◎
A feature that specifies a custom permission key type MUST also specify a permission key generation algorithm.
</dd>

	<dt>
`許可~key生成~algo@
◎
A permission key generation algorithm:
</dt>
	<dd>
所与の`環境~設定群~obj$に対し，新たな`許可~key$を返す。
◎
Takes an environment settings object, and returns a new permission key.＼
</dd>
	<dd>
未指定な場合の既定は、
`既定の許可~key生成~algo$になる。
◎
If unspecified, this defaults to the default permission key generation algorithm.＼
</dd>
	<dd>
~customな`許可~key生成~algo$を指定する特能は、
`許可~key比較~algo$も指定しなければナラナイ。
◎
A feature that specifies a custom permission key generation algorithm MUST also specify a permission key comparison algorithm.
</dd>
	<dd class="algo">
`既定の許可~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.
</dd>
	<dd class="note">注記（許可の委任）：
ほとんどの`強力な特能$は、
その許可を~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.
</dd>

	<dt>
`許可~key比較~algo@
◎
A permission key comparison algorithm:
</dt>
	<dd>
所与の
2 個の`許可~key$に対し，それらが等しいかどうかを示す`真偽値$を返す。
◎
Takes two permission keys and returns a boolean that shows whether the two keys are equal.＼
</dd>
	<dd>
未指定な場合の既定は、
`既定の許可~key比較~algo$とする。
◎
If unspecified, this defaults to the default permission key comparison algorithm.
</dd>
	<dd class="algo">
`既定の許可~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.
</dd>

	<dt>
`許可~revocation~algo@
◎
A permission revocation algorithm:
</dt>
	<dd>
引数はとらない。
実装における他の部分
— ［
`許可~状態$ ／ `~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.
</dd>
	<dd>
<p>
未指定な場合の既定は、
`利用者により許可が~revokeされたとき反応する$†。
</p>

<p class="trans-note">【†
これは、
`許可~revocation~algo$を呼出すので，定義が循環している。
実際には、
その手続きの中の［
`許可~revocation~algo$を遂行する段
］以外を遂行することになろう。
】</p>
◎
If unspecified, this defaults to running react to the user revoking permission.
</dd>

	<dt>
許可の`存続期間$
◎
A permission lifetime:
</dt>
	<dd>
`強力な特能$を定義する仕様は、
当の特能に対する`許可$の`存続期間$として，
最良に適するものを示唆するベキである。
下に、
許可~存続期間の決定-法に関する指導を
— 特に，利用者の~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.
</dd>
	<dd class="algo">
<p>
所与の`強力な特能$に対する［
ある生成元~用の許可
］の`存続期間$が失効したときは：
◎
When the permission lifetime expires for an origin:
</p>
		<ol>
			<li>
当の許可の`状態$を，その既定の`許可~状態$（例： `~prompt$）に設定し直す
◎
Set the permission back to its default permission state (e.g., by setting it back to "prompt").
</li>
			<li>
当の生成元に属する
~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.
</li>
		</ol>
	</dd>
	<dd class="note">
<p>
注記（許可の存続期間の決定-法）
— `存続期間$は、
当の`強力な特能$や~UAに応じて様々になる：
◎
Note: Determining the lifetime of a permission
</p>
		<ul>
			<li>
特に~privacyに敏感な特能
（例： `Media Capture and Streams＠~TR/mediacapture-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.＼
</li>
			<li>
他の【~privacyに敏感な】特能
（例： `Geolocation$cite ）
に対しては、
~UAは，当の許可を［
当の~session ／ 1 日
］に限り是認する~~選択肢を提供することが知られている。
◎
For other features, like the Geolocation, user agents are known to offer a choice of only granting the permission for the session, or for one day.＼
</li>
			<li>
他のもの
（例： `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.＼
</li>
		</ul>
<p>
許可の`存続期間$は、
~UAごとに有意に変わり得ることに注意。
◎
Note that permission lifetimes can vary significantly between user agents.
</p>

<p>
ある許可の存続期間~用に的確な~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＼
</p>
<ul>
	<li>
~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,＼
</li>
	<li>
ある~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).
</li>
</ul>

<p>
ある`強力な特能$用に示唆する`存続期間$が不確かな場合、
`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.
</p>
	</dd>

	<dt>
`既定の許可~状態@
◎
Default permission state:
</dt>
	<dd>
`PermissionState$I 値のうち，［
%特能 に対する`許可$
］の`既定の状態$として~serveするもの。
◎
An PermissionState value that serves as a permission's default state of a powerful feature.
</dd>
	<dd>
指定されていない場合、
【！`許可$の`既定の状態$は】
`prompt$l になるとする。
◎
If not specified, the permission's default state is "prompt".
</dd>
</dl>

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

	</section>
	<section id="algorithms-to-interface-with-permissions">
<h2 title="Algorithms to interface with permissions">5. 許可と~interfaceするための~algo</h2>

		<section id="reading-current-states">
<h3 title="Reading the current permission state">5.1. 現在の許可~状態の読取n法</h3>

<p>
所与の［
`名前$ ／ `PermissionDescriptor$I
］ %名前または記述子 の
`許可~状態@
は、
次の結果の略記である
⇒
`現在の許可~状態を取得する$( %名前または記述子 )
◎
↓</p>

<p class="trans-note">【
原文では，`現在の許可~状態を取得する$~algoが`許可~状態$の定義に基づくよう定義されているが、
この訳では，逆になるよう改める。
また、
簡便に利用できるよう，これらが［
`名前$, `PermissionDescriptor$I
］両者を受容するよう改める。
】</p>

<div class="algo">
<p>
`現在の許可~状態を取得する@
~algoは、
所与の
⇒＃
［ `名前$ ／ `PermissionDescriptor$I ］ %名前または記述子,
`環境~設定群~obj$ %設定群 （省略時は ε ）
◎終
に対し， `PermissionState$I 列挙値を返す：
◎
To get the current permission state, given a name name and an optional environment settings object settings, run the following steps. This algorithm returns a PermissionState enum value.
• Let descriptor be a newly-created PermissionDescriptor with name initialized to name.
• Return the permission state of descriptor with settings.
◎
↑ A descriptor's permission state, given an optional environment settings object settings is the result of the following algorithm. It returns a PermissionState enum value:
</p>
<ol>
	<li>
~IF［
%設定群 ~EQ ε
］
⇒
%設定群 ~SET `現在の設定群~obj$
◎
If settings wasn't passed, set it to the current settings object.
</li>
	<li>
~IF［
%設定群 は`~secureな文脈$enVでない
］
⇒
~RET `denied$l
◎
If settings is a non-secure context, return "denied".
</li>
	<li>
<p>
%特能 ~LET %名前または記述子 で`識別される特能$
◎
Let feature be descriptor's name.
</p>

<p class="trans-note">【
この段は， %特能 が存在しない（それを定義する仕様が無い）事例を想定していないが、
そのような事例も，あるかもしれない
— この手続きが`許可を設定する拡張d~command＠#dfn-set-permission$から呼出された場合など。
その場合、
~UAは %特能 を~supportしないかのように挙動することも考えられる。
】</p>
	</li>
	<li>
<p>
~IF［
%特能 は`施策により制御される特能$である
］：
</p>
		<ol>
			<li>
%大域~obj ~LET %設定群 の`大域~obj$enV【！`関連な大域~obj$】
</li>
			<li>
~IF［
%大域~obj は `Window$I ~objである
］~AND［
%大域~obj に`結付けられた文書$には %特能 の`利用は許容されて$いない
］
⇒
~RET `denied$l
</li>
		</ol>
◎
If there exists a policy-controlled feature for feature and settings' relevant global object has an associated Document run the following step:
• Let document be settings' relevant global object's associated Document.
• If document is not allowed to use feature, return "denied".
</li>
	<li>
%~key ~LET %特能 の`許可~key生成~algo$( %記述子, %設定群 )
◎
Let key be the result of generating a permission key for descriptor with settings.
</li>
	<li>
%~entry ~LET `許可~store~entryを取得する$( %記述子, %~key )
◎
Let entry be the result of getting a permission store entry with descriptor and key.
</li>
	<li>
~IF［
%~entry ~NEQ ~NULL
］
⇒
~RET %~entry の`状態$psEを表現する `PermissionState$I 列挙値
◎
If entry is not null, return a PermissionState enum value from entry's state.
</li>
	<li>
~RET 
%特能 用の`許可~状態~拘束$も織り込む下で，
%特能 の許可~状態を表現する `PermissionState$I 列挙値
◎
Return the PermissionState enum value that represents the permission state of feature, taking into account any permission state constraints for descriptor's name.
◎
↑↑ As a shorthand, a DOMString name's permission state is the permission state of a PermissionDescriptor with its name member set to name.
</li>
</ol>
</div>

		</section>
		<section id="requesting-more-permission">
<h3 title="Requesting permission to use a powerful feature">5.2. 強力な特能を利用する更なる許可の要請-法</h3>

<div class="algo">
<p>
`利用する許可を要請する@
~algoは、
所与の
( ［
`名前$ ／ `PermissionDescriptor$I
］ %名前または記述子 %記述子 )
に対し，［
`granted$l ／ `denied$l
］を返す：
◎
To request permission to use a descriptor, the user agent must perform the following steps. This algorithm returns either "granted" or "denied".
</p>
<ol>
	<li>
%記述子 ~LET %名前または記述子
◎
↓↓</li>
	<li>
~IF［
%名前または記述子 は文字列である
］
⇒
%記述子 ~SET 新たな `PermissionDescriptor$I
— その
⇒＃
`name$mb ~member ~SET %名前または記述子
◎
↓↓</li>
	<li>
%現在の状態 ~LET `現在の許可~状態を取得する$( %記述子 )
◎
Let current state be the descriptor's permission state.
</li>
	<li>
%特能 ~LET %記述子 で`識別される特能$
◎
↓</li>
	<li>
~IF［
%現在の状態 ~NEQ `prompt$l
］
⇒
~RET %現在の状態
◎
If current state is not "prompt", return current state and abort these steps.
</li>
	<li>
<p>
次に対する`許可を表出する$よう，利用者に依頼する
⇒
~call元~の~algoが %特能 を利用すること
◎
Ask the user for express permission for the calling algorithm to use the powerful feature described by descriptor.
</p>

<p>
その結果に応じて
⇒
%現在の状態 ~LET ［
利用者は`許可を表出-$したならば `granted$l ／
~ELSE_ `denied$l
］
◎
If the user gives express permission to use the powerful feature, set current state to "granted"; otherwise to "denied".＼
</p>

<p>
この結果は、
当の`生成元$【 %特能 が利用している`許可~key$】用の［
`利用者の意図についての新たな情報$
］を供するものとしてヨイ。
◎
The user's interaction may provide new information about the user's intent for the origin.
</p>

<div class="note">
<p>注記：
ここでの［
許可~UI／
~UAが利用者の意図をどう推定するか
］の詳細~については、
意図的に曖昧にしてある。
~UAは、
この~frameworkの下で数多の~UIを探求するべきである。
◎
Note

This is intentionally vague about the details of the permission UI and how the user agent infers user intent. User agents should be able to explore lots of UI within this framework.
</p>
<p class="trans-note">【
例えば、
利用者が是認せず，明示的に否認することもなく~UIを退けた場合、
`利用者の意図についての新たな情報$としては扱わないことも考えられる。
あるいは，利用者により予め為された環境設定に基づいて、
利用者からの~~回答を待機することなく，即時に結果を返すこともあるかもしれない。
】</p>
</div>
	</li>
	<li>
%~key ~LET `許可~key生成~algo$( `現在の設定群~obj$ )
◎
Let key be the result of generating a permission key with the current settings object.
</li>
	<li>
<p>
`~taskを~queueする$( 【`~task~source$が指定されていない（`許可~task~source$？）】, 次の手続き, `現在の設定群~obj$の`担当の~event~loop$enV )
◎
Queue a task on the current settings object's responsible event loop to＼
</p>

<p class="algo">
手続きは
⇒
`許可~store~entryを設定する$( %記述子, %~key, %現在の状態 )
◎
set a permission store entry with descriptor, key, and current state.
</p>
	</li>
	<li>
~RET %現在の状態
◎
Return current state.
◎
↑↑ As a shorthand, requesting permission to use a DOMString name, is the same as requesting permission to use a PermissionDescriptor with its name member set to name.
</li>
</ol>
</div>

		</section>
		<section id="prompt-the-user-to-choose">
<h3 title="Prompt the user to choose">5.3. 何かを選ぶよう利用者に~promptする</h3>

<div class="algo">
<p>
~UAは，
%記述子 に結付けられた %選択肢~群 の中から一つ以上を
`選ぶよう利用者に~promptする@
~algoは、
所与の
( 【！`真偽値$】 %複数を許容するか ~IN { `複数を許容する^i, ε } （省略時は ε ） )
に対し，［
`denied$l ／ 利用者の選択
］を返す：
◎
To prompt the user to choose one or more options associated with a given descriptor and an optional boolean allowMultiple (default false), the user agent must perform the following steps. This algorithm returns either "denied" or the user's selection.
</p>
<ol>
	<li>
%許可~状態 ~LET `現在の許可~状態を取得する$( %記述子 )
◎
↓</li>
	<li>
~IF［
%許可~状態 ~EQ `denied$l
］
⇒
~RET `denied$l
◎
If descriptor's permission state is "denied", return "denied" and abort these steps.
</li>
	<li>
任意選択で，利用者に~promptすることなく
⇒
~IF［
%許可~状態 ~EQ `granted$l
］
⇒
~RET %選択肢~群 を成す選択肢のうち［
%複数を許容するか ~EQ ε ならば一つ ／
~ELSE_ 一つ以上
］
⇒
この場合，~UAは、
後続な同じ
( %記述子, 選択肢の集合 )
から`選ぶよう利用者に~promptする$ときも、
~UAが`利用者の意図についての新たな情報$を受取っていない限り，同じ［
選択肢／選択肢たち
］を返すモノトスル。
◎
If descriptor's permission state is "granted", the user agent may return one (or more if allowMultiple is true) of options chosen by the user and abort these steps. If the user agent returns without prompting, then subsequent prompts for the user to choose from the same set of options with the same descriptor must return the same option(s), unless the user agent receives new information about the user's intent.
</li>
	<li>
<p>
利用者に［
%選択肢~群 から一つ（以上）の選択肢を選ぶか, 許可を否認するか
］依頼した上で：
◎
Ask the user to choose one or more options or deny permission,＼
</p>
		<ol>
			<li>
利用者が選ぶまで待機する
◎
and wait for them to choose:
</li>
			<li>
~IF［
利用者は %選択肢~群 から何も選ばなかった（否認した）
］
⇒
~RET `denied$l
◎
↓</li>
			<li>
%選択 ~LET 利用者が選んだ一つ以上の選択肢
— ~call元~の~algoが［
~prompt内に含める~extra情報
］を指定した場合、
それも結果に含める
◎
If the calling algorithm specified extra information to include in the prompt, include it.
</li>
			<li>
~IF［
%複数を許容するか ~EQ ε
］
⇒
%選択 を成す選択肢たちを 1 個の~itemに制約する
◎
If allowMultiple is false, restrict selection to a single item from options; otherwise, any number may be selected by the user.
</li>
			<li>
~RET %選択
◎
If the user chose one or more options, return them;＼
↑↑ otherwise return "denied".
</li>
		</ol>
<p class="note">注記：
ここでの［
許可~UI ／
~UAが利用者の意図をどう推定するか
］の詳細~については、
意図的に曖昧にしてある。
~UAは、
この~frameworkの下で数多の~UIを探求するべきである。
（例：許可~promptは、
利用者が明示的な選定を為すことなく時間~切れになって，自動的に `denied^l を返すこともある）。
◎
Note

This is intentionally vague about the details of the permission UI and how the user agent infers user intent. User agents should be able to explore lots of UI within this framework (e.g., a permission prompt could time out and automatically return "denied" without the user making an explicit selection).
</p>
	</li>
</ol>
</div>

<p>
所与の文字列【！DOMString】 %名前 に結付けられた選択肢~群から［
一つ／一つ以上
］を`選ぶよう利用者に~promptする$とは、
次の略記である
⇒
［
`name$mb ~memberが %名前 に設定された`PermissionDescriptor$I 
］に結付けられた選択肢~群から［
`選ぶよう利用者に~promptする$() ／
`選ぶよう利用者に~promptする$( `複数を許容する^i )
］
◎
As a shorthand, prompting the user to choose from options associated with a DOMString name, is the same as prompting the user to choose from those options associated with a PermissionDescriptor with its name member set to name.
</p>

		</section>
		<section id="reacting-to-revocation">
<h3 title="Reacting to users revoking permission">5.4. 利用者から許可が~revokeされたときの反応-法</h3>

<div class="algo">
<p>
~UAは、［
利用者が，もはや次を意図しない
］ことを学習したときは
⇒
［
`許可~key$ %~key により述べられる文脈
］において［
`PermissionDescriptor$I %記述子 で`識別される特能$
］を利用する許可を是認すること
◎終
次に与える
`利用者により許可が~revokeされたとき反応する@
手続きを走らすとする：
◎
When the user agent learns that the user no longer intends to grant permission to use a feature described by the PermissionDescriptor descriptor in the context described by the permission key key, react to the user revoking permission by running these steps:
</p>
<ol>
	<li>
%記述子 により`識別される特能$の`許可~revocation~algo$()
◎
Run descriptor's name's permission revocation algorithm.
</li>
	<li>
`許可~store~entryを除去する$( %記述子, %~key )
◎
Remove a permission store entry with descriptor and key.
</li>
</ol>
</div>

		</section>
	</section>
	<section id="permissions-api">
<h2 title="Permissions API">6. 許可~API</h2>

		<section id="navigator-and-workernavigator-extension">
<h3 title="Extensions to the Navigator and WorkerNavigator interfaces">6.1. `Navigator^I, `WorkerNavigator^I ~interfaceに対する拡張</h3>

<pre class="idl">
[`Exposed$=(Window)]
partial interface `Navigator$I {
  [`SameObject$] readonly attribute `Permissions$I `permissions@m;
};
</pre>

<pre class="idl">
[`Exposed$=(Worker)]
partial interface `WorkerNavigator$I {
  [`SameObject$] readonly attribute `Permissions$I `~permissions0@m;
};
</pre>

		</section>
		<section id="permissions-interface">
<h3 title="Permissions interface">6.2. `Permissions^I ~interface</h3>

<pre class="idl">
[`Exposed$=(Window,Worker)]
interface `Permissions@I {
  `Promise$&lt;`PermissionStatus$I&gt; `query$m(`object$ %permissionDesc);
};

dictionary `PermissionDescriptor@I {
  required `DOMString$ `name@mb;
};
</pre>

<div class="algo" id="query-method">
`query(permissionDesc)@m
~method手続きは
⇒
`許可を~queryする$( %permissionDesc )
◎
5.2.1 query() method
◎
When the query() method is invoked, the user agent MUST run the following＼
</div>

<div class="algo">
<p>
`許可を~queryする@
~algoは、
所与の
( %記述子 )
に対し：
◎
query a permission algorithm, passing the parameter permissionDesc:
</p>
<ol>
	<li>
~IF［
コレに`関連な大域~obj$は `Window$I ~objである
］~AND［
`現在の設定群~obj$に`結付けられた文書$は`全部的に作動中$でない
］
⇒
~RET `却下される~promise$( `InvalidStateError$E 例外 )
◎
If this's relevant global object is a Window object, then:
• If the current settings object's associated Document is not fully active, return a promise rejected with an "InvalidStateError" DOMException.
</li>
	<li>
<p>
%根~記述子 ~LET `~IDL値に変換する$( %記述子, `PermissionDescriptor$I )
◎
Let rootDesc be the object permissionDesc refers to, converted to an IDL value of type PermissionDescriptor.
</p>

<p>
例外が投出されたときは
⇒
~RET `却下される~promise$( その例外 )
◎
If the conversion throws an exception, return a promise rejected with that exception.
</p>

<p class="trans-note">【
この~algoを利用する `query()$m ~methodから渡される %記述子 は，
~Web~IDLに則って暗黙的に~IDL `object^c 型に`変換される＠~WEBIDLjs#js-object$が、
ここでは， %記述子 は生の~JS `object^jt 値である（すなわち、元々渡された~JS値である）ものと見做されている
— それでも、
`object^c 型への変換における例外は，
ここで例外を取扱うに先立って `query()^m ~methodから投出される。
】</p>
	</li>
	<li>
%特能 ~LET %根~記述子[ `name$mb ] で`識別される特能$
◎
↓</li>
	<li>
<p>
~IF［
~UAは %特能 を~supportしない
］
⇒
~RET `却下される~promise$( `TypeError$E 例外 )
◎
If rootDesc["name"] is not supported, return a promise rejected with a TypeError.
</p>

<p class="note">注記
（ `name$mb の型が列挙型でないのは、なぜか？）：
`name$mb は，
~Web~IDLの`列挙$（ `enum^c ）と同じに働くよう，故意に設計されており、
実装者には，ここで自前の~customな列挙型を利用することが奨励される。
これが仕様において列挙型でない理由は、
~browserごとに［
`強力な特能$としてどれを~supportするか
］が大きく変わるからである。
文字列（ `DOMString^c ）を利用して強力な特能を識別することは、
実装者に［
`許可~registry$から，
自身が~supportしたいと望む強力な特能を選びとる自由度
］を与える。
◎
Note: Why is this not an enum?
◎
This is deliberately designed to work the same as WebIDL's enumeration (enum) and implementers are encouraged to use their own custom enum here. The reason this is not an enum in the specification is that browsers vary greatly in the powerful features they support. Using a DOMString to identify a powerful feature gives implementers the freedom to pick and choose which of the powerful features from the Permissions Registry they wish to support.
</p>
	</li>
	<li>
<p>
%有型~記述子 ~LET `~IDL値に変換する$( %記述子, %特能 の`許可~記述子~型$ )
◎
Let typedDescriptor be the object permissionDesc refers to, converted to an IDL value of rootDesc's name's permission descriptor type.
</p>

<p>
例外が投出されたときは
⇒
~RET `却下される~promise$( その例外 )
◎
If the conversion throws an exception, return a promise rejected with that exception.
</p>
	</li>
	<li>
%~promise ~LET `新たな~promise$
◎
Let promise be a new promise.
</li>
	<li>
~RET %~promise
— ただし、
以降の手続きも`並列的$に走らす
◎
Return promise and continue in parallel:
</li>
	<li>
%状態s ~LET `許可~状態sを作成する$( %有型~記述子 )
◎
Let status be create a PermissionStatus with typedDescriptor.
</li>
	<li>
%~query ~LET %状態s .`query$sl
◎
Let query be status's [[query]] internal slot.
</li>
	<li>
【！%~query[ "`name$mb" ] で`識別される特能$】
%特能 の`許可~query~algo$( %~query, %状態s )
◎
Run query's name's permission query algorithm, passing query and status.
</li>
	<li>
<p>
`大域~taskを~queueする$( `許可~task~source$, コレに`関連な大域~obj$, 次の手続き )
</p>

<div class="algo">
手続きは
⇒
`~promiseを解決する$( %~promise, %状態s )
</div>
◎
Queue a global task on the permissions task source with this's relevant global object to resolve promise with status.
</li>
</ol>
</div>

		</section>
		<section id="permissionstatus-interface">
<h3 title="PermissionStatus interface">6.3. `PermissionStatus^I ~interface</h3>

<pre class="idl">
[`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,
};
</pre>

<p>
`PermissionStatus$I の各~instanceは、
`query@sl
内部~slotを伴って作成される。
それは、［
ある`強力な特能$の`許可~記述子~型$
］の~instanceを~~保持する。
◎
PermissionStatus instances are created with a [[query]] internal slot, which is an instance of a feature's permission descriptor type.
</p>

<p>
［
`granted@l
は`是認-$された／
`denied@l
は`否認-$された／
`prompt@l
は`~prompt$する
］ことの概念を表現する。
◎
The "granted", "denied", and "prompt" enum values represent the concepts of "granted", "denied", and "prompt" respectively.
</p>

<div class="algo">
<p id="creating-instances">
`許可~状態sを作成する@
~algoは、
所与の
( `PermissionDescriptor$I %記述子 )
に対し：
◎
6.3.1. Creating instances
◎
To create a PermissionStatus for a given PermissionDescriptor permissionDesc:
</p>
<ol>
	<li>
%名前 ~LET %記述子[ "`name$mb" ]
◎
Let name be permissionDesc's name.
</li>
	<li>
%特能 ~LET %名前 で`識別される特能$
◎
↓</li>
	<li>
~Assert：
~UAは %特能 を~supportする。
◎
Assert: The feature identified by name is supported by the user agent.
</li>
	<li>
%状態s ~LET ［
%特能 の`許可~結果型$
］の新たな~instance
— その
⇒＃
`query$sl ~SET %記述子,
`name$m ~SET %名前
◎
Let status be a new instance of the permission result type identified by name:
• Initialize status's [[query]] internal slot to permissionDesc.
• Initialize status's name to name.
</li>
	<li>
~RET %状態s
◎
Return status.
</li>
</ol>
</div>

<div class="algo" id="name-attribute">
`name@m
取得子~手続きは、
初期化-時の値を返す。
◎
6.3.2. name attribute
◎
The name attribute returns the value it was initialized to.
</div>

<div class="algo" id="state-attribute">
`state@m
取得子~手続きは、
最後に設定された値を返す。
◎
6.3.3. state attribute
◎
The state attribute returns the latest value that was set on the current instance.
</div>

<p id="onchange-attribute">
`onchange@m
属性は、
`~event~handler~event型$ `change^et に対応する`~event~handler$である。
◎
6.3.4. onchange attribute
◎
The onchange attribute is an event handler whose corresponding event handler event type is change.
</p>

<div class="algo">
<p id="PermissionStatus-update">
`~UA$は， `PermissionStatus$I ~instance %状態s の状態が変化したことに自覚したときは、
いつでも，次の
`許可~状態s更新~手続き@
を非同期的に走らすモノトスル：
◎
Whenever the user agent is aware that the state of a PermissionStatus instance status has changed, it asynchronously runs the PermissionStatus update steps:
</p>
<ol>
	<li>
%大域~obj ~LET %状態s【！this】 に`関連な大域~obj$
◎
↓</li>
	<li>
<p>
~IF［
%大域~obj は `Window$I ~objである
］：
◎
If this's relevant global object is a Window object, then:
</p>
		<ol>
			<li>
%文書 ~LET %大域~obj に`結付けられた文書$
◎
Let document be status's relevant global object's associated Document.
</li>
			<li>
~IF［
%文書 ~EQ ~NULL
］~OR［
%文書 は`全部的に作動中$でない
］
⇒
~RET
◎
If document is null or document is not fully active, terminate this algorithm.
</li>
		</ol>
	</li>
	<li>
%状態s .`query$sl で`識別される特能$の`許可~query~algo$( %~query, %状態s )
◎
Let query be status's [[query]] internal slot.
◎
Run query's name's permission query algorithm, passing query and status.
</li>
	<li>
<p>
`~taskを~queueする$( `許可~task~source$, 次の手続き )
</p>

<p class="algo">
手続きは
⇒
`~eventを発火する$( %状態s, `change^et )
</p>
◎
Queue a task on the permissions task source to fire an event named change at status.
</li>
</ol>
</div>

			<section id="permissionstatus-gc">
<h4 title="Garbage collection">6.3.1. ~garbage収集</h4>

<p>
`PermissionStatus$I ~objは、
型 `change^et の`~event~listener$がある間は，
~garbage収集してはナラナイ。
◎
A PermissionStatus object MUST NOT be garbage collected if it has an event listener whose type is change.
</p>

			</section>
		</section>
	</section>
	<section id="conformance">
<h2 title="Conformance">適合性</h2>

<p class="trans-note">【
この節の他の内容は、
`~W3C日本語訳 共通~page＠~W3Ccommon#conformance$
に移譲。
】</p>

<p>
この仕様への適合性を主張できる製品には、
次に挙げる 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).
</p>

	</section>
	<section id="relationship-to-permissions-policy">
<h2 title="Relationship to the Permissions Policy specification">A. 許可~施策~仕様との関係性</h2>

◎非規範的

<p>
この仕様, `許可~施策$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.
</p>

<p>
この仕様が専ら懸念する`強力な特能$は、
その~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.
</p>

<p>
他方，`許可~施策$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.
</p>

<p>
`許可~施策$cite 仕様により不能化される`強力な特能$は、
この仕様においては，その`許可~状態$は常に `denied$l （否認された）として反映される。
このことは、［
`現在の許可~状態を取得する$ことが
`HTML$r の “`利用は許容されて$いるかどうか” の検査に依拠する
］ことから生じる
— この検査~自体も，`許可~施策$cite 仕様の中へ~callする。
ここでの重要な注意点は、
許可の名前が両~仕様にて共有されることである。
この仕様, `許可~施策$cite 仕様は、
どちらも［
許可の名前~群, `名前$
］を定義している他の仕様に依拠し，
それらは通例的に同じモノを命名する
（例： `Geolocation$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, and so on).
</p>

<p>
最後に，ある`強力な特能$が［
`許可~施策$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.
</p>

	</section>
	<section id="automation">
<h2 title="Automated testing">B. 自動化された~test法</h2>

<p>
この文書は、
~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.
</p>

<pre class="idl">
dictionary `PermissionSetParameters@I {
  required `object$ `descriptor@mb;
  required `PermissionState$I `state@mb;
};
</pre>

<div class="algo">
<p>
`許可を設定する@
~algoは、
所与の
⇒＃
`PermissionDescriptor$I %記述子,
`PermissionState$I %状態,
`生成元$ %生成元（省略時は ~NULL ）,
`~UA$ %~UA（省略時は ε ）
◎終
に対し：
◎
To set a permission given a PermissionDescriptor descriptor, a PermissionState state, an optional origin, and an optional user agent:
</p>
<ol>
	<li>
~IF［
%生成元 ~EQ ~NULL
］
⇒
%生成元 ~SET `現在の設定群~obj$の`生成元$enV
◎
Let target origin be current settings object's origin if origin is null, or origin otherwise.
</li>
	<li>
%~target群 ~LET ~AND↓ を満たす
`環境~設定群~obj$たちが成す`~list$
【順序は指定されていない】
⇒
( その`生成元$enV, %生成元 )
は`同一-生成元$である
◎
Let targets be a list containing all environment settings objects whose origin is same origin with target origin,＼
</li>
	<li>
<p>
~IF［
%~UA ~NEQ ε
］
⇒
%~target群 から %~UA に属さないものを`除去する$
</p>
<p class="trans-note">【
この段の~logicは、
複数の`~UA$が`同時に稼働し得る＠https://github.com/w3c/permissions/pull/438$ことに基づく。
例えば、［
私的~閲覧~mode下で稼働するものと他のもの／
異なる利用者~profileの下で稼働するものどうし
］は，異なる~UAであると見なされる。
】</p>
◎
and which belong to the user agent if provided, or all user agents otherwise.
</li>
	<li>
%~task群 ~LET 新たな`~list$
◎
Let tasks be an empty list.
</li>
	<li>
<p>
%~target群 を成す
~EACH( %~target )
に対し：
◎
For each environment settings object target in targets:
</p>
		<ol>
			<li>
%閲覧~文脈 ~LET %~target に`関連な設定群~obj$の`大域~obj$enVに`対応する閲覧~文脈$
◎
↓</li>
			<li>
<p>
%~task ~LET `~taskを~queueする$( %閲覧~文脈 の`許可~task~source$, 次の手続き )
◎
Queue a task task on the permissions task source of target's relevant settings object's global object's browsing context to＼
</p>

<div class="algo">
手続きは
⇒
%状態 を，この時点で次を呼出した結果であったかのように解釈する
⇒
`現在の許可~状態を取得する$( %記述子, %~target )
◎
perform the following step:
• Interpret state as if it were the result of an invocation of permission state for descriptor with the argument target made at this moment.
</div>
			</li>
			<li>
%~task群 に %~task を`付加する$
◎
Append task to tasks.
</li>
		</ol>
	</li>
	<li>
%~task群 を成す`~task$すべてが実行されるまで待機する
◎
Wait for all tasks in tasks to have executed and return.
</li>
</ol>
</div>


<p class="trans-note">【
この訳では、
この節に利用される `WEBDRIVER$r 用の用語に以下に挙げる表記を用いる：
】</p>

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

		<section id="automation-webdriver">
<h3 title="B.1 Automated testing with [WebDriver]">B.1. ~WebDriver用の自動化された~test法</h3>

<p>
この文書は、
`WebDriver$r 仕様~用に，
以下に与える`拡張~command$を定義する。
◎
This document defines the following extension commands for the [WebDriver] specification.
</p>

			<section id="webdriver-command-set-permission">
<h4 title="B.1.1. Set Permission">B.1.1. 許可を設定する</h4>

<div>
<table><thead>
<tr><th>~HTTP~method
</th><th>`~URI~template$
</th></tr></thead><tbody>

<tr><td>`POST^hm
</td><td>`/session/{session id}/permissions^c
</td></tr></tbody></table>
◎
HTTP Method 	URI Template
POST 	/session/{session id}/permissions 
</div>

<p>
`許可を設定する＠#dfn-set-permission@
`拡張~command$は、
`PermissionDescriptor$I の`許可~状態$に対する利用者-改変を模倣する。
◎
The Set Permission extension command simulates user modification of a PermissionDescriptor's permission state.
</p>

<div class="algo">
<p>
その`~remote端~手続き$は、
所与の
( %~parameter群 )
に対し：
◎
The remote end steps are:
</p>
<ol>
	<li>
%~parameter辞書 ~SET `~IDL値に変換する$( %~parameter群, `PermissionSetParameters$I )
⇒
例外が投出されたときは
⇒
~RET `~error$wdr( `無効な引数$ )
◎
Let parametersDict be the parameters argument, converted to an IDL value of type PermissionSetParameters. If this throws an exception, return an invalid argument error.
</li>
	<li>
<p>
~IF［
%~parameter辞書[ "`state$mb" ] は、
何らかの実装~定義な理由により，`許可~状態$として不適切である
］
⇒
~RET `~error$wdr( `無効な引数$ )
◎
If parametersDict.state is an inappropriate permission state for any implementation-defined reason, return an invalid argument error.
Note
</p>

<p class="note">注記：
例えば、
`~UA$が［
`midi^l で`識別される特能$を “常にオン” として定義する
］ならば，［
`許可~状態$を `denied$l に設定する~command
］をこの段で却下することを選べる。
◎
Note

For example, user agents that define the "midi" powerful feature as "always on" can choose to reject a command to set the permission state to "denied" at this step.
</p>
	</li>
	<li>
%根~記述子 ~LET %~parameter辞書[ "`descriptor$mb" ]
◎
Let rootDesc be parametersDict.descriptor.
</li>
	<li>
%特能 ~LET `Get$jA(%根~記述子, `name^l ) で`識別される特能$
◎
↓</li>
	<li>
<p>
%有型~記述子 ~LET `~IDL値に変換する$( %根~記述子, %特能 の`許可~記述子~型$ )
⇒
例外が投出されたときは
⇒
~RET `~error$wdr( `無効な引数$ )
</p>

<p class="trans-note">【
%特能 が存在しない（それを定義する仕様が無い）場合の挙動が指定されていない。
同じように`~error$wdrになりそうだが、
現在は未知な特能であると解釈して（~UAが %特能 を~supportしない場合と同様に），
`許可~記述子~型$は既定の `PermissionDescriptor$I であったかのように挙動する方が自然とも思われる。
】</p>
◎
Let typedDescriptor be the object rootDesc refers to, converted to an IDL value of permission descriptor type matching the result of Get(rootDesc, "name"). If this throws an exception, return a invalid argument error.
</li>
	<li>
`許可を設定する$( %有型~記述子, %~parameter辞書[ "`state$mb" ] )
◎
Set a permission with typedDescriptor and parametersDict.state.
</li>
	<li>
~RET `成功$wdr( ~NULL )
◎
Return success with data null.
</li>
</ol>
</div>

<div class="example" id="example-setting-a-permission-via-webdriver">
<p>
~WebDriverを介して`許可を設定する＠#dfn-set-permission$例：
`現在の設定群~obj$の［
~ID 23 を伴う`~session$
］の
`{name: "midi", sysex: true}^c
用の許可を `granted$l に設定するときは、
`局所~端$は，［
本体として次を伴わせて，
`/session/23/permissions^c へ `POST^hm する
］ことになる：
◎
Example 7: Setting a permission via WebDriver 
◎
To set permission for {name: "midi", sysex: true} of the current settings object of the session with ID 23 to "granted", the local end would POST to /session/23/permissions with the body:
</p>

<pre class="lang-js">{
  "descriptor": {
    "name": "midi",
    "sysex": true
  },
  "state": "granted"
}
</pre>
</div>

			</section>
		</section>
		<section id="automation-webdriver-bidi">
<h3 title="B.2 Automated testing with [WebDriver-BiDi]">B.2. ~WebDriver-BiDi用の自動化された~test法</h3>

<p>
この文書は、
`WebDriver-BiDi$r 仕様~用に以下に与える`拡張~module$を定義する。
◎
This document defines the following extension modules for the [WebDriver-BiDi] specification.
</p>

			<section id="webdriver-bidi-module-permissions">
<h4 title="B.2.1 The permissions Module">B.2.1. 許可~module</h4>

<p>
`許可~module@
は、
`~remote端$の~browser許可を管理するための~commandを包含する。
◎
The permissions module contains commands for managing the remote end browser permissions.
</p>

				<section id="webdriver-bidi-module-permissions-definition">
<h5 title="B.2.1.1 Definition">B.2.1.1. 定義</h5>

<p>
`~remote端~定義$：
◎
remote end definition
</p>

<pre class="cddl remote-cddl">
PermissionsCommand = (
  permissions.setPermission
)
</pre>

				</section>
				<section id="webdriver-bidi-module-permissions-types">
<h5 title="B.2.1.2 Types">B.2.1.2. 型</h5>

					<section id="webdriver-bidi-type-permissions-PermissionDescriptor">
<h6 title="B.2.1.2.1 The permissions.PermissionDescriptor Type">B.2.1.2.1. `permissions.PermissionDescriptor^c 型</h6>

<pre class="cddl local-cddl">
permissions.PermissionDescriptor = {
  name: text,
}
</pre>

<p>
`permissions.PermissionDescriptor^c 型は、
`PermissionDescriptor$I を表現する。
◎
The permissions.PermissionDescriptor type represents a PermissionDescriptor.
</p>

					</section>
					<section id="webdriver-bidi-type-permissions-PermissionState">
<h6 title="B.2.1.2.2 The permissions.PermissionState Type">B.2.1.2.2. `permissions.PermissionState^c 型</h6>

<pre class="cddl local-cddl">
permissions.PermissionState = "granted" / "denied" / "prompt"
</pre>

<p>
`permissions.PermissionState^c 型は、
`PermissionState$I を表現する。
◎
The permissions.PermissionState type represents a PermissionState.
</p>

					</section>
				</section>
				<section id="webdriver-bidi-module-permissions-commands">
<h5 title="B.2.1.3 Commands">B.2.1.3. ~command</h5>

					<section id="webdriver-bidi-command-permissions-setPermission">
<h6 title="B.2.1.3.1 The permissions.setPermission Command">B.2.1.3.1. `permissions.setPermission^c ~command</h6>

<p>
`許可を設定する＠#dfn-set-permission-0@
`~command$は、［
`PermissionDescriptor$I の`許可~状態$に対する利用者-改変
］を模倣する。
◎
The Set Permission command simulates user modification of a PermissionDescriptor's permission state.
</p>
<dl>
	<dt>
~command型
◎
Command Type
</dt>
	<dd>
<pre class="cddl remote-cddl">
permissions.setPermission = (
  method: "permissions.setPermission",
  params: permissions.SetPermissionParameters
)

permissions.SetPermissionParameters = {
  descriptor: permissions.PermissionDescriptor,
  state: permissions.PermissionState,
  origin: text,
  ? userContext: text,
}
</pre>
	</dd>

	<dt>
結果~型
◎
Result Type
</dt>
	<dd>
`EmptyResult^c
</dd>
</dl>

<div class="algo">
<p>
その`~remote端~手続き$は、
所与の
( %~session, %~command~parameter群 )
に対し：
◎
The remote end steps with session and command parameters are:
</p>
<ol>
	<li>
%記述子 ~LET %~command~parameter群 を成す `descriptor^c ~fieldの値
◎
Let descriptor be the value of the descriptor field of command parameters.
</li>
	<li>
%許可~名 ~LET %記述子 を成す `name^c ~fieldの値
（これは、 `name$mb を表現する）
◎
Let permission name be the value of the name field of descriptor representing name.
</li>
	<li>
%状態 ~LET %~command~parameter群 を成す `state^c ~fieldの値
◎
Let state be the value of the state field of command parameters.
</li>
	<li>
%利用者~文脈~ID ~LET %~command~parameter群 を成す `userContext^c ~fieldは［
在るならば その値／
無いならば `default^l
］
◎
Let user context id be the value of the userContext field of command parameters, if present, and default otherwise.
</li>
	<li>
~IF［
%状態 は、
何らかの実装~定義な理由により，`許可~状態$として不適切である
］
⇒
`~error$wdr( `無効な引数$ )
◎
If state is an inappropriate permission state for any implementation-defined reason, return error with error code invalid argument.
</li>
	<li>
%~parameter群 ~LET 新たな `object^jt
（これは `PermissionSetParameters$I を成す）
— その
⇒＃
`descriptor^l ~prop ~SET %記述子,
`state^l ~prop ~SET %状態
◎
↓</li>
	<li>
%有型~記述子 ~LET `~IDL値に変換する$( %~parameter群, %許可~名 で`識別される特能$の`許可~記述子~型$ )
⇒
例外が投出されたときは
⇒
~RET `~error$wdr( `無効な引数$ )
◎
Let typedDescriptor be the object descriptor refers to, converted to an IDL value (descriptor, state) of PermissionSetParameters permission name's permission descriptor type. If this conversion throws an exception, return error with error code invalid argument.
</li>
	<li>
%生成元 ~LET %~command~parameter群 を成す `origin^c ~fieldの値
◎
Let origin be the value of the origin field of command parameters.
</li>
	<li>
<p>
%~UA ~LET 次を満たす`利用者~文脈$を表現する`~UA$
⇒
その`利用者~文脈~ID$ ~EQ %利用者~文脈~ID
◎
Let user agent be the user agent that represents the user context with the id user context id.
</p>

<p class="trans-note">【
条件を満たすものが無い場合の挙動が指定されていない。
在るならば、
利用者~文脈~IDの定義により，一つに限られる。
】</p>
	</li>
	<li>
`許可を設定する$( %有型~記述子, %状態, %生成元, %~UA )
◎
Set a permission with typedDescriptor, state, and origin. 
</li>
	<li>
~RET `成功$wdr( ~NULL )
◎
Return success with data null.
</li>
</ol>
</div>

					</section>
				</section>
			</section>
		</section>
	</section>
	<section id="permissions-registry">
<h2 title="Permissions Registry">C. 許可~registry</h2>

◎非規範的

		<section id="purpose">
<h3 title="Purpose">C.1. 目的</h3>

<p>
この`~W3C~registry＠~W3C-Process#w3c-registry$は、
~web~platformを成す［
`施策により制御される特能$／`強力な特能$
］を見出すための中心的な場を供する。
また、
`変更~過程$を通して，［
~platformにおける許可が様々な仕様にまたがって一貫して指定される
］ことを確約し易くする。
◎
This W3C Registry provides a centralized place to find the policy-controlled features and/or powerful features of the web platform. Through the change process it also helps assure permissions in the platform are consistently specified across various specifications.
</p>

<p>
この~registryは、［
標準~化された許可, 暫定的な許可
］に分割することにより，
これらの特能の位置付けを追跡する仕方も供する。
◎
By splitting the registry into standardized permissions and provisional permissions, the registry also provides a way to track the status of these features.
</p>

		</section>
		<section id="change-process">
<h3 title="Change Process">C.2. 変更~過程</h3>

<p>
この~registry［
に何かを追加する／を更新する
］ための
`変更~過程@
は、
以下に従う：
◎
The change process for adding and/or updating this registry is as follows:
</p>
<ol>
	<li>
<p>
必要yなら、
当の仕様に “§ 許可~施策” を追加して，次に挙げるものを含める：
◎
If necessary, add a "Permissions Policy" section to your specification which includes the following:
</p>
		<ol>
			<li>
当の［
施策により制御される特能
］を識別する文字列
（例： `super-awesome^l ）。
この文字列は、
`dfn$e 要素で包装することにより，~link可能にすること。
◎
The string that identifies the policy controlled feature (e.g., "super-awesome"). Make sure the string is linkable by wrapping it a dfn element.
</li>
			<li>
<p>
`既定の許容list$用の値
（例： `'self'^l ）。
◎
The default allowlist value (e.g. 'self').
</p>

<div class="example">
<p>
この判定基準を満たすことになろう，
ある`許可~施策$を指定する典型的な例：
◎
Example 8: Specifying a Permissions Policy
◎
An typical example that would meet this criteria:
</p>
<blockquote>
`The Super Awesome API^cite は、
文字列 `super-awesome^l により識別される`施策により制御される特能$を定義する。
その`既定の許容list$は `'self'^l とする。
◎
The Super Awesome API defines a policy-controlled feature identified by the string "super-awesome". Its default allowlist is 'self'.
</blockquote>
</div>
			</li>
		</ol>
	</li>
	<li>
当の特能は、
`強力な特能$の定義を満たす
（すなわち、
`許可を表出する$ことを利用するよう要求される）
か否かを決定する。
満たす場合、
`許可$cite 仕様への適合性に従って，
当の仕様~内に`強力な特能を指定する$こと。
◎
Determine if your feature meets the definition of a powerful feature (i.e., requires express permission to be used). If it does:
• Specify a powerful feature in your specification in conformance with the Permissions specification.
</li>
	<li>
［
`標準~化された許可たちが成す表t$／`暫定的な許可たちが成す表t$
］いずれかを改変する
— 表tの各欄すべてを要求される情報で埋めるよう。
◎
Modify either the table of standardized permissions or the table of provisional permissions filling out each column with the required information.
</li>
	<li>
GitHub 上の`強力な特能たちが成す~registry用の~repository＠https://github.com/w3c/permissions/$cite
（ `Powerful Features Registry Repository^en ）に対し［
~registryに対する変更点を伴わせた~pull要請
］を提出する。
この~repositoryの保守者は、
この~pull要請を考査して，あらゆるものが適正に統合されたかどうか検査することになる。
◎
Submit a pull request to the Powerful Features Registry Repository on GitHub with your changes. The maintainers of the repository will review your pull request and check that everything integrates properly.
</li>
</ol>

		</section>
		<section id="registry-table-of-standardized-permissions">
<h2 title="Registry table of standardized permissions">C.3. 標準~化された許可たちが成す~registry表t</h2>

<p>
ある許可が`標準~化された許可たちが成す表t$内に現れる
— したがって、
`標準~化された許可@
であると見なされる —
ためには、
次に挙げる判定基準を満たす必要がある：
◎
For a permission to appear in the table of standardized permissions, and thus be considered a standardized permission, it needs to meet the following criteria:
</p>
<ul>
	<li>
2 つ以上の~browser~engineにおいて、
実装され，相互運用可能なことをデモれる
（例：
`~web~platform~test群＠https://web-platform-tests.org$が付随している）。
◎
Implemented and demonstrably interoperable in at least two browser engines (e.g., has accompanying Web Platform Tests).
</li>
	<li>
<p>
次のいずれかにおいて指定されている：
</p>
		<ul>
			<li>
ある`~W3C~WG＠~W3C-Process#GroupsWG$により公表された`技術-報告＠~W3C-Process#technical-report$のうち，
`最初の公な作業草案＠~W3C-Process#fpwd$以上に成熟したもの
</li>
			<li>
`WHATWG＠https://whatwg.org$
により公表された標準
</li>
		</ul>
◎
Is specified in published as technical report by a W3C Working Group with maturity of first public working draft or above, or is published by the WHATWG as a standard.
</li>
</ul>

<p>
各`許可$は、
一意な~literal文字列により識別される。
この文字列は
⇒＃
`許可~施策$cite 仕様においては，`施策により制御される特能$を識別する。
`許可$cite 仕様においては，`強力な特能$を識別する。
◎
Each permission is identified by a unique literal string. In the case of Permissions Policy, the string identifies a policy-controlled features. Similarly, in the Permissions specification the string identifies a powerful feature.
</p>

<div class="note">
<p>注記：
`許可^citeと`許可~施策^cite
◎
Note: Permissions and Permissions Policy
</p>

<p>
`施策により制御される特能$には、
`強力な特能$でないものもある。
例えば `web-share^l は、
`施策により制御される特能$であるが，`強力な特能$には分類されない
— `許可を表出する$ことを利用するよう要求しないので。
しかしながら，ごく少数の例外を除けば、
ほとんどの`強力な特能$は，`施策により制御される特能$でもある。
例えば `geolocation^l は、
`施策により制御される特能$であって，`強力な特能$でもある
— `許可を表出する$ことを利用するよう要求するので。
`強力な特能を指定する$方法に対する指導は、
`許可$cite 仕様を参照rされたし。
◎
Not every policy-controlled feature is powerful features. For example, "web-share" is a policy-controlled feature that is not classified as a powerful feature because it doesn't require express permission to be used. However, with very few exceptions, most powerful features are also policy-controlled features. For example, "geolocation" is both a policy-controlled feature and a powerful feature, as it requires express permission to be used. Please refer to the Permissions specification for guidance on how to specify a powerful feature.
</p>
</div>

<div>
<table class="_registry-table grid-table">
<caption>
`標準~化された許可たちが成す表t@
</caption>
<thead>
<tr><th>識別用の文字列
<th>`施策により制御される特能$か？
<th>`強力な特能$か？
<th>仕様
<th>実装（
`Chromium＠https://www.chromium.org/Home/$／
`Gecko＠https://developer.mozilla.org/en-US/docs/Glossary/Gecko$／
`WebKit＠https://webkit.org/$
）
<tbody>

<tr><td>`geolocation＠~GEOLOCATION#dfn-geolocation$l
<td>はい
<td>はい
<td>
`Geolocation$cite
<td>はい／はい／はい

<tr><td>`notifications＠~NOTIFICATIONS#permissiondef-notifications$l
<td>いいえ
<td>はい
<td>
`Notifications API Standard＠~NOTIFICATIONS$cite
<td>はい／はい／はい

<tr><td>`push＠~TR/push-api/#dfn-push$l
<td>いいえ
<td>はい
<td>
`Push API$cite
<td>はい／はい／はい

<tr><td>`web-share＠~WEBSHARE#dfn-web-share$l
<td>はい
<td>いいえ
<td>
`Web Share API＠~WEBSHARE$cite
<td>はい／はい／はい
</table>

◎
Table of standardized permissions of the web platform
◎
Identifying string｜Is policy-controlled feature?｜Is powerful feature?｜Specification｜Implementations
◎
｜｜｜｜Chromium｜Gecko｜WebKit
"geolocation"｜YES｜YES｜Geolocation｜YES｜YES｜YES
"notifications"｜NO｜YES｜Notifications API Standard｜YES｜YES｜YES
"push"｜NO｜YES｜Push API｜YES｜YES｜YES
"web-share"｜YES｜NO｜Web Share API｜YES｜YES｜YES
</div>

		</section>
		<section id="registry-table-of-provisional-permissions">
<h2 title="Registry table of provisional permissions">C.4. 暫定的な許可たちが成す~registry表t</h2>

<p>
暫定的な許可は、
まだ`標準~化された許可$でない
— すなわち，次に挙げるいずれかに該当する許可である
⇒＃
試験的である／
まだ揺籃期にある／
実装した~browser~engineは 1 つしかない
◎
Provisional permissions are permissions that are not yet standardized (i.e., they are either experimental, still in the incubation phase, or are only implemented in a single browser engine).
</p>

<div>
<table class="_registry-table grid-table">
<caption>
`暫定的な許可たちが成す表t@
</caption>
<thead>
<tr><th>識別用の文字列
<th>`施策により制御される特能$か？
<th>`強力な特能$か？
<th>仕様
<th>実装（
`Chromium＠https://www.chromium.org/Home/$／
`Gecko＠https://developer.mozilla.org/en-US/docs/Glossary/Gecko$／
`WebKit＠https://webkit.org/$
）
<tbody>

<tr><td>`accelerometer＠~DEVICEORIENTATION#permissiondef-accelerometer$l
<td>はい
<td>はい
<td>`Device Orientation and Motion＠~DEVICEORIENTATION$cite
<td>はい／いいえ／いいえ

<tr><td>`window-management＠~TR/window-management/#permissiondef-window-management$l
<td>はい
<td>はい
<td>`Window Management＠~TR/window-management/$cite
<td>はい／いいえ／いいえ

<tr><td>`local-fonts＠https://wicg.github.io/local-font-access/#permissiondef-local-fonts$l
<td>はい
<td>はい
<td>`Local Font Access＠https://wicg.github.io/local-font-access/$cite
<td>はい／いいえ／いいえ
</table>
◎
Table of provisional permissions
◎
Identifying string｜Is policy-controlled feature?｜Is powerful feature?｜Specification｜Implementations
｜｜｜｜Chromium｜Gecko｜WebKit
"accelerometer"｜YES｜YES｜Accelerometer｜YES｜NO｜NO
"window-management"｜YES｜YES｜Window Management｜YES｜NO｜NO
"local-fonts"｜YES｜YES｜Local Font Access｜YES｜NO｜NO
</div>

		</section>
	</section>
	<section id="privacy-considerations">
<h2 title="Privacy considerations">D. ~privacyの考慮点</h2>

<p>
ある敵対者は、
末端利用者に対応する “指紋” を作成するための要素として，
`許可~状態$も利用できる。
敵対者は，実際に~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.
</p>

<p>
~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.
</p>

	</section>
	<section id="security-considerations">
<h2 title="Security considerations">E. ~securityの考慮点</h2>

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

	</section>
	<section id="acknowledgments">
<h2 title="Acknowledgments">謝辞</h2>

◎非規範的

<div>
<p>
~API設計と編集上の作業に助力された，次の方々に：
</p>
<div lang="en">
Adrienne Porter Felt, Anne van Kesteren, Domenic Denicola, Jake Archibald and Wendy Seltzer
</div>
◎
The editors would like to thank Adrienne Porter Felt, Anne van Kesteren, Domenic Denicola, Jake Archibald and Wendy Seltzer for their help with the API design and editorial work.
</div>

	</section>
</main></div>