セキュリティとプライバシーに関する自己考査 質問票 — Self-Review Questionnaire: Security and Privacy

1.1. この質問票を利用する方法

設計-過程において何かを容易に変更できる早期に，これらの質問を通して作業すること。 ある特能が出荷された後で［ ~security／~privacy ］の課題が見出された場合、 その設計を変更するのは，ずっと難しくなることに加え、 ~UAは，その課題を修正するために非互換化する変更を採用する必要が生じ得る。 ◎ Work through these questions early on in the design process, when things are easier to change. When privacy and security issues are only found later, after a feature has shipped, it’s much harder to change the design. If security or privacy issues are found late, user agents may need to adopt breaking changes to fix the issues.

仕様に対し作業している間は、 これらの質問を念頭に置くこと。 この質問票を周期的に — 特に，その設計が時を経て変更されるに伴い — 再訪して，これらの質問を考慮し続けること。 ◎ Keep these questions in mind while working on specifications. Periodically revisit this questionnaire and continue to consider the questions, particularly as a design changes over time.

1.2. 追加的な文献

この文書と並行して，［ ~PING（ `Privacy Interest Group^en ）により公表された次の文書 ］も考慮するベキである — それは、~browser指紋収集について，更に掘り下げる ⇒ `Mitigating Browser Fingerprinting in Web Specifications^cite （~Web仕様における~browser指紋収集の軽減-法） `FINGERPRINTING-GUIDANCE$r ◎ The Mitigating Browser Fingerprinting in Web Specifications [FINGERPRINTING-GUIDANCE] document published by PING goes into further depth about browser fingerprinting and should be considered in parallel with this document.

~IETFによる，~privacyの考慮点についての~RFC `RFC6973$r — 特に `§ 7＠~RFCx/rfc6973#section-7$ — は、見事な文献である ◎ The IETF’s RFC about privacy considerations, [RFC6973], is a wonderful resource, particularly section 7.

1.3. ~TAG, ~PING, ~security考査と，この質問票

［ ~securityについて ~security考査者／ ~privacyについて `~PING＠https://www.w3.org/Privacy/IG/$（ `Privacy Interest Group^en ） ］に考査を要請する前に，当の文書に［ “§ ~securityの考慮点”, “§ ~privacyの考慮点” ］を書くこと — `§ 当の仕様には、 “§ ~securityの考慮点”, “§ ~privacyの考慮点” どちらもあるか？＠#considerations$ を見よ。 この文書~内の質問に回答することは、 これらの節を書いたことを伝えると希望される。 しかしながら，この質問票を これらの節の中に複製するだけ【各~質問に［はい／いいえ］で回答するだけ】で済ますのは適切でない。 ［ ~security, ~privacy ］の考査を要請するための指示書きは、 `広くから考査を行う方法＠https://w3c.github.io/documentreview/#how_to_get_horizontal_review$cite にて見出せる。 ◎ Before requesting privacy and security reviews from the Privacy Interest Group (PING) and security reviewers, write "Security Considerations" and "Privacy Considerations" sections in your document, as described in § 2.16 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?. Answering the questions in this document will, we hope, inform your writing of those sections. It is not appropriate, however, to merely copy this questionnaire into those sections. Instructions for requesting security and privacy reviews can be found in the document How to do Wide Review.

策定者が `~TAG＠https://www.w3.org/2001/tag/$ （ `Technical Architecture Group^en ）に `考査＠https://github.com/w3ctag/design-reviews$を要請するとき、 ~TAGは，この文書~内の質問に回答を供するよう策定者に依頼する。 ◎ When authors request a review from the Technical Architecture Group (TAG), the TAG asks that authors provide answers to the questions in this document.

~TAGによる考査を要請するときは、 この文書~内の各~質問に対する回答を~TAGに供されたし。 それを行うには、 `Markdownによる，この~template＠https://raw.githubusercontent.com/w3ctag/security-questionnaire/main/questionnaire.markdown$ が有用になろう。 ◎ When requesting a review from the Technical Architecture Group (TAG), please provide the TAG with answers to the questions in this document. This Markdown template may be useful when doing so.

2.1. 当の特能は、情報として何を何の目的で公開するのか？

~UAが情報を~webに公開するのは、 利用者の明瞭な必要性を~serveするために必要yなときに限るベキである ⇒＃ 当の特能は、~web~siteに情報を公開するのか？ 公開する場合、それは，利用者にどんな便益があるのか？ その便益は、利用者にとっての~riskに勝るのか？どう勝るのか？ ◎ User agents should only expose information to the Web when doing so is necessary to serve a clear user need. Does your feature expose information to websites? If so, how does exposing this information benefit the user? Are the risks to the user outweighed by the benefits to the user? If so, how?

次も見よ ⇒ `~Web~platform設計~原則^cite `§ 利用者の必要性を第一に置くこと＠~DESIGN-PRINCIPLES#priority-of-constituencies$ ◎ See also • Web Platform Design Principles § priority-of-constituencies

この質問に回答するときは、 以下に挙げる，［ 情報の［ 開示／共有 ］に関する 4 種の下位-質問 ］それぞれについて考慮されたし。 ◎ When answering this question, please consider each of these four possible areas of information disclosure / sharing.

これら下位-質問における用語 `識別するものになり得る情報^emは、 ~~個々の~browser利用者について述べる情報を意味するととられたし。 `識別するものになり得る情報^emの例として、 当の~browser利用者の［ 環境（例：~OS環境設定, ~browser環境設定, ~hardware能力）, それまでの活動や関心（例： 閲覧~履歴, 購入-時の選好, 個人の特性） ］についての情報が挙げられる。 ◎ For the below sub-questions, please take the term potentially identifying information to mean information that describes the browser user, distinct from others who use the same browser version. Examples of such potentially identifying information include information about the browser user’s environment (e.g., operating system configuration, browser configuration, hardware capabilities), and the user’s prior activities and interests (e.g., browsing history, purchasing preferences, personal characteristics).

1. ［ 当の仕様が`当事者-主体^strongに公開する情報 ］のうち［ `当事者-主体^strongが現時点では容易に決定し得ないもの ］は何か。 ◎ What information does your spec expose to the first party that the first party cannot currently easily determine.
2. ［ 当の仕様が`第三者-主体^strongに公開する情報 ］のうち［ `第三者-主体^strongが現時点では容易に決定し得ないもの ］は何か。 ◎ What information does your spec expose to third parties that third parties cannot currently easily determine.
3. ［ 当の仕様が`当事者-主体^strongに公開する`識別するものになり得る情報^em ］のうち［ `当事者-主体^strongがすでに~accessし得るもの （すなわち，当の仕様が重複するか~~反映するもの） ］は何か。 ◎ What potentially identifying information does your spec expose to the first party that the first party can already access (i.e., what identifying information does your spec duplicate or mirror).
4. ［ 当の仕様が`第三者-主体^strongに公開する`識別するものになり得る情報^em ］のうち［ `第三者-主体^strongがすでに~accessし得るもの ］は何か。 ◎ What potentially identifying information does your spec expose to third parties that third parties can already access.

2.2. 当の特能が公開する情報は、意図される機能性を実装するために必要yな最小な量か？

特能が情報を公開するのは、 絶対的に必要yなときに限るベキである ⇒＃ 当の特能が，必要yなものを超える情報を公開する場合、なぜ，そうするのか？ 同じ機能性は、より少ない情報を公開することで達成できないか？ ◎ Features should only expose information when it’s absolutely necessary. If a feature exposes more information than is necessary, why does it do so, and can that the same functionality be achieved by exposing less information?

次も見よ ⇒ `§ ~dataの最小~化＠#data-minimization$ ◎ See also • § 4.1 Data Minimization

2.3. 当の特能は、個人-情報や個人識別可能な情報（~PII）, これらいずれかから導出される情報を公開するか？

個人-情報（ `personal informatin^en ）とは、［ 利用者についての~data（例：住所）／ 利用者を識別するためにも利用し得る情報（例：別名, ~email~address, 識別~番号） ］である。 ◎ Personal information is any data about a user (for example, their home address), or information that could be used to identify a user, such as an alias, email address, or identification number.

注記： 個人-情報は、 個人識別可能な情報（ `personally identifiable information^en ） — 略称 ~PII — とは別物である。 ~PIIは，法的な概念であり、その定義は，【司法の】管轄ごとに変わる。 ~PIIが法的でない文脈において利用されたときは、 一般に，利用者を識別するためにも利用し得る情報を指す傾向にある。 ◎ Note: Personal information is distinct from personally identifiable information (PII). PII is a legal concept, the definition of which varies from jurisdiction to jurisdiction. When used in a non-legal context, PII tends to refer generally to information that could be used to identify a user.

仕様~策定者は，［ 個人-情報や~PII／それらから導出される情報 ］を公開するときは、 利用者に及び得る害を防止するか，それがアリでないときは害を最小~化しなければナラナイ。 ◎ When exposing personal information, PII, or derivative information, specification authors must prevent or, when prevention is not possible, minimize potential harm to users.

［ 個人-情報や~PII／それらから導出される情報 ］は、 `有意義な利用者の同意＠~DESIGN-PRINCIPLES#consent$ を経ることなく，生成元に公開されるベキでない。 多くの~APIは、 有意義な利用者の同意を獲得するために， `Permissions API^cite を利用する。 `PERMISSIONS$r ◎ Personal information, PII, or their derivatives should not be exposed to origins without meaningful user consent. Many APIs use the Permissions API to acquire meaningful user consent. [PERMISSIONS]

