Rewrite ancillary uses to focus on 2 kinds of ancillary APIs rather than ancillary data. #361

jyasskin · 2023-10-06T00:22:54Z

This is a replacement for #359 after the discussion in https://github.com/w3ctag/privacy-principles/blob/main/meetings/2023-10-04-minutes.md. It will close #220.

@pes10k, I think I fixed your comments:

"identifiable person" was an echo of a phrase in the definition of "personal data", but I found a way to avoid it.
I replaced the CSP report example with event timings. There's also a nit there that the duration field is a novel piece of data, so I could narrow this to just the processingEnd field.
I reworded the "it complies with this principle" bit and also moved the second principle in the section down to just before the paragraph that elaborates on it. This violates the guideline we've been following to put principles at the tops of their sections, so maybe folks will want me to move it back.

Preview | Diff

yoavweiss · 2023-10-09T14:38:01Z

index.html

+  <dd>
+    APIs that filter or summarize information available from [=non-ancillary
+    APIs=], like the [[[event-timing]]] and <a
+    data-cite="intersection-observer#introduction">IntersectionObserver</a>.


I wouldn't consider intersection observer ancillary. It's somewhat polyfillable, but can be used to e.g. lazily load parts of the UI.

Ah, and that's supported by https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API. What's a good API to use as an example here? Ideally one that does more processing than just filtering out un-interesting events. I'll try to look again before the Wednesday meeting, but you might just know one off the top of your head.

index.html

yoavweiss · 2023-10-09T14:41:33Z

index.html

-when [=ancillary data=] contributes to a collective benefit in a way
-that reduces privacy threats to individuals (see <a href="#principle-collective-privacy">collective
-privacy</a>).
+  <dt><dfn>Novel ancillary APIs</dfn></dt>


Maybe "new sources of ancillary data"?

I could do that or

Suggested change

<dt><dfn>Novel ancillary APIs</dfn></dt>

<dt><dfn>Ancillary APIs that provide new information</dfn></dt>

along with <dfn>Ancillary APIs that filter or summarize other sources of information</dfn> above to stay parallel. I'll give other folks a chance to weigh in before making this change.

@npdoty suggested using the "unavoidable information exposure" phrase, and I'll try to work that in.

Done; please check that the new wording looks ok.

yoavweiss · 2023-10-09T14:43:11Z

index.html

+APIs if a significant number of people turn them off, and that the act of
+turning them off can ironically contribute to [=browser fingerprinting=].
+Opponents argue that if data's easier or cheaper to collect, more sites will
+collect it, and because there's still some risk and cost, users should be able


Is "cost" here related to privacy?

Maybe: it's about the computational and network costs, so not about exposing user information. I think the connection to privacy is that it's about using a user's resources without their knowledge for things they might not like, and if they notice, they might be uneasy about what else the site can do. But the closest item in https://wiki.openrightsgroup.org/wiki/A_Taxonomy_of_Privacy that seems to match is Intrusion, and that's limited to when the intrusion is “highly offensive to a reasonable person”, which is probably not the case for these APIs.

@pes10k, I'm trying to represent your concern with this bit, so maybe you can justify why this is a privacy concern better than I can?

Otherwise, I can just remove "and cost" without touching the rest of the paragraph.

I think the privacy impact of cost was primarily the point in the previous part of the sentence -- that reducing cost will make the data collection more ubiquitous.

Users may also want to disable APIs just because they cost network and processing resources; in some cases that might be considered a privacy issue, but I think that's mostly just a distinct user control issue and doesn't need to be covered here. Removing "and cost" seems just as clear to me.

(fwiw, @npdoty expressed the concern i was trying to get across)

I've removed "and cost".

jyasskin · 2023-10-09T20:46:24Z

index.html

+  asking for each use of the APIs.
+
+API designers should maintain APIs that had to make one of these choices and
+should keep trying to evolve them toward aggregating the data instead.


@pes10k @sandandsnow You'd been concerned about saying that "aggregation" is sufficient for depersonalizing data. Is there a term I should use instead? Above I used "private aggregation", but I'm happy to use something else or to define something.

yoavweiss · 2023-10-10T07:32:41Z

index.html

+<span class="practicelab"
+id="principle-novel-ancillary-apis-shouldnt-reveal-personal-data">[=Novel
+ancillary APIs=] should not reveal any [=personal data=] that isn't already
+available through other APIs, without permission.</span>


