transparency section

[npdoty]

addresses #263

principles for providing transparency, plain and machine-readable, distinguishable apis

citations to Adding Permissions guide, Unsanctioned Tracking, Fingerprinting

note with links to permissions workshops

---

Preview | Diff

[jyasskin]

This feels vague. Which people? What information is relevant? (That's covered below, but it'd be good if the principle could be read alone.) Should we interrupt people whenever a backend system touches their data?

I think we have a couple goals in this section:

1. People should be made aware of (or be able to find out?) what actors have their data and how those actors use it.
2. The above information should be in a form that allows people to automate their reactions to it.
3. Researchers and regulators should be able to aggregate that information (in privacy-preserving ways) in order to analyze how data is used and abused across society.

Maybe the first one would be covered by:

Suggested change

	[=People=] should be provided relevant information when data is accessed or when permission is
	requested.
	[=People=] should be able to find out which [=actors=] have their data and how they're using it.

On the permissions point, maybe there's something more general about UAs needing to inform users when they give out information about the user, which pushes for designing web APIs that avoid passive fingerprintability and that provide an opportunity to ask the user's permission before disclosing the information.

[npdoty]

This text is broad (perhaps still too broad) in part because the intent is to go beyond discoverability about who has data about you, though that is good to call out separately as well.

Sites need to provide, and UAs may need to help present or consume, relevant information about data collection and use when collection is happening. Permissions is a special case of that where the APIs are easier to reason about, but sites also collect data in the course of navigation and in using HTML functionality (forms, etc.).

[jyasskin]

What does it mean for transparency to be contextual?

[npdoty]

Made it clear that it's the information that would be contextual, and instead described it as presenting the information in the relevant context (since context is a defined term). But this could still be clarified. And it may not be necessary for this document, even if it seems like generally good advice.

[jyasskin]

I think this is a special case of the principles above that data use should be machine-readable? We should probably say that. Should this mention [=recognizing=] people?

[npdoty]

If "recognizing" is our preferred defined term, that could just replace "tracking or identifying".

Machine-readable seems distinct to me from mechanisms that are detectable or visible in their operation. Machine-readable is explicit information marked up to provide semantics, while detectable/visible/distinguishable is just about API usage that can be analyzed.

[npdoty]

Changed the terminology here in recent commit. But I'm still describing this distinctly from machine-readable (for the reasons above).

[npdoty]

In a few cases here, the text uses passive voice, which was helpful in that it was broad, but reviewers point out that its vague.

I think what we typically mean is: sites should provide, and user agents should help present and consume, information to people

But there are some cases where it might go beyond that typical case. A user agent might collect or share information and should itself provide transparency. Other actors may collect or share information outside of the site-browser interaction. Should we exclude these from the scope of the document? Or just talk about the typical case at the top, and then add a sentence or two about other cases where different actors need to cooperate in providing transparency?

[npdoty]

Maybe "actors who are processing data (typically, sites) should provide, and user agents should help present and consume,"

[jyasskin]

I'm not sure exactly how to best fix this, but I stumbled over the pairing of "its use" with both "accessing data" and "requesting permission". We could make it "requesting permission to access data". Or "information about the site's plans" if the permission might also be about things like storing data. Or I'm not sure that "requesting permission" belongs here, since transparency is about what the sites do with the thing they got permission for.

[npdoty]

Tried to clarify this in recent commit, "with relevant explanatory information about the use of data".

[jyasskin]

The first two sentences in this paragraph don't seem to have much to do with each other.

[npdoty]

Relevant explanatory information is an example of providing the transparency necessary for consent.

[jyasskin]

Here we have two different meanings of "information" in the same sentence. First the information/explanation that needs to be given to a user, and second the information whose use the user is being informed about.

Would it help to call this a "helpful explanation" instead of "relevant information"?

[npdoty]

Agree that this was ambiguous over "information". Thinking about phrasing, but "relevant explanation", "explanatory text", something like that.

[npdoty]

Tried to disambiguate by talking about "relevant explanatory information" (and "explanatory information") and then "data" to describe the personal data that might be accessed. I think that also better aligns with the rest of the document.

[jyasskin]

It's not completely clear whether the "information" that must be provided in context is 1) the information that gets accessed or 2) the "relevant information" that helps users make informed choices. Contexts are used in the rest of the document to provide principles about information use, which leans toward the first interpretation, but I think you mean the second.

[npdoty]

Clarified with "explanatory information".

[jyasskin]

Browsers have historically shied away from showing a site's explanation of its permission request alongside the permission request, mostly because we can't guarantee that the site is telling the truth and don't want to endorse their claim. I'm worried that this principle is going to argue against that practice.

[npdoty]

Help in presenting and consuming information doesn't require any particular UI about permissions requests. I think we're agreed that this wouldn't prohibit any current browser vendor preference about UI.

(Although, also, yes, browsers should change their practices to improve visibility of the site's explanation when permissions are being requested, as the current model of providing no context or explanation whatsoever has proved extremely ineffective.)

[jyasskin]

Making the voice more active:

Suggested change

	user, which undermines user control [[?UNSANCTIONED-TRACKING]]. Designing features that minimize
	data and make requests for data explicit can enable detectability, a kind of transparency that is an
	important mitigation for <a>browser fingerprinting</a>.
	user, which undermines user control [[?UNSANCTIONED-TRACKING]]. When web features are designed
	so that sites explicitly request the [[#data-minimization|minimal]] amount of data that they
	need, they make sites' data use "detectable", a kind of transparency that helps
	mitigate <a>browser fingerprinting</a>.

[npdoty]

No strong preference, but the suggestion here seems to convert to passive voice, not active.

[jyasskin]

Suggested change

	their operation is visible and distinguishable, to [=user agents=], researchers and regulators.
	their operation is visible and distinguishable to [=user agents=], researchers, and regulators.

[jyasskin]

We'll merge this once @pes10k and @jyasskin have re-read the text and approved the PR.

[pes10k]

i dont think its accurate that detectability is a mitigation for browser fingerprinting. Its often easy to detect when scripts are fingerprinting a user; but that doesn't mitigate / prevent the fingerprinting from happening

[npdoty]

The Mitigating Browser Fingerprinting doc describes detectability as one mitigation, though clearly not a solution or prevention of fingerprinting altogether. If we want to come up with another word to describe something that can be a useful response to a problem without solving it, I'm open to that, but if so we should (also) file an issue on the fingerprinting-guidance.

[pes10k]

I left one substantive comment, but LGTM, and happy to address that in follow up too

[jyasskin]

We could still improve this section's readability, but that doesn't need to block getting the concepts in.