~web~platformに許可~promptが追加されるたびに、［ 利用者が，すべての許可~promptに対し その内容を無視したくなる~risk ］は高まることを念頭に置くこと。 許可~promptを追加する前に、［ もっと目障りにならない仕方を利用して，有意義な利用者の同意を得る ］ような選択肢を考慮すること。 `ADDING-PERMISSION$r ◎ Keep in mind that each permission prompt added to the web platform increases the risk that users will ignore the contents of all permission prompts. Before adding a permission prompt, consider your options for using a less obtrusive way to gain meaningful user consent. [ADDING-PERMISSION]

次も見よ ⇒＃ `§ 利用者による明示的な仲介＠#user-mediation$／ `~Web~platform設計~原則^cite `§ 同意＠~DESIGN-PRINCIPLES#consent$ ◎ See also • § 4.3 Explicit user mediation • Web Platform Design Principles § consent

2.4. 当の特能は、敏感な情報をどう処するか？

敏感な情報は、 個人-情報のみに限られない。 他の多くの種類の情報も敏感になり得る。 何が敏感な情報になるかは、 個人ごと, 場所ごとに変わり得る。 ある［ 個人または何人かの~group ］について知られても無害な情報であっても、 別の［ 個人または何人かの~group ］について知られた場合，危険にもなり得る。 ある個人についての情報は、 ある国では無害であっても，別の国では その者を［ 勾留-／誘拐-／投獄- ］するために利用されるかもしれない。 ◎ Personal information is not the only kind of sensitive information. Many other kinds of information may also be sensitive. What is or isn’t sensitive information can vary from person to person or from place to place. Information that would be harmless if known about one person or group of people could be dangerous if known about another person or group. Information about a person that would be harmless in one country might be used in another country to detain, kidnap, or imprison them.

敏感な情報の例には、 次が挙げられる ⇒＃ ~Ex-sensitive-info ◎ Examples of sensitive information include: caste, citizenship, color, credentials, criminal record, demographic information, disability status, employment status, ethnicity, financial information, health information, location data, marital status, political beliefs, profession, race, religious beliefs or nonbeliefs, sexual preferences, and trans status.

ある特能が敏感な情報を~webに公開するとき、 その設計者は，その情報が公開する~riskを軽減する手続きを踏まなければナラナイ。 ◎ When a feature exposes sensitive information to the web, its designers must take steps to mitigate the risk of exposing the information.

所在~情報を要求するような利用事例の多くは、 ごく粗い所在~dataで必要十分に~serveできる。 一例として，料理店を推奨する~siteは、 利用者の精確な所在を公開する代わりに， 市区~levelの所在~情報で利用者たちに必要十分に~serveすることもできる。 ◎ Many use cases which require location information can be adequately served with very coarse location data. For instance, a site which recommends restaurants could adequately serve its users with city-level location information instead of exposing the user’s precise location.

次も見よ ⇒ `~Web~platform設計~原則^cite `§ 支援技術が利用-中かどうかを露呈しないこと＠~DESIGN-PRINCIPLES#do-not-expose-use-of-assistive-tech$ ◎ See also • Web Platform Design Principles § do-not-expose-use-of-assistive-tech

2.5. 当の仕様により公開される~dataは、関係する情報として，利用者にとって明白とは言えない別個な情報も運ぶか？

［ 利用者が~dataを生成元と共有する ］ことを可能化する特能は、 利用者の［ 自覚, 理解, 同意 ］を伴わない限り，そのような~dataが［ それに埋込まれた — 場合によっては，隠れた — 情報 ］を運ばないことを確保するベキである。 ◎ Features which enable users to share data with origins should ensure that such data does not carry embedded, possibly hidden, information without the user’s awareness, understanding, and consent.

［ 画像, 動画, 音声 ］などの文書は、［ それが いつどこで撮られたか ］および［ 当の~dataを［ 撮った／生産した ］機器の種類 ］についての~metadataを包含することが多い。 この種類の~metadataは、 ~uploadされたとき， 利用者が露呈するよう意図しない情報 — 利用者の［ ~~現在あるいは~~過去 ］の［ 所在, 社会経済的~地位 ］など — を生成元へ露呈し得る。 ◎ Documents such as image or video files often contain metadata about where and when the image, video, or audio was captured and what kind of device captured or produced the data. When uploaded, this kind of metadata may reveal to origins information the user did not intend to reveal, such as the user’s present or past location and socioeconomic status.

~UAは、［ そのような~dataを~siteと共有するか否か，利用者が選ぶ ］ことを可能化するベキであり、 既定では，そのような~dataは共有されないベキである。 ◎ User agents should enable users to choose whether or not to share such data with sites, and the default should be that such data is not shared.

2.6. 当の特能は、複数の閲覧~sessionにわたって持続する状態を導入するか？

~Web~platformには、 情報を格納するために生成元が利用できる仕組みが，すでにいくつもある。 次に挙げるものは、 それらのうち一握りでしかない ⇒＃ ~HTTP［ `Cookie$h ／ `ETag$h ／ `Last-Modified$h ］~header, `localStorage$c, `indexedDB$c ◎ The Web platform already includes many mechanisms origins can use to store information. Cookies, ETag, Last Modified, localStorage, and indexedDB, are just a few examples.

［ 複数の閲覧~sessionにわたって持続する仕方で，利用者の機器に~dataを格納する ］ことを~web~siteに許容することは、 この状態が — `当事者-主体＠https://privacycg.github.io/storage-access/#first-party-site-context$, `第三者-主体＠https://privacycg.github.io/storage-access/#third-party-context$ どちらの文脈においても — 利用者の知らない所で, 利用者の制御を経ることなく， 利用者を追跡するために利用され得る~riskを導入し得る。 ◎ Allowing a website to store data on a user’s device in a way that persists across browsing sessions introduces the risk that this state may be used to track a user without their knowledge or control, either in first- or third-party contexts.

生成元が~client側~storageの仕組みを濫用するのを，~UAが防止する仕方の一つは、［ 生成元により格納された~dataを~clearする能 ］を利用者に供することである。 仕様~策定者は、 類似な保護を含めることで，新たな~client側~storageの仕組みは［ 利用者により制御されることなく，利用者を複数~domainにわたって追跡する ］ために誤利用され得ないようにするベキである。 しかしながら、［ 生成元により設定された状態を削除する能 ］を利用者に与えるだけでは，通例的には足らない — 利用者は、 稀にしか，~browser状態を手動で~clearしないので。 仕様~策定者は、 新たな特能に対し — ~storageを全部的に~clearすることを経ずに — ~privacyをもっと保全する仕方を考慮するベキである — 例：［ 値の一意~性を抑制する ／ 値を交替する ／ ］その他，当の特能が必要以上に利用者を識別するものにならないようにするなど。 ◎ One way user agents prevent origins from abusing client-side storage mechanisms is by providing users with the ability to clear data stored by origins. Specification authors should include similar protections to make sure that new client-side storage mechanisms cannot be misused to track users across domains without their control. However, just giving users the ability to delete origin-set state is usually not sufficient since users rarely manually clear browser state. Spec authors should consider ways to make new features more privacy-preserving without full storage clearing, such as reducing the uniqueness of values, rotating values, or otherwise making features no more identifying than is needed.

加えて，仕様~策定者は、 アリなときは，［ 当の特能が~browserの~cache法~特能とどうヤリトリするベキか ］について注意深く考慮して指定するベキである。 生成元が~cacheを濫用して［ 利用者~同意を経ることなく，複数［ ~site／~session ］にわたって利用者を識別して追跡する ］ことを防止するためには、 追加的な軽減策も必要yあり得る。 ◎ Additionally, specification authors should carefully consider and specify, when possible, how their features should interact with browser caching features. Additional mitigations may be necessary to prevent origins from abusing caches to identify and track users across sites or sessions without user consent.

2.7. 当の特能は、下層の~platformについての情報を生成元に公開するか？

下層の~platform情報は、次を含む ⇒＃ 利用者の環境設定~data／ ~sensorなどの~hardware入出力~機器の有無, それらの属性／ 様々な~software特能の可用性, その挙動 ◎ (Underlying platform information includes user configuration data, the presence and attributes of hardware I/O devices such as sensors, and the availability and behavior of various software features.)

そのような情報を生成元に公開する場合 ⇒＃ どの生成元にも同じ~dataが公開されるのか？生成元に応じて異なるのか？ その~dataが変化するのは、 頻繁なのか稀なのか？ ◎ If so, is the same information exposed across origins? Do different origins see different data or the same data? Does the data change frequently or rarely?＼

稀にしか変化しない~dataが複数の生成元に公開されると、 それらの生成元にわたって利用者を一意に識別するために利用され得る。 これは、 直接的にも（その情報~片だけで一意になるとき）， 間接的にも（当の~dataは，他の~dataと組合されて指紋を形成する）なり得る。 `FINGERPRINTING-GUIDANCE$r ◎ Rarely-changing data exposed to multiple origins can be used to uniquely identify a user across those origins. This may be direct (when the piece of information is unique) or indirect (because the data may be combined with other data to form a fingerprint). [FINGERPRINTING-GUIDANCE]

［ 当の仕様／~UA ］は、［ そのような情報を公開するかどうか考慮するとき， それを他の情報と隔離して考慮する ］ベキではなく、［ それを~platformの既存の指紋収集~表口に追加すること ］による~riskを評価するベキである。 ◎ When considering whether or not to expose such information, specs and user agents should not consider the information in isolation, but should evaluate the risk of adding it to the existing fingerprinting surface of the platform.

特定0の情報~片が指紋収集される~riskは、 ~platformに応じて変わり得ることを念頭に置くこと。 `you^en 【ある利用者？策定者？】が利用する［ ~hardware／~software ］~platformで何らかの~dataが指紋収集される~riskは、 他の~platformで指紋収集される~riskとは異なることもある。 ◎ Keep in mind that the fingerprinting risk of a particular piece of information may vary between platforms. The fingerprinting risk of some data on the hardware and software platforms you use may be different than the fingerprinting risk on other platforms.

