[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).

[pes10k]

Nick says it better than me, like usual. My goal is just to make the expectation clear that we expect specs to solve the privacy issues they introduce, and not just suggest to implementors how implementors might solve them outside of the standardized behavior. If the current text already does that, and Im just misunderstanding the legalese, then thats great and I'm happy to (re)close the issue.

But, at least to a law-school dropout like me, the current text reads (to me) as if its saying spec authors should give implementors suggestions on how implementors could modify or add functoinality outside of the standardized behaviors to address the standard's privacy issues

[chrisn]

I have a concern (objection) about the removal of the words "all known" in the current charter template, made in https://github.com/w3c/charter-drafts/pull/415.

The original phrasing, which I would prefer to continue use, was:

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.

As I describe in the PATCG charter issue where this change was proposed, I believe that this is a step in the wrong direction, I don't believe the concern of disruption to WGs through "weaponisation" of that requirement to be well founded, and we shouldn't be loosening the requirements on WGs to document privacy considerations, even with strong horizontal review in place, as we have.