infra.spec.whatwg.orgInfra Standard

Infra Living Standard — Last Updated 6 August 2020 Participate: GitHub whatwg/infra ( new issue , open issues ) IRC: #whatwg on Freenode Commits: GitHub whatwg/infra/commits Snapshot as of this commit @infrastandard Tests: web-platform-tests infra/ ( ongoing work ) Translations (non-normative) : 日本語 Abstract The aims to define the fundamental concepts upon which standards are built. Table of Contents Goals 1 Usage 2 Conventions 2.1 Conformance 2.2 Compliance with other specifications 2.3 Terminology 2.4 Privacy concerns 3 Algorithms 3.1 Conformance 3.2 Declaration 3.3 Variables 3.4 Control flow 3.5 Conditional abort 3.6 Iteration 3.7 Assertions 4 Primitive data types 4.1 Nulls 4.2 Booleans 4.3 Bytes 4.4 Byte sequences 4.5 Code points 4.6 Strings 5 Data structures 5.1 Lists 5.1.1 Stacks 5.1.2 Queues 5.1.3 Sets 5.2 Maps 5.3 Structs 6 JSON 7 Forgiving base64 8 Namespaces Acknowledgments Index Terms defined by this specification Terms defined by reference References Normative References Informative References Goals Deduplicate boilerplate in standards. Align standards on conventions, terminology, and data structures. Be a place for concepts used by multiple standards without a good home. Help write clear and readable algorithmic prose by clarifying otherwise ambiguous concepts. Suggestions for more goals welcome. 1. Usage To make use of the in a document titled X , use X depends on the . Additionally, cross-referencing terminology is encouraged to avoid ambiguity. Specification authors are also encouraged to add their specification to the list of dependent specifications in order to help the editors ensure that any future breaking changes to the are correctly reflected by any such dependencies. 2. Conventions 2.1. Conformance All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. [RFC2119] These keywords have equivalent meaning when written in lowercase and cannot appear in non-normative content. This is a willful violation of RFC 8174, motivated by legibility and a desire to preserve long-standing practice in many non-IETF-published pre-RFC 8174 documents. [RFC8174] All of the above is applicable to both this standard and any document that uses this standard. Documents using this standard are encouraged to limit themselves to "must", "must not", "should", and "may", and to use these in their lowercase form as that is generally considered to be more readable. For non-normative content "strongly encouraged", "strongly discouraged", "encouraged", "discouraged", "can", "cannot", "could", "could not", "might", and "might not" can be used instead. 2.2. Compliance with other specifications In general, specifications interact with and rely on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs require a specification to violate the requirements of other specifications. When this occurs, a document using the should denote such transgressions as a willful violation , and note the reason for that violation. The previous section, § 2.1 Conformance , documents a willful violation of RFC 8174 committed by the . 2.3. Terminology The word "or", in cases where both inclusive "or" and exclusive "or" are possible (e.g., "if either width or height is zero"), means an inclusive "or" (implying "or both"), unless it is called out as being exclusive (with "but not both"). A user agent is any software that acts on behalf of a user, for example by retrieving and rendering web content and facilitating end user interaction with it. In specifications using the , the user agent is generally the client software that implements the specification. Implementation can be used as a synonym for user agent . If something is said to be implementation-defined , the particulars of what is said to be implementation-defined are up to the user agent . In the absence of such language, the reverse holds: user agents have to follow the rules laid out in documents using this standard. Insert U+000A (LF) code points into input in an implementation-defined manner such that each resulting line has no more than width code points. For the purposes of this requirement, lines are delimited by the start of input , the end of input , and U+000A (LF). 2.4. Privacy concerns Some features that are defined in documents using the might trade user convenience for a measure of user privacy. In general, due to the internet’s architecture, a user can be distinguished from another by the user’s IP address. IP addresses do not perfectly match to a user; as a user moves from device to device, or from network to network, their IP address will change; similarly, NAT routing, proxy servers, and shared computers enable packets that appear to all come from a single IP address to actually map to multiple users. Technologies such as onion routing can be used to further anonymize requests so that requests from a single user at one node on the internet appear to come from many disparate parts of the network. [RFC791] However, the IP address used for a user’s requests is not the only mechanism by which a user’s requests could be related to each other. Cookies, for example, are designed specifically to enable this, and are the basis of most of the web’s session features that enable you to log into a site with which you have an account. More generally, any kind of cache mechanism or shared state, including but not limited to HSTS, the HTTP cache, grouping of connections, storage APIs, can and ought to be expected to be abused. [COOKIES] [RFC6797] [STORAGE] There are other mechanisms that are more subtle. Certain characteristics of a user’s system can be used to distinguish groups of users from each other. By collecting enough such information, an individual user’s browser’s "digital fingerprint" can be computed, which can be better than an IP address in ascertaining which requests are from the same user. Grouping requests in this manner, especially across multiple sites, can be used for malevolent purposes, e.g., governments combining information such as the person’s home address (determined from the addresses they use when getting driving directions on one site) with their apparent political affiliations (determined by examining the forum sites that they participate in) to determine whether the person should be prevented from voting in an election. Since the malevolent purposes can be remarkably evil, user agent implementors and specification authors are strongly encouraged to minimize leaking information that could be used to fingerprint or track a user. Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit to be derived from exposing APIs that can also be abused for fingerprinting and tracking purposes, so it’s not as easy as blocking all possible leaks. For instance, the ability to log into a site to post under a specific identity requires that the user’s requests be identifiable as all being from the same user, more or less by definition. More subtly, though, information such as how wide text is, which is necessary for many effects that involve drawing text onto a canvas (e.g., any effect that involves drawing a border around the text) also leaks information that can be used to group a user’s requests. (In this case, by potentially exposing, via a brute force search, which fonts a user has installed, information which can vary considerably from user to user.) Features that are defined in documents using the that can be used as a tracking vector are marked as this paragraph is. Other features in the platform can be used for the same purpose, including, but not limited to: The exact list of which features a user agents supports. The maximum allowed stack dep...