"permission" bakes a solution into the principle. Maybe "without proper mitigations or justifications"?

I'm worried that "proper mitigations" leaves it too open to debate. https://w3ctag.github.io/privacy-principles/#data-minimization uses "aligns with the user's wishes and interests", so I could use that here, if folks agree:

Suggested change

available through other APIs, without permission.</span>

available through other APIs, without an indication that doing so aligns

with the user's wishes and interests.</span>

npdoty

I'm not clear what issue this addresses or how this re-write improves on the existing text.

This seems to repeat and more deeply encode the new-vs-old distinction, which seems to set up further debates over how minimization shouldn't apply if something is old enough or has some alternative use.

This seems to delete much of the text about solicitation and respecting of general preferences around analytics and other ancillary uses. Further, it seems to actively discourage browsers from providing general choices.

npdoty · 2023-10-11T14:52:41Z

index.html

+use of this data.
+
+[=User agents=] usually can't do much about data collection from the
+[=non-ancillary APIs=].


I'm not sure this statement is accurate. It also doesn't seem to be necessary for any principles in this section.

It's mostly here because I wanted to say something about all three categories that I introduced above. I'm fine with removing it.

npdoty · 2023-10-11T14:55:26Z

index.html

+APIs if a significant number of people turn them off, and that the act of
+turning them off can ironically contribute to [=browser fingerprinting=].
+Opponents argue that if data's easier or cheaper to collect, more sites will
+collect it, and because there's still some risk and cost, users should be able


I think the privacy impact of cost was primarily the point in the previous part of the sentence -- that reducing cost will make the data collection more ubiquitous.

Users may also want to disable APIs just because they cost network and processing resources; in some cases that might be considered a privacy issue, but I think that's mostly just a distinct user control issue and doesn't need to be covered here. Removing "and cost" seems just as clear to me.

index.html

npdoty · 2023-10-11T15:00:05Z

index.html

+[=non-ancillary APIs=].
+
+There is disagreement about how [=user agents=] should handle [=summarizing
+ancillary APIs=]. Advocates of these APIs argue that they're hard to use to


I'm not sure what we're gaining from summarizing the different arguments here. This doesn't seem to provide any advice as a result of the documented disagreement.

I'd be fine with removing this paragraph if that's what the group wants to do.

npdoty · 2023-10-11T15:01:21Z

index.html

