From 6a1a0bbc58a2c1855a038385ca56d9149cec9f6a Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Thu, 26 Sep 2024 00:35:55 +0000 Subject: [PATCH] Rename "ancillary" to "supporting" and "non-ancillary" to "essential." --- index.html | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/index.html b/index.html index 8db47cc..57a23e5 100644 --- a/index.html +++ b/index.html @@ -1251,17 +1251,17 @@ -### Ancillary uses +### Supporting uses [=Sites=] sometimes use data in ways that aren't needed for the user's immediate goals. For example, they might bill advertisers, measure site performance, or -tell developers about bugs. These uses are known as ancillary uses. +tell developers about bugs. These uses are known as supporting uses. -[=Sites=] can get the data they want for [=ancillary uses=] from a variety of places: +[=Sites=] can get the data they want for [=supporting uses=] from a variety of places:
-
Non-ancillary APIs
+
Essential APIs
Web APIs that were designed to support users' immediate goals, like DOM events and .
-
Ancillary APIs computed from existing information
+
Supporting APIs computed from existing information
APIs that filter, summarize, or time-shift information available from - [=non-ancillary APIs=], like the [[[event-timing]]] and IntersectionObserver. See - [[[#information]]] for restrictions on how existing non-ancillary APIs can - be used to justify new ancillary APIs. + [[[#information]]] for restrictions on how existing essential APIs can + be used to justify new supporting APIs.
-
Ancillary APIs that provide new information
+
Supporting APIs that provide new information
APIs that provide new information that's primarily useful to support the - ancillary uses, like element paint + supporting uses, like element paint timing, memory usage measurements, and deprecation @@ -1298,10 +1298,10 @@ use of this data. The task force does not have consensus about how [=user agents=] should handle -[=ancillary APIs computed from existing information=]. +[=supporting APIs computed from existing information=]. Advocates of these APIs argue that they're hard to use to extract [=personal data=], they're more efficient than collecting the same -information though [=non-ancillary APIs=], sites are less likely to adopt these +information though [=essential APIs=], sites are less likely to adopt these APIs if a significant number of people turn them off, and that the act of turning them off can contribute to [=browser fingerprinting=]. Opponents argue that if data's easier or cheaper to collect, more sites will @@ -1312,24 +1312,24 @@ Because different users are likely to have different preferences:
-Specifications -for [=ancillary APIs computed from existing information=] and [=ancillary APIs +Specifications +for [=supporting APIs computed from existing information=] and [=supporting APIs that provide new information=] should identify them as such, so that [=user agents=] can provide appropriate choices for their users.
-#### Designing ancillary APIs that provide new information {#designing-ancillary-apis-with-new-information} +#### Designing supporting APIs that provide new information {#designing-supporting-apis-with-new-information}
-[=Ancillary APIs that provide new information=] should not reveal any [=personal +id="principle-supporting-apis-with-new-information-shouldnt-reveal-personal-data"> +[=Supporting APIs that provide new information=] should not reveal any [=personal data=] that isn't already available through other APIs, without an indication that doing so aligns with the user's wishes and interests.
-Most [=ancillary uses=] don't require that a site learn any [=personal data=]. +Most [=supporting uses=] don't require that a site learn any [=personal data=]. For example, site performance measurements and ad billing involve averaging or summing data across many users such that any individual's contribution is obscured. Private aggregation techniques can often allow an API to serve its use @@ -1347,7 +1347,7 @@ Group">PATCG groups. -Some [=ancillary uses=] don't require their data to be related to a person, but +Some [=supporting uses=] don't require their data to be related to a person, but the useful aggregations across many people are difficult to design into a web API, or they might require new technologies to be invented. API designers have a few choices in this situation: @@ -1369,15 +1369,15 @@ API needs to change, designers should consider replacing the whole API with one that avoids exposing [=personal data=]. -Some other [=ancillary uses=] do require that a person be connected to their +Some other [=supporting uses=] do require that a person be connected to their data. For example, a person might want to file a bug report that a website breaks on their particular computer, and be able to get follow-up communication from the developers while they fix the bug. This is an appropriate time to ask the person's permission.
- -User agents should provide a way to enable or disable [=ancillary APIs that + +User agents should provide a way to enable or disable [=supporting APIs that provide new information=] and should set the default according to their users' needs. @@ -1385,7 +1385,7 @@ Some people might know something about their specific situation that makes the API designers' general decisions inappropriate -for them. Because the information provided by [=ancillary APIs that provide new +for them. Because the information provided by [=supporting APIs that provide new information=] isn't available in any other way, [=user agents=] should let people turn them off, despite the additional risk of [=browser fingerprinting=].