策定者は、 そのような情報を公開するものと裁定するときは， それによる害を軽減する手続きを踏むベキである。 ◎ When you do decide to expose such information, you should take steps to mitigate the harm of such exposure.

ときには，~dataを初めから公開しないことが正解になることもある （`§ 当の特能を落とす＠#drop-feature$を見よ）。 他にも、 指紋収集-能を抑制することは， 【各 実装~間の】一貫性を確保するのと~~同程度に単純な事例 — 一例として，可用な資源の~list内での順序付け【`有順序~集合$など】 — もあるが、 ときには，もっと複階的な軽減策が必要yあり得る。 `§ 軽減策＠#mitigations$を見よ。 ◎ Sometimes the right answer is to not expose the data in the first place (see § 4.6 Drop the feature). In other cases, reducing fingerprintability may be as simple as ensuring consistency—for instance, by ordering a list of available resources—but sometimes, more complex mitigations may be necessary. See § 4 Mitigation Strategies for more.

当の特能がそのような~dataを公開しつつ，必要十分な軽減策を定義しない場合、 その策定者は，［ そのような情報は、 `有意義な利用者の同意＠~DESIGN-PRINCIPLES#consent$を経ない限り， 生成元には露呈されない ］ことを確保するベキであり、 当の仕様の “§ ~securityと~privacyの考慮点” にて，そのことを明瞭に述べるベキである。 ◎ If features in your spec expose such data and does not define adequate mitigations, you should ensure that such information is not revealed to origins without meaningful user consent, and you should clearly describe this in your specification’s Security and Privacy Considerations sections.

次も見よ ⇒＃ `機器を識別する情報を公開するときの注意点＠~DESIGN-PRINCIPLES#device-ids$／ `機器を選定する／列挙するための~APIを公開するときの注意点＠~DESIGN-PRINCIPLES#device-enumeration$ ◎ See also: • Use care when exposing identifying information about devices • Use care when exposing APIs for selecting or enumerating devices

2.8. 当の仕様は、下層の~platformへ~dataを送信するのを生成元に許容するか？

そうならば、 どんな種類の~dataが送信され得るのか？ ◎ If so, what kind of data can be sent?

渡された~dataをどう処理するかは、 各~platform間で相違するので，利用者にとっての~riskも異なり得る。 ◎ Platforms differ in how they process data passed into them, which may present different risks to users.

下層の~platformが渡された~dataを安全に取扱うものと，見做さないこと。 アリな所では、 当の~platformに渡される~data［ の種類を制限する／を構造-化する ］ことにより，攻撃を軽減すること。 ◎ Don’t assume the underlying platform will safely handle the data that is passed. Where possible, mitigate attacks by limiting or structuring the kind of data is passed to the platform.

2.9. 当の特能は、機器~sensorに対する~accessを可能化するか？

そうする場合、 どの~sensorから, どの種類の情報が生成元に公開されるのか？ ◎ If so, what kinds of information from or about the sensors are exposed to origins?

~sensorからの情報は、 各 生成元にわたる指紋収集~行路として~serveし得る。 加えて，~sensorは、 機器や環境について敏感な何かを露呈し得る。 ◎ Information from sensors may serve as a fingerprinting vector across origins. Additionally, sensors may reveal something sensitive about the device or its environment.

~sensor~dataは、 比較的-［ 安定的, かつ各 生成元にまたがって一貫する ］ので，複数の生成元にまたがる識別子にも利用され得る。 事実， 2 つの~UAが同じ~sensorから そのような安定的な~dataを公開する場合、 その~dataは，複数の~browserにまたがる — さらには，複数の機器にもまたがる — 識別子にすら利用され得る。 ◎ If sensor data is relatively stable and consistent across origins, it could be used as a cross-origin identifier. If two User Agents expose such stable data from the same sensors, the data could even be used as a cross-browser, or potentially even a cross-device, identifier.

2.10. 当の特能は、~scriptを実行したり読込む新たな仕組みを可能化するか？

~scriptを［ 実行する／読込む ］ための新たな仕組みには、 斬新な攻撃~表口を可能化する~riskがある。 一般に，新たな特能にて これが必要になる場合、 広くからの~~意見に諮って，［ 既存の仕組みを利用できるかどうか／当の特能は本当に必要yであるかどうか ］について考するベキである。 ◎ New mechanisms for executing or loading scripts have a risk of enabling novel attack surfaces. Generally, if a new feature needs this you should consult with a wider audience, and think about whether or not an existing mechanism can be used or the feature is really necessary.

2.11. 当の特能は、他の機器への~accessを生成元に許容するか？

許容する場合、 当の特能は，どの機器に~accessするのを生成元に許容するか？ ◎ If so, what devices do the features in this specification allow an origin to access?

他の機器へ~accessすることは、［ ~networkへの接続，利用者の~machineへの直な接続（例： ~Bluetooth／ ~NFC【 `Near Field Communication^en, 近距離無線通信規格】／ ~USB） ］どちらを介するものも，脆弱性を公開し得る — これらの機器の一部は、［ ~webへの接続性／~web上での利用 ］を念頭に作成されていないものもあり、 悪意的な入力に抗して必要十分に~~堅固でない。 ◎ Accessing other devices, both via network connections and via direct connection to the user’s machine (e.g. via Bluetooth, NFC, or USB), could expose vulnerabilities - some of these devices were not created with web connectivity in mind and may be inadequately hardened against malicious input, or with the use on the web.

利用者の局所~network上に他の機器を公開することには、 有意な~privacy~riskもある： ◎ Exposing other devices on a user’s local network also has significant privacy risk:

• 2 つの~UAの各自の局所~network上に同じ機器が在る場合、 攻撃者は，その 2 つの~UAは［ 同じ~host上で稼働している／ 同じ物理的~所在に居る 2 人の利用者が利用している ］ことを推定し得る。 ◎ If two user agents have the same devices on their local network, an attacker may infer that the two user agents are running on the same host or are being used by two separate users who are in the same physical location.
• 利用者の局所~network上に在る機器を列挙すると、［ 攻撃者が，~UAを指紋収集するために利用し得る ］ような有意な~entropyを供することになる。 ◎ Enumerating the devices on a user’s local network provides significant entropy that an attacker may use to fingerprint the user agent.
• 当の特能が［ 持続的／長寿命 ］な［ 局所~network機器の識別子 ］を公開する場合、 それは，利用者を時間~越しに追跡する仕方を攻撃者に供する — 利用者がそのような追跡を防止する手続きを踏んだとしても （例：~cookie, その他の~statefulな追跡の仕組みを~clearしても）。 ◎ If features in this spec expose persistent or long lived identifiers of local network devices, that provides attackers with a way to track a user over time even if a user takes steps to prevent such tracking (e.g. clearing cookies and other stateful tracking mechanisms).
• 直な接続は、 他の~APIが供する~security検査を迂回するためにも利用され得る。 例えば，攻撃者は、 `WebUSB API^cite を利用して， 早期 `U2F API^cite における同一-生成元~検査を迂回して、 ~hardware~security上の他~siteの資格証に~accessした。 `YUBIKEY-ATTACK$r ◎ Direct connections might be also be used to bypass security checks that other APIs would provide. For example, attackers used the WebUSB API to access others sites' credentials on a hardware security, bypassing same-origin checks in an early U2F API. [YUBIKEY-ATTACK]

2.12. 当の特能は、~UAの~native~UIに対する何らかの制御を生成元に許容するか？

［ ~UAの~UIに対する制御（例：全screen~mode）／ 下層の~systemに対する変更（例： ~smartphoneの~home~screen上で “~app” を~installする） ］を許容するような特能は、 利用者を驚かす, あるいは［ ~security／~privacy ］用の制御を遮ることもある。 当の特能が~UAの~UIを変更できる範囲内で、 それは［ ~security／~privacy ］制御に効果を及ぼし得るか？ その結論は、 何の分析により確認されたか？ ◎ Features that allow for control over a user agent’s UI (e.g. full screen mode) or changes to the underlying system (e.g. installing an ‘app’ on a smartphone home screen) may surprise users or obscure security / privacy controls. To the extent that your feature does allow for the changing of a user agent’s UI, can it effect security / privacy controls? What analysis confirmed this conclusion?

2.13. 当の特能は、一時的な識別子として何を作成するか？／何を~webに公開するか？

~webに一時的な識別子を公開する標準は、［ この識別子を利用して，利用者が時間~越しに追跡される~risk ］を軽減するため，識別子は短寿命, かつ定期的に交替させるベキである。 利用者が，~UA内の状態を~clearしたときは、 一時的な識別子も — それを利用して，状態が相関し直されるのを防止するため — ~clearされるベキである。 ◎ If a standard exposes a temporary identifier to the web, the identifier should be short lived and should rotate on some regular duration to mitigate the risk of this identifier being used to track a user over time. When a user clears state in their user agent, these temporary identifiers should be cleared to prevent re-correlation of state using a temporary identifier.

当の特能が，~web向けに一時的な識別子を［ 作成する／公開する ］場合、 いつ, どの実体へ, どう公開され，どの頻度で交替されるか？ ◎ If features in this spec create or expose temporary identifiers to the web, how are they exposed, when, to what entities, and, how frequently are those temporary identifiers rotated?

一時的な識別子の例として、 次が挙げられる ⇒＃ `TLS Channel ID^en, `Session Ticket^en, ~IPv6~address ◎ Example temporary identifiers include TLS Channel ID, Session Tickets, and IPv6 addresses.

