[template] Privacy should be mitigated, not just detailed

[plehegar]

Current charter template says:
[[
Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.
]]

It is important to have mitigations as well.

How about:
[[
Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users, as well as recommendations for mitigations.
]]

cc @pes10k @npdoty @sandandsnow

[sandandsnow]

Thank you @plehegar for making this suggested change to the current charter template to incorporate the need to mitigate (not merely detail) security and privacy implications.

[pes10k]

Thank you for opening this @plehegar . I think the wording needs to be a bit stronger, since what we're looking for is not how implementors could fix the privacy issues if they wanted to, but for the proposal itself to fix the privacy issues the proposal would introduce. I suggest the following text instead:

Each specification should contain sections detailing the security and privacy risks that specification authors are aware of and considered when drafting the specification, as well as how those risks are mitigated and addressed within the specification. These sections should also detail security and privacy issues implementers, Web authors, and end users should be aware of when interacting with the specification's functionality.

[sandandsnow]

Thank you @pes10k for more specifically articulating what we would like to see happen as specs are being developed.

[samuelweiler]

While threats should be mitigated, I don't see that as the point of the separate section. The separate section, IMHO, is for analysis, particular of the not-mitigated things.

Mitigations are often architectural - they're usually not stick-on-after-the-fact things that easily fit into a separate section. For example, quoting from https://www.rfc-editor.org/rfc/rfc3552.html#section-5 (re: security considerations):

There should be a clear description of the residual risk to the user
or operator of that protocol after threat mitigation has been
deployed.

[plehegar]

(current conclusion is to adopt @samuelweiler' text)

[samuelweiler]

hmmm. I intended it more as commentary, not as suggested text, but...

[pes10k]

Reopening this bc I dont think the text added here fully addresses the concern. We review specs expecting them to include mitigations the privacy harms the specs would otherwise introduce. We generally would not consider it sufficient for a spec to merely recommend to implementors ways implementors could mitigate privacy harms outside of the spec's defined functionality.

I think the charter template text should reflect this review practice, partially to avoid preventable conflicts during the HR process

[npdoty]

It might be unclear whether "recommendations for mitigations" means:

1. non-normative suggestions to implementers on how to mitigate privacy threats that the specification introduces, or
2. normative mitigations in the specification to address privacy threats.

While it will always be the case that some privacy protections are handled by UA implementations (and indeed we want specs to allow for that), normative mitigations are preferred because they provide both a stronger privacy protection and don't introduce potential interoperability issues (if different implementations choose different ways to mitigate the privacy threat, then sites may unexpectedly see inconsistent behavior, or may start to rely on the non-specified behavior of one implementation).