+functionality.
+
+We do have consensus that [[[#information]]] governs [=summarizing ancillary
+APIs=] and that:


Do we need to note consensus that the other principles in the document still apply? That would seem to be the case for all principles.

I'd be fine with dropping that.

Reworded to

Because different users are likely to have different preferences:

That's still a little awkward, so I'd welcome other wording suggestions.

npdoty · 2023-10-11T15:29:57Z

index.html

+<div class="practice" data-audiences="user-agents">
+<span class="practicelab" id="principle-disabling-novel-ancillary-apis">User
+agents should provide a way to disable [=novel ancillary APIs=].</span>
+</div>


This seems to imply that users should be allowed to turn off this subset of APIs, but not other APIs.

And it seems to set up an incomprehensible and unpleasant choice for users. Rather than asking users whether they want to provide telemetry data, UAs would instead ask, "do you want to disable novel ancillary apis but continue to provide very similar data through a different set of ancillary apis?"

The other ancillary APIs aren't providing "very similar data". If they were, this set of APIs wouldn't "provide new information."

UAs are also free to have their setting turn off more APIs than the ones called out here; this just sets a minimum bar.

npdoty · 2023-10-11T15:35:30Z

index.html

-
-To help [=sites=] understand user preferences, user agents can provide
-browser-configurable signals to directly communicate common user preferences
-(such as a [=global opt-out=]).


why is this being deleted?

It's not related to ancillary data, and https://w3ctag.github.io/privacy-principles/#dfn-global-opt-out still says that UAs can provide this sort of signal.

npdoty · 2023-10-11T15:35:57Z

index.html

@@ -1161,34 +1215,43 @@
  Group">PATCG</abbr></a> groups.
 </aside>

-[=User agents=] should aggressively <a href="#data-minimization">minimize</a> [=ancillary
-data=] and should avoid burdening the user with additional [=privacy labor=]


why remove the requirement to minimize this data?

We already say to minimize the data in https://w3ctag.github.io/privacy-principles/#data-minimization. I don't think we actually have consensus to "aggressively" minimize the APIs that are computed from existing information, and the new text says something more precise and stronger about the ancillary APIs that provide new information: that they shouldn't provide personal data at all.

npdoty · 2023-10-11T15:42:59Z

index.html

+  ask the user whether they generally support sharing this data, rather than
+  asking for each use of the APIs.
+
+API designers should maintain APIs that had to make one of these choices and


what is the maintenance requirement? I'm not clear what we're asking designers to do.

npdoty · 2023-10-11T15:44:20Z

index.html

+  asking for each use of the APIs.
+
+API designers should maintain APIs that had to make one of these choices and
+should keep trying to evolve them toward aggregating the data instead.


Is this a useful exhortation? What would convince API designers to migrate to an aggregation alternative if they aren't required to minimize data and users are actively discouraged from disabling this functionality?

API designers are required to minimize data by https://w3ctag.github.io/privacy-principles/#data-minimization. I'd be ok with deleting this paragraph if folks don't think it's useful, but I figured it'd be useful to encourage designers to keep trying to find alternatives that don't reveal personal data. We could also re-word it if there's a clearer wording for that.

Based on today's conversation, trying:

If an API had to make one of these choices, and then something else about the API needs to change, designers should consider replacing the whole API with one that avoids exposing [=personal data=] if possible.

…han ancillary data.

index.html

pes10k · 2023-11-18T22:26:25Z

From slack

But if @torgo (or others) supports that direction again, as an alternative to the “yes/no exists and not planned for removal in existing APIs” way of splitting things up, then I’d like to revist```

torgo

we agreed to merge on today's taskforce call

@torgo

Per @torgo's above comment.

…han ancillary data. (#361) SHA: 1dd68c8 Reason: push, by jyasskin Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

jyasskin requested review from npdoty, pes10k and yoavweiss October 6, 2023 00:22

yoavweiss reviewed Oct 9, 2023

View reviewed changes

jyasskin commented Oct 9, 2023

View reviewed changes

yoavweiss reviewed Oct 10, 2023

View reviewed changes

npdoty previously requested changes Oct 11, 2023

View reviewed changes

jyasskin added 5 commits November 8, 2023 14:26

Rewrite ancillary uses to focus on 2 kinds of ancillary APIs rather t…

c627263

…han ancillary data.

De-duplicate an id.

6e3bfbe

Avoid "first group", and name it instead.

8a9efbb

Add time-shifting.

f6fac98

Address some code review comments.

c7ef27f

jyasskin force-pushed the rewrite-ancillary-uses branch from 490587e to f6fac98 Compare November 10, 2023 01:15

jyasskin commented Nov 15, 2023

View reviewed changes

index.html Outdated Show resolved Hide resolved

jyasskin added 2 commits November 15, 2023 09:36

Fix a section link.

ee991e1

Take suggestions from the 2023-11-15 meeting.

b2e5a25

pes10k approved these changes Nov 18, 2023

View reviewed changes

torgo approved these changes Nov 22, 2023

View reviewed changes

jyasskin merged commit 1dd68c8 into w3ctag:main Nov 22, 2023
1 check passed

jyasskin deleted the rewrite-ancillary-uses branch November 22, 2023 17:06

torgo mentioned this pull request Nov 22, 2023

remove list of privacy labor suggestions around ancillary data #221

Closed

	<dt><dfn>Novel ancillary APIs</dfn></dt>
	<dt><dfn>Ancillary APIs that provide new information</dfn></dt>

	available through other APIs, without permission.</span>
	available through other APIs, without an indication that doing so aligns
	with the user's wishes and interests.</span>

Rewrite ancillary uses to focus on 2 kinds of ancillary APIs rather than ancillary data. #361

Rewrite ancillary uses to focus on 2 kinds of ancillary APIs rather than ancillary data. #361

Conversation

jyasskin commented Oct 6, 2023 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyasskin Oct 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

npdoty left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pes10k commented Nov 18, 2023

torgo left a comment

Choose a reason for hiding this comment

jyasskin commented Oct 6, 2023 •

edited by pr-preview bot

Loading

jyasskin Oct 9, 2023 •

edited

Loading