2.14. 当の仕様は、当事者-主体, 第三者-主体の文脈~間における挙動をどう判別するか？

当の特能の挙動は、［ 利用者が訪問している当事者-主体の生成元のみならず，それが内包する任意な第三者-主体 ］の文脈で利用されることによる含意も考慮されるベキである。 仕様を開発するときには、 ~page上の第三者-主体~資源による利用に対し，［ それによる含意 ］, および［ その~supportは、 当の仕様に適合するためには，任意選択とするベキかどうか ］を考慮すること。 第三者-主体~資源による利用を~supportすることが，適合性において義務である場合、 なぜ, および何が~privacy軽減策として その場にあるか説明されたし。 これは、特に重要になる — 第三者-主体が機能性を濫用していると見出された場合、 ~UAは，第三者-主体に対し 一定の特能の［ 可用性／機能性 ］を抑制する手続きを踏むこともあるので。 ◎ The behavior of a feature should be considered not just in the context of its being used by a first party origin that a user is visiting but also the implications of its being used by an arbitrary third party that the first party includes. When developing your specification, consider the implications of its use by third party resources on a page and, consider if support for use by third party resources should be optional to conform to the specification. If supporting use by third party resources is mandatory for conformance, please explain why and what privacy mitigations are in place. This is particularly important as user agents may take steps to reduce the availability or functionality of certain features to third parties if the third parties are found to be abusing the functionality.

2.15. 当の特能は、~browserの私的~閲覧~modeの文脈においてどう働くか？

ほとんどの~browserは、 私的~閲覧（ `private browsing / incognito^en ）~mode特能を実装するが、 それらが供する機能性, それによる保護を利用者にどう述べるかに関して，有意に変わる。 `WU-PRIVATE-BROWSING$r ◎ Most browsers implement a private browsing or incognito mode, though they vary significantly in what functionality they provide and how that protection is described to users [WU-PRIVATE-BROWSING].

共通点として、 それらが供する状態の集合は，~browserの “通常の” ~modeとは異なることが挙げられる。 ◎ One commonality is that they provide a different set of state than the browser’s 'normal' state.

当の特能は： ◎ ↓

• ［ 通常の~mode, 私的~閲覧~mode ］にわたって，同じ利用者の活動の相関を許容するような情報を供するか？ ◎ Do features in this spec provide information that would allow for the correlation of a single user’s activity across normal and private browsing / incognito modes?＼
• ［ 私的~閲覧~mode~sessionの~~終了に後続して持続する情報 ］を利用者の~hostに書込む結果になるか？ ◎ Do features in the spec result in information being written to a user’s host that would persist following a private browsing / incognito mode session ending?

どちらに対しても事実調査がある： ◎ There has been research into both:

• `RIVERA$r ⇒ `window.requestFileSystem()$c などの，標準~化されてない~methodを利用して、 ~UAは私的~閲覧~modeにあるかどうかを検出する。 ◎ Detecting whether a user agent is in private browsing mode [RIVERA] using non-standardized methods such as window.requestFileSystem().
• `OLEJNIK-PAYMENTS$r ⇒ いくつかの特能を利用して，~browserを指紋収集して、 利用者の［ 私的~閲覧~mode, そうでない~mode ］の~sessionどうしを相関する。 ◎ Using features to fingerprint a browser and correlate private and non-private mode sessions for a given user. [OLEJNIK-PAYMENTS]

仕様~策定者は、［ 私的~閲覧~modeにあるかどうかを~siteが検出-可能になる ］ことをアリな限り避けるベキである。 `DESIGN-PRINCIPLES$r `§ 私的~閲覧~mode下にあることを露呈しないこと＠~DESIGN-PRINCIPLES#do-not-expose-use-of-private-browsing-mode$ を見よ。 ◎ Spec authors should avoid, as much as possible, making the presence of private browsing mode detectable to sites. Web Platform Design Principles § do-not-expose-use-of-private-browsing-mode

2.16. 当の仕様には、 “§ ~securityの考慮点”, “§ ~privacyの考慮点” どちらもあるか？

当の仕様は、［ 実装者を助ける／ ~web開発者が特能に在る~riskを理解する／ 必要十分な軽減策が，その場にあることを確保する ］ため，［ “§ ~securityの考慮点”, “§ ~privacyの考慮点” ］どちらも含めるベキである。 この文書~内の質問に対する策定者の回答は，策定者が これらの節を書いたことは伝えるが、 この質問票を これらの節の中に複製するだけ【各~質問に［はい／いいえ］で回答するだけ】で済ませないこと。 代わりに、［ 実装者／~web開発者 ］に有益になるよう，当の仕様に特有な文言を尽くすこと。 ◎ Specifications should have both "Security Considerations" and "Privacy Considerations" sections to help implementers and web developers understand the risks that a feature presents and to ensure that adequate mitigations are in place. While your answers to the questions in this document will inform your writing of those sections, do not merely copy this questionnaire into those sections. Instead, craft language specific to your specification that will be helpful to implementers and web developers.

`RFC6973$r — 特に，その `§ 7＠~RFCx/rfc6973#section-7$ — は、 当の仕様による~privacy影響iを考慮するときに諮る文献として秀逸である。 `RFC3552$r は、 “§ ~securityの考慮点” を書くときの，一般的な助言を供する — その `§ 5＠~RFCx/rfc3552#section-5$ には特有な要件がある。 【`日本語訳＠https://www.nic.ad.jp/ja/tech/ipa/RFC3552JA.html#05$】 ◎ [RFC6973] is an excellent resource to consult when considering privacy impacts of your specification, particularly Section 7 of RFC6973. [RFC3552] provides general advice as to writing Security Consideration sections, and Section 5 of RFC3552 has specific requirements.

一般に，これらの節は、 当の特能が導入する［ ~security／~privacy ］~riskについて，明瞭な記述を包含するベキである。 また、 当の仕様~内の他所で軽減される~riskがあれば，それを文書化して、［ 当の仕様に則って実装されていないと脆弱性に至る見込みが高いことについて，詳細を~~明記する ］ことも適切になる。 ◎ Generally, these sections should contain clear descriptions of the privacy and security risks for the features your spec introduces. It is also appropriate to document risks that are mitigated elsewhere in the specification and to call out details that, if implemented other-than-according-to-spec, are likely to lead to vulnerabilities.

当の特能には［ ~security／~privacy ］に対する影響iは無いものと見受けられる場合、 そのことを当の仕様~内に記すこと — 例えば、次のように ⇒ この特能による~securityに対する既知な影響iは無い。 ◎ If it seems like none of the features in your specification have security or privacy impacts, say so in-line, e.g.: • There are no known security impacts of the features in this specification.

ほとんどの仕様は、［ ~browserの指紋収集~表口に対し，少なくとも何らかの影響iがある ］ような特能を含むことを自覚すること。 当の仕様は該当しないと予見する場合、 その主張-を正当化することが~~要求される。 ◎ Be aware, though, that most specifications include features that have at least some impact on the fingerprinting surface of the browser. If you believe your specification in an outlier, justifying that claim is in order.

2.17. 当の特能は、既定の~security保護を降格するのを生成元に可能化するか？

当の特能は、生成元が［ 何かを成遂げるために~security設定群を~opt-outする ］ことを可能化するか？ そうならば、 当の特能がそのような降格を許容するのは，どういう状況で，なぜそうするのか？ ◎ Do features in your spec enable an origin to opt-out of security settings in order to accomplish something? If so, in what situations do these features allow such downgrading, and why?

これを初めから避けることはできるか？ できない場合、［ 降格があっても，~riskは劇的に増えない ］ことを~~確保する軽減策として，何がその場にあるか？ 一例として， `PERMISSIONS-POLICY$r は、［ 信用できない `iframe$e が当の特能を利用するのを防止する ］ために，~siteが利用できる仕組みを定義する。 ◎ Can this be avoided in the first place? If not, are mitigations in place to make sure this downgrading doesn’t dramatically increase risk to users? For instance, [PERMISSIONS-POLICY] defines a mechanism that can be used by sites to prevent untrusted iframes from using such a feature.

2.18. 当の特能を利用する文書が［~naviの後に~BF~cache内に生きたまま保たれた］とき，および［文書へ戻る未来の~naviにて再利用されるようになる］とき，何が（破壊される代わりに）起こるか？

利用者が，ある文書から他所へ~navigateした後でも、 当の文書は， “`全部的に作動中$” でない状態に居続けるよう`~BF~cache$内に保たれることもある — そのような文書は、 利用者が文書へ戻るよう~navigateしたとき，再利用されるかもしれない。 `全部的に作動中$でない文書は、 利用者の視点からは，すでに破棄され、 したがって，他所へ~navigateした後に起きた更新や~event — とりわけ~privacyに敏感な情報（例：地理所在 【 `GEOLOCATION$r 】） — を取得するべきでない。 ◎ After a user navigates away from a document, the document might stay around in a non-"fully active" state and kept in the "back/forward cache (BFCache)", and might be reused when the user navigates back to the document. From the user’s perspective, the non-fully active document is already discarded and thus should not get updates/events that happen after they navigated away from it, especially privacy-sensitive information (e.g. geolocation).

文書は，~naviの後に再利用されることもあるので、［ 文書の存続期間に何かを束ねることは、 ~naviの後にも それを再利用することを意味する ］ことを自覚すること。 これが望ましくない場合、 次を考慮すること ⇒ `全部的に作動中$な状態に対する変化を~listenして，必要に応じて片付けを行う。 ◎ Also, as a document might be reused even after navigation, be aware that tying something to a document’s lifetime also means reusing it after navigations. If this is not desirable, consider listening to changes to the fully active state and doing cleanup as necessary.

~BF~cacheされた文書を取扱う方法に対する，より詳細な指導は、 次を見よ ⇒＃ `~Web~platform設計~原則^cite `§ “全部的に作動中” でない文書を~supportすること＠~DESIGN-PRINCIPLES#support-non-fully-active$【！#non-fully-active】／ `~BF~cacheされた文書の~support法＠~BFCACHE$cite 手引き ◎ For more detailed guidance on how to handle BFCached documents, see Web Platform Design Principles § non-fully-active and the Supporting BFCached Documents guide.

