Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rename "ancillary" to "supporting" and "non-ancillary" to "essential." #438

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Rename "ancillary" to "supporting" and "non-ancillary" to "essential." #438

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 24 additions & 24 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1251,37 +1251,37 @@

</aside>

### 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 <dfn data-lt="ancillary
use">ancillary uses</dfn>.
tell developers about bugs. These uses are known as <dfn data-lt="supporting
use">supporting uses</dfn>.

[=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:

<dl>
<dt><dfn>Non-ancillary APIs</dfn></dt>
<dt><dfn>Essential APIs</dfn></dt>
<dd>
Web APIs that were designed to support users' immediate goals, like <a
data-cite="dom#interface-event">DOM events</a> and <a
data-cite="cssom-view-1#extension-to-the-element-interface">element position
observers</a>.
</dd>

<dt><dfn>Ancillary APIs computed from existing information</dfn></dt>
<dt><dfn>Supporting APIs computed from existing information</dfn></dt>
<dd>
APIs that filter, summarize, or time-shift information available from
[=non-ancillary APIs=], like the [[[event-timing]]] and <a
[=essential APIs=], like the [[[event-timing]]] and <a
data-cite="intersection-observer#introduction">IntersectionObserver</a>. 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.
</dd>

<dt><dfn>Ancillary APIs that provide new information</dfn></dt>
<dt><dfn>Supporting APIs that provide new information</dfn></dt>
<dd>
APIs that provide new information that's primarily useful to support the
ancillary uses, like <a data-cite="element-timing#sec-intro">element paint
supporting uses, like <a data-cite="element-timing#sec-intro">element paint
timing</a>, <a data-cite="performance-measure-memory#intro">memory usage
measurements</a>, and <a
data-cite="deprecation-reporting#deprecation-report">deprecation
Expand All @@ -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
Expand All @@ -1312,24 +1312,24 @@
Because different users are likely to have different preferences:

<div class="practice" data-audiences="api-designers">
<span class="practicelab" id="principle-identify-ancillary-apis">Specifications
for [=ancillary APIs computed from existing information=] and [=ancillary APIs
<span class="practicelab" id="principle-identify-supporting-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.</span>
</div>

#### 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}

<div class="practice" data-audiences="api-designers">
<span class="practicelab"
id="principle-ancillary-apis-with-new-information-shouldnt-reveal-personal-data">
[=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.
</span>
</div>

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
Expand All @@ -1347,7 +1347,7 @@
Group">PATCG</abbr></a> groups.
</aside>

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:
Expand All @@ -1369,23 +1369,23 @@
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.

<div class="practice" data-audiences="user-agents">
<span class="practicelab" id="principle-disabling-ancillary-apis-with-new-information">
User agents should provide a way to enable or disable [=ancillary APIs that
<span class="practicelab" id="principle-disabling-supporting-apis-with-new-information">
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.
</span>
</div>

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=].
Expand Down