注記： 文書は、 ~BF~cache法に関係しない理由で，`全部的に作動中$でなくなることもアリである — 当の文書を保持している `iframe$e が`切断された$ときなど。 【！Our advice is that】 `全部的に作動中$でない文書は、 どれも同じ仕方で扱うべきである。 唯一の相違は、［ ~BF~cacheされた文書は，再び`全部的に作動中$になるかもしれない ］一方で［ 切離された `iframe$e 内の文書は，以降も作動中でない状態に居続ける ］ことである。 したがって、 ~BF~cacheされた事例には，余計に注意を払うことが示唆される。 ◎ Note: It is possible for a document to become non-fully active for other reasons not related to BFcaching, such as when the iframe holding the document becomes disconnected. Our advice is that all non-fully active documents should be treated the same way. The only difference is that BFCached documents might become fully active again, whereas documents in detached iframes will stay inactive forever. Thus, we suggest paying extra attention to the BFCache case.

2.19. 当の特能を利用する文書が切断されたとき，何が起こるか？

ある文書を包含している `iframe$e 要素が`切断された$なら、 当の文書は，もはや`全部的に作動中$でなくなり、 再び全部的に作動中になることは決してない — 当の要素が再び`接続された$ときには、 新たな文書を読込むことになるので。 当の文書は、 利用者の視点からは消え去っており， 当の特能においても そのように扱うベキである。 ［ ~BF~cacheされた文書, 切離された文書 ］は、 同じ仕方で扱うことが期待されるので， 上で言及した`~BF~cache用の指針＠#bfcache$に従うことにしてもヨイ — これらには、［ ~BF~cacheされた文書は、 再び`全部的に作動中$になることもある ］こと以外に相違は無い。 ◎ If the iframe element containing a document becomes disconnected, the document will no longer be fully active. The document will never become fully active again, because if the iframe element becomes connected again, it will load a new document. The document is gone from the user’s perspective, and should be treated as such by your feature as well. You may follow the guidelines for BFCache mentioned above, as we expect BFCached and detached documents to be treated the same way, with the only difference being that BFCached documents can become fully active again.

2.20. 当の仕様は、新たな種類の~errorが［いつ, どう］生じるベキかを定義するか？

［ ~errorの取扱い, 何が~error状態に~~至らす条件を成すか ］は、［ 意図されない情報~漏洩, ~privacy脆弱性 ］の~sourceになり得る。 次に挙げるすべてが，利用者の~privacyに影響し得る【！effect】（または弱め得る） ⇒＃ ~errorを誘発すること／ ~errorに伴われる（あるいは，~errorにより学習-可能になる）情報／ ~appにおいて，どの主体が~errorについて学習し得るか ◎終 利用者の~privacyと~securityが~errorの取扱いを通して害されないことを確保するため、 提案~策定者は，これら各~次元にわたって注意深く考するベキである。 ◎ Error handling, and what conditions constitute error states, can be the source of unintended information leaks and privacy vulnerabilities. Triggering an error, what information is included with (or learnable by) the error, and which parties in an application can learn about the error can all effect (or weaken) user privacy. Proposal authors should carefully think through each of these dimensions to ensure that user privacy and security are not harmed through error handling.

利用者が~riskに~~晒され得る［ ~error定義, ~errorの取扱い ］には、 少なくとも，次が挙げられる： ◎ A partial list of how error definitions and error handling can put users at risk include:

• 当の仕様が定義する~error状態が，ある種の~system資源が可用かどうかに基づく場合、 ~appは，そのような~error状態を［ そのような資源の可用性について探査する ］ために利用し得る。 これは、［ ~appが，そのような資源について学習すること ］を~UAが意図しないときには，利用者の~privacyを害し得る。 ◎ If your spec defines an error state based whether certain system resources are available, applications can use that error state as a probe to learn about the availability of those system resources. This can harm user privacy when user agents do not intend for applications to learn about those system resources.
• 各~仕様は、 ~error~objに［ 作者が~appにおける課題を識別して~debugする ］ことを助けるために意図された情報を含めることが多い。 仕様~策定者は、［ そのような~debug用の情報が公開する情報 ］および［ ~page上の どの動作者が，その情報へ~access可能になるか ］について注意深く考するベキである。 ◎ Specs often include information with error objects that are intended to help authors identify and debug issues in applications. Spec authors should carefully think through what information such debugging information exposes, and whether (and which) actors on a page are able to access that information.

2.21. 当の特能は、利用者による支援技術の利用について学習することを~siteに許容するか?

~Webは，誰にとっても働くよう設計され、 ~Web標準は，支援技術を利用している人々のためにも — ［ ~mouse, ~keyboard, ~touch~screen ］に依拠している利用者と同程度に — 設計されるベキである。 ［ ~accessibility, 普遍的な~access ］は、 ~W3Cの使命の中核である。 ◎ The Web is designed to work for everyone, and Web standards should be designed for people using assistive technology (AT) just as much as for users relying on mice, keyboards, and touch screens. Accessibility and universal access are core to the W3C’s mission.

そうであっても、 仕様~策定者は，［ 支援技術に依拠する~Web利用者は、 ~Webを利用しているとき，ある独特な~riskに直面する ］ことを念頭に置くベキである。 支援技術の利用は、 その利用者を他の~Web利用者から目立たせ得る — その結果、 求まれない［ 再~識別による害, ~privacyに対する害 ］の~riskは高まる。 類似に、 一部の~Web~site運用者は，［ 支援技術に依拠する~Web利用者を差別化する ］よう試行することもある。 ◎ Specification authors though should keep in mind that Web users that rely on assistive technology face some unique risks when using the Web. The use of assistive technologies may cause those Web users to stand out among other Web users, increasing the risk of unwanted reidentification and privacy harm. Similarly, some Web site operators may try to discriminate against Web users who rely on assistive technology.

したがって、［ 当の特能の設計者, 当の仕様の策定者 ］は、［ ~web~siteが支援技術の利用について［ 何か／何 ］を学習し得るか ］について制限するよう，思慮深く気を付けるベキである。 仕様~策定者は、 当の特能を利用する支援技術について［ 明示的, 暗黙的 ］に露呈される情報を，どちらも最小~化しなければナラナイ。 `明示的^emな情報の例として、 機器の識別子や~model名が挙げられる。 `暗黙的^emな情報の例として、［ ~mouse, ~keyboard, ~touch~screen ］でない何かにより生成された見込みが高い［ 利用者-ヤリトリの~pattern ］が挙げられる。 ◎ Feature designers and spec authors should therefore be thoughtful and careful to limit if, and what, websites can learn about the use of assistive technologies. Spec authors must minimize both what information about assistive technology use their features reveal, both explicitly and implicitly. Examples of explicit information about assistive technology include device identifiers or model names. Examples of implicit information about the use of assistive technology might include user interaction patterns that are unlikely to be generated by a mouse, keyboard, or touch screen.

`wai-aria-1.3$r は、 作者が［ 自身の~pageを支援技術で より~navigateし易くする ］ために利用できる追加的な~markup — 特に、 `aria-hidden＠https://w3c.github.io/aria/#aria-hidden$a 属性 — を定義する。 ~site作者は、 この属性を利用して［ ある種の内容は、 支援技術には隠されるベキである ］ことを指示できる。 ◎ The [wai-aria-1.3] defines additional markup authors can use to make their pages easier to navigate with assistive technology. The spec includes the [aria-hidden](https://w3c.github.io/aria/#aria-hidden) attribute, that site authors can use to indicate that certain content should be hidden from assistive technology.

悪意的な~site作者は、［ 利用者が支援技術を利用しているか否か学習する ］ために `aria-hidden^a 属性を濫用するかもしれない — 場合によっては、［ 支援技術に対し，ある種の~page内容を露呈する ］一方で［ 他の利用者には，大きく異なる~page内容を示す ］ことにより。 悪意的な~site作者は、 場合によっては，［ どの内容にヤリトリしたかに関する利用者の挙動 ］から［ 支援技術が利用されているか否か ］を推定することもできる。 ◎ A malicious site author might abuse the aria-hidden attribute to learn if a user is using assistive technology, possibly by revealing certain page content to assistive technology, while showing very different page content to other users. A malicious site author could then possibly infer from the user’s behavior which content the user was interacting with, and so whether assistive technology was being used.

2.21. この質問票には何が尋ねられるベキか？

この質問票は網羅的でない。 ~privacy考査を完了した後でも、 当の仕様の~privacy側面には［ この質問票に対する厳密な読取りと対する答えからは，露呈されないもの ］があるかもしれない。 これに該当する場合、 そのような~privacyの懸念を伝達して，［ 改善されると考せるもの／そのような側面を受持つ新たな質問 ］を指示されたし。 ◎ This questionnaire is not exhaustive. After completing a privacy review, it may be that there are privacy aspects of your specification that a strict reading, and response to, this questionnaire, would not have revealed. If this is the case, please convey those privacy concerns, and indicate if you can think of improved or new questions that would have covered this aspect.

この質問票にて尋ねられるベキものが在れば， `課題を申請して＠https://github.com/w3ctag/security-questionnaire/issues/new$知らしめることを考慮されたし。 ◎ Please consider filing an issue to let us know what the questionnaire should have asked.

3.1. 受動的~network攻撃者

`受動的~network攻撃者@ は、［ 通信している利用者と~serverの間で伝送路を行き交う~bit列 ］に対する読取n~accessを有する。 攻撃者は、 その~bit列を`改変できない^emが，収集して分析できる。 ◎ A passive network attacker has read-access to the bits going over the wire between users and the servers they’re communicating with. She can’t modify the bytes, but she can collect and analyze them.

~internetの分散的な資質に因り，および 利用者~活動への一般的な関心の~levelにおいては、［ たった今~利用している［ ~proxy, ~router, ~server ］が成す~networkを行き交っている，暗号化されてない~bit ］すべては，［ 実施上は，誰かが読取っていると見做す ］ことが適理になる。 ある攻撃者が，暗号化された~bit列を解するために最善を尽くしていることも、 およそ等しくある — 暗号化された通信を，後の暗号分析~用に格納することも含め （それは、もっと有意な労を要求するが）。 ◎ Due to the decentralized nature of the internet, and the general level of interest in user activity, it’s reasonable to assume that practically every unencrypted bit that’s bouncing around the network of proxies, routers, and servers you’re using right now is being read by someone. It’s equally likely that some of these attackers are doing their best to understand the encrypted bits as well, including storing encrypted communications for later cryptanalysis (though that requires significantly more effort).

• `RFC7258$r “`Pervasive Monitoring Is an Attack^en” 【“（諜報機関などによる）大規模な監視網は攻撃である”】 文書は、 有用な読み物であり，この前提に必然的に伴う~privacyへの影響iの一部を要旨している。 ◎ The IETF’s "Pervasive Monitoring Is an Attack" document [RFC7258] is useful reading, outlining some of the impacts on privacy that this assumption entails.
• 懸念されるものは政府に限らない。 近所の喫茶店や自宅の~ISPも、 顧客の情報を集めている見込みが高い。 ◎ Governments aren’t the only concern; your local coffee shop is likely to be gathering information on its customers, your ISP at home is likely to be doing the same.

3.2. 能動的~network攻撃者

`能動的~network攻撃者@ は、 通信している利用者と~serverの間で伝送路を行き交う~bit列に対し，［ 読取る, 書込む ］両~accessを有する。 攻撃者は、 ~dataを収集して分析できることに加え，伝送途上にある それを改変することもでき、［ ~JS, ~HTML, その他の内容 ］を意のままに注入したり操作できる。 これは、 ~~普通に予期される以上に — 善意的, 悪意的どちらの目的にも — 共通的にある： ◎ An active network attacker has both read- and write-access to the bits going over the wire between users and the servers they’re communicating with. She can collect and analyze data, but also modify it in-flight, injecting and manipulating Javascript, HTML, and other content at will. This is more common than you might expect, for both benign and malicious purposes:

• ［ ~ISP／~cache用~proxy ］は、 ~data利用量を抑制する労の一環として — 利用者へ送達する前に — 定常的に，画像を~cacheして圧縮する。 これは、とりわけ，［ 電話の様な，帯域幅が狭く待時間が長い機器 ］の利用者にとって有用になり得る。 ◎ ISPs and caching proxies regularly cache and compress images before delivering them to users in an effort to reduce data usage. This can be especially useful for users on low-bandwidth, high-latency devices like phones.
• ~ISPはまた、 善意的とは言えない目的で［ ~JS／識別子 ］などを定常的に注入する（例： `COMCAST$r ／ `VERIZON$r ）。 ◎ ISPs also regularly inject JavaScript [COMCAST] and other identifiers [VERIZON] for less benign purposes.
• 利用している~ISPが，相当量の流通を `profit^en のためなら改変する用意がある場合、 `state-level^en の攻撃者が受動的であり続けるとは信じ難くなる。 【 `profit^en（利潤？）と `state-level^en（国家レベル？）とはどうつながる？】 ◎ If your ISP is willing to modify substantial amounts of traffic flowing through it for profit, it’s difficult to believe that state-level attackers will remain passive.

3.3. 同一-生成元~施策に対する違反

`同一-生成元~施策@ は、 ~webにおける~securityの礎石である — 生成元は、 別の生成元の~dataへ直な~accessを有するベキでない （この施策は、より正式には `RFC6454$r `§ 3＠~RFC6454#section-3$ にて定義される）。 この施策の系として、 生成元は `どの生成元にも^em 結付けられない~data — 一例として，利用者の~hard-driveの内容 — に対しては，直な~accessを有するベキでない。 様々な種類の攻撃が、 どうにかして，この保護を迂回しようとする。 例えば： ◎ The same-origin policy is the cornerstone of security on the web; one origin should not have direct access to another origin’s data (the policy is more formally defined in Section 3 of [RFC6454]). A corollary to this policy is that an origin should not have direct access to data that isn’t associated with any origin: the contents of a user’s hard drive, for instance. Various kinds of attacks bypass this protection in one way or another. For example:

• `~XSS攻撃@ （ `cross-site scripting^en ）は、 ~target生成元の文脈の中で，攻撃者が制御する~codeを実行させようと騙している攻撃者を孕む。 ◎ Cross-site scripting attacks involve an attacker tricking an origin into executing attacker-controlled code in the context of a target origin.
• `~CSRF攻撃@ （ `cross-site request forgery^en ）は、 自身に利する要請を提出させることにより，［ 利用者が~log-inしている~site上の，利用者の~~環境に備わる（ `ambient^en な）権限 ］を行使させようと~UAを騙す。 ◎ Cross-site request forgery attacks trick user agents into exerting a user’s ambient authority on sites where they’ve logged in by submitting requests on their behalf.
• ~data漏洩e （ `data leakage^en ）は、 情報を成す~bit列が，不作為に非同一-生成元に可用にされたとき生じる — 各種~CORS~header `CORS$r を介して明示的に, あるいは `TIMING$r の様な~side-channel攻撃を介して暗黙的に。 ◎ Data leakage occurs when bits of information are inadvertently made available cross-origin, either explicitly via CORS headers [CORS], or implicitly, via side-channel attacks like [TIMING].

3.4. 第三者-主体による追跡

~webの力の一部を成すものには、［ 内容／~siteにおける利用者~体験 ］を増補するためとして，~pageが他の第三者-主体から内容（画像から~JSまでに至る）を~pullする能がある。 しかしながら，第三者-主体から内容を~pullすることは、［ 利用者を追跡して~profileするために利用され得る何らかの情報（~referer, その他の情報など） ］を第三者-主体へ漏洩することを，内来的に伴う。 これには，初期~時に格納された~cookieが~domainへ還って行く事も含まれ、 非同一-生成元による追跡を許容している。 さらには，第三者-主体は、 ~web~pageが内包する第三者-主体~JSを通して，実行~力を~~獲得できる。 ［ ~pageは、 第三者-主体の内容による~riskを軽減する手続きを踏める ］としても，［ ~browserは、 所与の~pageを成す内容が［ 当事者-主体, 第三者-主体 ］のどちらに属するかに応じて，扱いを違え得る ］としても、 新たな機能性が（当事者-主体の~siteでなく）第三者-主体により実行される~riskは， 開発~過程において考慮されるベキである。 ◎ Part of the power of the web is its ability for a page to pull in content from other third parties — from images to javascript — to enhance the content and/or a user’s experience of the site. However, when a page pulls in content from third parities, it inherently leaks some information to third parties — referer information and other information that may be used to track and profile a user. This includes the fact that cookies go back to the domain that initially stored them allowing for cross origin tracking. Moreover, third parties can gain execution power through third party Javascript being included by a webpage. While pages can take steps to mitigate the risks of third party content and browsers may differentiate how they treat first and third party content from a given page, the risk of new functionality being executed by third parties rather than the first party site should be considered in the feature development process.

最も単純な例は、［ 特定の条件~下では，挙動が他と異なる~link ］を~siteに注入することである — 例えば、 利用者が~siteに~log-inしたかどうかの事実に基づいて。 これは、 利用者が その~siteに~accountを有するかどうかを露呈し得る。 ◎ The simplest example is injecting a link to a site that behaves differently under specific condition, for example based on the fact that user is or is not logged to the site. This may reveal that the user has an account on a site.

3.5. 合法的な誤利用

強力な特能は、 開発者に可用にされていたとしても，その利用すべてが常に［ 良い案とされる／正当化される ］ベキであることにはならない。 事実，~dataの~privacyに関する世界各国の規制には、 一定の利用に制限sを課すものさえある。 当事者-主体の文脈の下では，合法的な~web~siteは、 強力な特能とヤリトリして，利用者の挙動や性癖について学習-可能になり得る。 例えば： ◎ Even when powerful features are made available to developers, it does not mean that all the uses should always be a good idea, or justified; in fact, data privacy regulations around the world may even put limits on certain uses of data. In the context of first party, a legitimate website is potentially able to interact with powerful features to learn about user behavior or habits. For example:

• ~mouseの~~動きを追跡するなどの仕組みを介して，当の~web~siteを閲覧している利用者を追跡する。 ◎ Tracking the user while browsing the website via mechanisms such as mouse move tracking
• 用法~patternに基づいて，利用者の挙動について~profileする。 ◎ Behavioral profiling of the user based on the usage patterns
• ~webcamや~sensorなどの強力な特能に~accessすることを通して，［ 利用者の~system／ 利用者~自身／ 利用者の周囲のもの ］について学習する。 ◎ Accessing powerful features that enable the first-party to learn about the user’s system, the user themselves, or the user’s susurroundings, such as could be done through a webcam or sensors

この点は、他とは明らかに異なる — `何かがアリであっても，常に行われるベキであることにはならない^em。 よって、~privacyへの影響iの査定を — 加えて，倫理上の査定~さえも — 考慮する必要がある。 ある特能を［ ~security／~privacy ］を念頭に設計するときは、［ 利用, 誤利用 ］どちらも，すべての事例を視野に入れるベキである。 ◎ This point is admittedly different from others - and underlines that even if something may be possible, it does not mean it should always be done, including the need for considering a privacy impact assessment or even an ethical assessment. When designing features with security and privacy in mind, all both use and misuse cases should be in scope.

4.1. ~dataの最小~化

最小~化は、［ 他の通信~相手に公開する情報 ］を［ 所与の演算を完了するために要求される分に限るよう抑える ］ことを孕む策である。 より特定的には、 次のいずれかを要求する： ◎ Minimization is a strategy that involves exposing as little information to other communication partners as is required for a given operation to complete. More specifically, it requires＼

• 利用者が~access【の許可】を仲介する際に~~明らかになったものを超える情報へは、 ~accessを供さない。 ◎ not providing access to more information than was apparent in the user-mediated access or＼
• 正確にどの情報が供されるかについて、 何らかの制御を利用者に許容する。 ◎ allowing the user some control over which information exactly is provided.

例えば，利用者が所与の~fileへの~accessを供した場合、［ それを表現している~objから、 ~fileの親~directoryや~directoryの内容についての情報を得すること ］は，アリにされるベキでない — それは、明瞭に期待されるものではないので。 ◎ For example, if the user has provided access to a given file, the object representing that should not make it possible to obtain information about that file’s parent directory and its contents as that is clearly not what is expected.

~data最小~化の文脈の下では、 自ずと，次を尋ねることになる ⇒＃ 異なる主体の間で渡し回される~dataは何か？／ ~data~itemや識別子はどう持続するか？／ 稼働している異なる~protocolの間で相関される可能性はあるか？ ◎ In context of data minimization it is natural to ask what data is passed around between the different parties, how persistent the data items and identifiers are, and whether there are correlation possibilities between different protocol runs.

例えば， `W3C Device APIs Working Group^cite は、 ~privacy要件~文書 `DAP-PRIVACY-REQS$r にて， いくつかの要件を定義している。 ◎ For example, the W3C Device APIs Working Group has defined a number of requirements in their Privacy Requirements document. [DAP-PRIVACY-REQS]

~data最小~化は、 仕様の［ 策定者／実装者 ］にも，末端向けに~serviceを配備している者にも適用-可能である。 ◎ Data minimization is applicable to specification authors and implementers, as well as to those deploying the final service.

例として、 ~mouse~eventを考える。 ~pageが読込まれるとき，~appには［ ~mouseは装備されているかどうか, ~mouseの種別は何か（例： 製造元や~model）, それは どんな種類の能力を公開するか, いくつ装備されているか, 等々 ］を知る仕方は無い。 これらの情報の一部は、 利用者が~mouseを利用するものと — おそらく，ヤリトリに要求されたため — 裁定したときに限り，可用になる。 その場合でも、 最小な情報のみが公開される： 一例として，それが~trackpadであるかどうかを知ることはできず、 右~buttonを備える事も，利用された場合に限り公開される。 `Gamepad API^cite は、 この~dataを最小~化~能力に用立てる。 ~Web~gameにとっては［ ~UAは~gamepadへの~accessを有するかどうか, いくつ在るか, どんな能力があるか, 等々 ］を知ることは不可能であり、 単純に［ 利用者が~gamepadを通して~gameとヤリトリしたいと望む場合に限り， ~gamepadで動作したことが~gameに知れることになる ］こと，および［ 動作した結果，演算するために必要なすべての（かつ，それを超えない）情報が~appに供されることになる ］ものと見做される。 ◎ As an example, consider mouse events. When a page is loaded, the application has no way of knowing whether a mouse is attached, what type of mouse it is (e.g., make and model), what kind of capabilities it exposes, how many are attached, and so on. Only when the user decides to use the mouse — presumably because it is required for interaction — does some of this information become available. And even then, only a minimum of information is exposed: you could not know whether it is a trackpad for instance, and the fact that it may have a right button is only exposed if it is used. For instance, the Gamepad API makes use of this data minimization capability. It is impossible for a Web game to know if the user agent has access to gamepads, how many there are, what their capabilities are, etc. It is simply assumed that if the user wishes to interact with the game through the gamepad then she will know when to action it — and actioning it will provide the application with all the information that it needs to operate (but no more than that).

~mouse用の機能性が~supportされる仕方は、 単純に［ 一定の~eventが その場を占めたときに限り， ~mouseの挙動についての情報を供する ］ことによる。 したがってこの~approachでは、 機器への~interfaceとして，~eventの取扱い （例： `onclick^m, `onmousemove^m, `onmousedown^m, 等々を誘発する） のみを公開する。 ◎ The way in which the functionality is supported for the mouse is simply by only providing information on the mouse’s behaviour when certain events take place. The approach is therefore to expose event handling (e.g., triggering on click, move, button press) as the sole interface to the device.

自身の特能が公開する~dataを最小限にした仕様には、 次の 2 つが挙げられる： ◎ Two specifications that have minimized the data their features expose are:

• `BATTERY-STATUS$r ⇒ ~UAは高-精度な読出しを公開するベキでない ◎ [BATTERY-STATUS] "The user agent should not expose high precision readouts"
• `GENERIC-SENSOR$r ⇒＃ 最大~標本化~frequencyを制限する, 正確度を抑制する ◎ [GENERIC-SENSOR] "Limit maximum sampling frequency", "Reduce accuracy"

4.2. 既定の~privacy設定群

利用者は、 既定の設定を変更しないことが多い。 結果として，当の仕様の既定の~modeにおいては、 公開される［ ~data／識別子 ］の［ 量, 識別-能, 持続性 ］を最小限にすることが重要になる。 これは特に、 当の~protocolが［ 特定の環境に誂えれるような柔軟な~option群 ］を伴う場合が該当する。 ◎ Users often do not change defaults, as a result, it is important that the default mode of a specification minimizes the amount, identifiability, and persistence of the data and identifiers exposed. This is particularly true if a protocol comes with flexible options so that it can be tailored to specific environments.

4.3. 利用者による明示的な仲介

当の特能の［ ~security／~privacy ］~riskを他では軽減し得ない場合、 アリな軽減として，任意選択で利用者に~promptすることを実装者に許容することが最善になることもある — が，それを【利用者が~promptを？】解することは、 ~privacy~riskをまるごと除去するものではない。 ~promptすることを当の仕様が実装者に許容しない場合、 一部の~UAが，もっと~privacyに親切な~versionを実装することを選ぶ結果、 各~UAで実装が分岐する結果になりかねない。 ◎ If the security or privacy risk of a feature cannot otherwise be mitigated in a specification, optionally allowing an implementer to prompt a user may be the best mitigation possible, understanding it does not entirely remove the privacy risk. If the specification does not allow for the implementer to prompt, it may result in divergence implementations by different user agents as some user agents choose to implement more privacy-friendly version.

特能の~riskは、 それ自体が特能たらしめるものであるがため，軽減し得ない場合もある。 一例として， `GEOLOCATION$r は、 利用者の所在を意図的に露呈する。 一般に~UAは、 受容するかどうか利用者が選べる許可~prompt上で， 当の特能への~access可否を~~制御する。 この~riskは、 個人-~dataや識別子を公開する特能にも在るので，それらにも織り込まれるベキである。 ◎ It is possible that the risk of a feature cannot be mitigated because the risk is endemic to the feature itself. For instance, [GEOLOCATION] reveals a user’s location intentionally; user agents generally gate access to the feature on a permission prompt which the user may choose to accept. This risk is also present and should be accounted for in features that expose personal data or identifiers.

そのような~promptを設計する困難さは、 供するベキ許可の持続時間を決定することにある。 ◎ Designing such prompts is difficult as is determining the duration that the permission should provide.

最良な~promptは、 ~file~pickerの様に，利用者の動作に明瞭に束ねられるものが多い — そこでは、 利用者の動作に呼応して~file~pickerが持込まれ， 利用者は特定の~fileへの~accessを個々の~siteに与える。 ◎ Often, the best prompt is one that is clearly tied to a user action, like the file picker, where in response to a user action, the file picker is brought up and a user gives access to a specific file to an individual site.

一般的に言えば，~prompt【による許可】の持続時間と時機は、 ~dataを公開することによる~risk【の高さ】に反比例するベキである。 加えて，~promptは、 次に挙げる課題を考慮するベキである： ◎ Generally speaking, the duration and timing of the prompt should be inversely proportional to the risk posed by the data exposed. In addition, the prompt should consider issues such as:

• どこまでの許可~要請を視野に入れるベキか？ — とりわけ，第三者-主体に属する埋込d `iframe$e から要請されたとき。 ◎ How should permission requests be scoped? Especially when requested by an embedded third party iframe?
• 持続性は［ ~top-levelの内容の生成元, 埋込d内容の生成元 ］の~pairに基づくべきか？ 違う視野に基づくベキか？ ◎ Should persistence be based on the pair of top-level/embedded origins or a different scope?
• ［ ~promptは~dataを要求している文脈にて生じていること、 その時，なぜ~promptが生じているか ］が，利用者に明瞭になることは、 どれほど確かか？ ◎ How is it certain that the prompt is occurring in context of requiring the data and at a time that it is clear to the user why the prompt is occurring.
• 利用者に~promptする前に，許可した場合の含意 — `誰^emが, `何^emを依頼していて, `なぜ^em必要になるのか？ — を［ ~access可能, かつ地域化された仕方 ］で説明すること。 ◎ Explaining the implications of permission before prompting the user, in a way that is accessible and localized -- _who_ is asking, _what_ are they asking for, _why_ do they need it?
• 利用者が［ ~promptの時点で要請を却下した／後で気が変わって~accessを~revokeした ］場合に何が起こるか？ ◎ What happens if the user rejects the request at the time of the prompt or if the user later changes their mind and revokes access.

これらの~promptは、［ 他の主体と共有された後，それらの~dataに対し利用者が有する制御 ］についての考慮点も含むベキである。 例えば，利用者は、 他の主体に共有される情報として，何を決定-可能か？ ◎ These prompts should also include considerations for what, if any, control a user has over their data after it has been shared with other parties. For example, are users able to determine what information was shared with other parties?

4.4. 当の特能を明示的に当事者-主体の生成元に制約する

`§ 第三者-主体による追跡＠#third-party-tracking$ にて述べたように、 同じ~web~pageが［ 当事者-主体, 第三者-主体 ］による内容を同じ~appに混合する場合、 第三者-主体の内容が［ 当事者-主体の内容が利用し得るものと同じ，一式の~web特能 ］を誤利用し得る~riskを導入する。 ◎ As described in the "Third-Party Tracking" section, web pages mix first and third party content into a single application, which introduces the risk that third party content can misuse the same set of web features as first party content.

策定者は、 当の特能が可用になる視野を明示的に指定するベキである： ◎ Authors should explicitly specify a feature’s scope of availability:

• 第三者-主体に属する埋込d内容に対し，当の特能はいつ可用にされるベキか？ — これは、［ 当事者-主体が，それを（ `iframe$e の属性／`許可~施策$【！特能~施策】を利用して）明示的に制御-可能にするベキかどうか ］も含むことが多い。 ◎ When a feature should be made available to embedded third parties -- and often first parties should be able to explicitly control that (using iframe attributes or feature policy)
• 当の特能は、 ~~背後に回された~UItab【`~navigable$】でも可用にするのか，［ ~top-levelの／可視な ］~UItabに限るベキか？ ◎ Whether a feature should be available in the background or only in the top-most, visible tab.
• 当の特能は、 ~offline~swにも可用にするベキか？ ◎ Whether a feature should be available to offline service workers.
• ~eventは同時的に発火されることになるか？ ◎ Whether events will be fired simultaneously

第三者-主体による当の特能への~accessは、 適合性のためには，任意選択な実装になるベキである。 ◎ Third party access to a feature should be an optional implementation for conformance.

4.5. ~secureな文脈

当の仕様~内で，ある特能にて識別された首な~riskが`能動的~network攻撃者$による脅威である場合、 ~secureでない生成元に当の特能を提供することは， 当の特能をどの生成元にも提供するのと同じことになる — 攻撃者は~frameや~codeを意のままに注入できるので。 この種類の~riskは、［ 当の特能を利用するためには，暗号化され, 認証された接続を要求する ］ことで軽減できる。 ◎ If the primary risk that you’ve identified in your specification is the threat posed by active network attacker, offering a feature to an insecure origin is the same as offering that feature to every origin because the attacker can inject frames and code at will. Requiring an encrypted and authenticated connection in order to use a feature can mitigate this kind of risk.

`~secureな文脈$enVはまた、 `受動的~network攻撃者$に抗して保護する。 例えば、 ある~pageが `Geolocation API^cite を利用していて， ~sensorから供された［ 緯度, 経度 ］を~secureでない接続~越しに~serverへ送信した場合、 どの`受動的~network攻撃者$も 利用者の所在を学習できる — 利用者~その他にとって実現可能な検出-法は無い。 ◎ Secure contexts also protect against passive network attackers. For example, if a page uses the Geolocation API and sends the sensor-provided latitude and longitude back to the server over an insecure connection, then any passive network attacker can learn the user’s location, without any feasible path to detection by the user or others.

しかしながら，`~secureな文脈$enVを要求するだけでは、 `能動的~network攻撃者$ 以外の脅威~動作者からの多くの~privacy~riskを — あるいは~security~riskでさえも — 軽減するには足らない。 ◎ However, requiring a secure context is not sufficient to mitigate many privacy risks or even security risks from other threat actors than active network attackers.

4.6. 当の特能を落とす

場合によっては、 当の特能を落とすことが，その特能による［ ~security／~privacy ］への負になり得る影響iを軽減する最も単純な仕方になる — ［ ~security／~privacy ］~riskのうち一部は、 ~platformに特能を追加することにより［ 除去され得る／軽減され得る ］（順不同）ことも，念頭に置くベキであるが。 当の特能は，どれも、［ ~security／~privacy ］~riskを潜在的に追加していると見るベキである — そうでないと立証されない限り。 ［ ~security／~privacy ］への影響iを軽減するため当の特能を落とすことについて論じることは、 有益な演習になる — ［ 当の特能, 公開している~dataは必要最小限かどうか, 他にアリな軽減策 ］の間における~tradeoffを浮彫りにする助けになるので。 ◎ Possibly the simplest way to mitigate potential negative security or privacy impacts of a feature is to drop the feature, though you should keep in mind that some security or privacy risks may be removed or mitigated by adding features to the platform. Every feature in a specification should be seen as potentially adding security and/or privacy risk until proven otherwise. Discussing dropping the feature as a mitigation for security or privacy impacts is a helpful exercise as it helps illuminate the tradeoffs between the feature, whether it is exposing the minimum amount of data necessary, and other possible mitigations.

特能の追加による累積的な効果 — `~web~pageを訪問しても安全＠~DESIGN-PRINCIPLES#safe-to-browse$かどうかに関して，利用者が受ける全般的な印象に対する効果 — も考慮すること。 ［ ~web~siteを訪問しても安全かどうかについて，利用者の理解を複雑化する何かを行う／ 利用者が~webの安全性について理解する必要があるものを複雑化する （例：安全さに劣る特能を追加する） ］ことは、 利用者が［ 安全性の理解に基づいて／ 存在する安全性を正しく反映する仕方で ］動作する能を抑制する。 ◎ Consider also the cumulative effect of feature addition to the overall impression that users have that it is safe to visit a web page. Doing things that complicate users' understanding that it is safe to visit websites, or that complicate what users need to understand about the safety of the web (e.g., adding features that are less safe) reduces the ability of users to act based on that understanding of safety, or to act in ways that correctly reflect the safety that exists.

どの仕様も，アリな限り小さくなるよう~~追求するベキである — その理由が［ ~security／~privacy ］の攻撃~表口を抑制したり最小限にするためでしかない場合でも。 そうすることにより、 全般的な［ ~security, ~privacy ］の攻撃~表口を抑制できるようになる — 特定0の特能のみならず，［ ~module（関係する一式の特能）／仕様／全般的な~web~platform ］のそれも。 ◎ Every specification should seek to be as small as possible, even if only for the reasons of reducing and minimizing security/privacy attack surface(s). By doing so we can reduce the overall security and privacy attack surface of not only a particular feature, but of a module (related set of features), a specification, and the overall web platform.

例えば： ◎ Examples

• ［ Mozilla ／ WebKit ］は、 `Battery Status API^cite `BATTERY-STATUS$r を［ `落とした＠https://bugzilla.mozilla.org/show_bug.cgi?id=1313580$／ `落とした＠https://bugs.webkit.org/show_bug.cgi?id=164213$ ］ ◎ Mozilla and WebKit dropped the Battery Status API
• Mozilla は、 次に挙げる~eventを `落とした＠https://bugzilla.mozilla.org/show_bug.cgi?id=1359076$ ⇒＃ `devicelight^et, `deviceproximity^et, `userproximity^et ◎ Mozilla dropped devicelight, deviceproximity and userproximity events

4.7. ~privacyへの影響iの査定を為すこと

一部の特能は、 敏感な~dataを給するものになり得る。 ［ 末端~開発者／~system所有者／管理者 ］は、 このことを実感する下で，~systemを設計する責務がある。 一部の利用では — とりわけ，各個人に関係する~dataが処理され得るときは — ~privacyへの影響iの査定を指揮するよう，請合う仕様もある。 ◎ Some features potentially supply sensitive data, and it is the responsibility of the end-developer, system owner, or manager to realize this and act accordingly in the design of their system. Some use may warrant conducting a privacy impact assessment, especially when data relating to individuals may be processed.

当の仕様が敏感な~dataを公開する特能を含む場合、 その~APIを採用している［ ~web~site／~app ］に対する推奨として，［ 自身が収集する~dataによる~privacyへの影響iについての査定を指揮する ］ことを含めるベキである。 ◎ Specifications that include features that expose sensitive data should include recommendations that websites and applications adopting the API conduct a privacy impact assessment of the data that they collect.

これを行う特能としては、 次が挙げられる ⇒ `GENERIC-SENSOR$r は、 ~privacyへの影響iについて査定を遂行することを考慮するよう勧めている ◎ A feature that does this is: • [GENERIC-SENSOR] advises to consider performing of a privacy impact assessment

これらの影響iを文書化することは、 組織にとって重要になる — この責を組織に課すことに制限があることは、 注記されるベキであるが。 事実調査から、 仕様~内の［ ~security／~privacy ］要件に準拠していない~siteが多いことが示されている。 例えば， `DOTY-GEOLOCATION$r では、 ~~調査された~web~siteのうち［ 所在を~promptする前に，自身の~privacy実施を利用者に伝えている~site ］は皆無であることが見出されている。 ◎ Documenting these impacts is important for organizations although it should be noted that there are limitations to putting this onus on organizations. Research has shown that sites often do not comply with security/privacy requirements in specifications. For example, in [DOTY-GEOLOCATION], it was found that none of the studied websites informed users of their privacy practices before the site prompted for location.