privacycg/privacycg.github.io

Website and charter of the Privacy Community Group

privacycg.github.io's Issues

License

I would like to "borrow" some of the content of this repository. What license governs this work?

“Implementer” definition unreasonably favors some participants and redefines consensus

I have significant concerns that this operational agreement seems to redefine "consensus" as a very specific version of implementer agreement, and explicitly favors some browser vendors. This definition counter-intuitively seems to devalue consensus among browser-shippers who use the same engine; any browser companies who use the same engine may count as a separate implementer for one vote of support, but if multiple browsers using the same engine agree on a feature that would be implemented in that engine (and presumably would share code in that engine, whether it's shared with others or not), then only one implementer would count (because the other is “just shipping someone else's code”, I guess?). In short, the opinion of a "browser vendor" (which in this context, I would define as an entity that is knowingly making privacy decisions on behalf of its users) gets devalued, simply because they agree with another "browser vendor" who happens to share code.

I've thought through many of my concerns about this charter, and believe they largely track back to this devaluation. It certainly makes sense to prioritize the CG's focus on proposals that multiple entities-that-make-privacy-decisions-for-their-users support; I support the desire to focus the group's time and energy on proposals that can garner cross-industry, multi-vendor support. However, using as a gating factor that multiple independent code authors have to be signed up seems wildly misplaced.

As a real-world example, let's presume Brave, Samsung, Edge, and Chrome all supported a particular privacy-supporting API and thought it would be useful. Obviously, if that code can be shared in Blink, they would all prefer not to have multiple implementations. Despite having an obviously cross-vendor support, that would not pass the bar defined here, unless either Apple or Mozilla agreed to support the API as well. In fact, for any feature, you would really need to have support from two of: 1) Apple 2) Mozilla 3) any Chromium browser/committer. However, one of your statements of support MUST be Apple or Mozilla. (Obviously, if there were Webkit or Gecko engine browsers in the CG that weren’t Apple/Mozilla, this might be different. I don't think there are, but may be mistaken.)

In my opinion, this violates a constraint on Community Group Operational Agreements - per https://www.w3.org/community/about/agreements/#cgroups, CGs “must not unreasonably favor or discriminate against any group participant or their employer.”

Additionally, this leads back to a high-level concern: any decisions made in incubation are still subject to change when migrated to a standards-track effort, and having an explicitly different version of "consensus" is more likely to cause disagreements and objections at that migration transition. (It's possible this would be less so if transitioning to the WHATWG, although as this operational agreement notes the WHATWG doesn't define "implementer" this way today.) . Of course, even using any browser vendor support is not entirely compatible with the W3C's Process and voting mechanism, but at least it would be closer and more inclusive of positive support from different organizations.

Personally, I don't think this support bar needed to be explicit; the chairs can evaluate support, and clearly multiple entities supporting a proposal should move that along. However, if you want a more explicit version, in order to resolve this issue I believe the definition of “implementer” should essentially be that of a “browser vendor” - that is, support counts if it is expressed explicitly by separate browser vendors (i.e. Blink doesn’t get multiple “votes” just because they ship an engine that Brave, et al use; but if Brave expresses explicit support for a feature that Google explicitly supports as well, that meets the bar). You might wish to make it explicit that multiple browsers shipped by one company cannot be counted separately (e.g. Firefox and Firefox Reality don’t count twice).

Drop Melanie from the list of isLoggedIn editors.

See privacycg/is-logged-in#48

Chair powers and process

There is a lot of bespoke process defined in this charter.

Regardless, it's unclear to me why there's so much process defined here for a CG. Anything in this charter is editable by the chairs at will - there is no process around it, on purpose. If you want to define this kind of process, we should really be editing the Process docs in the Process CG, so that it is consistent across CGs. If you're just concerned about having a fair, consensus-based process in the Privacy area, we should be ramping up a WG (which would have a consistent Process). There are some oddities exposed here, otherwise - for example, Chairs in this privacy CG can decide to remove deliverables unilaterally, something that Chairs in a WG typically cannot do.

Charter should more clearly distinguish between Proposals and Work Items

It's clear that this can still be confusing. Some notes on this from #5:

@jyasskin wrote:

Is there a concrete difference between how the CG will interact with a Proposal vs a Work Item? It looks like a sufficiently complex proposal can get a repository before multiple engines have expressed interest, and the CG discusses them similarly.

Would it shorten or simplify the charter to say that everything's a Proposal, and the chairs will keep a list of proposals for which 2 engines have expressed interest?

@travisleithead replied:

The major difference seems to be around the allocation of [potentially scarce] Editors, which are appointed by the chairs (do these editors have to be members of the CG?) to advance the work item. The Editors then takeover much of the responsibility of "directing the work" until they judge its ready to advance beyond the CG. Did I get that right?

What does this mean for proposals that have a highly-engaged and willing "owner"/"creator"? If the chairs do not want to see the proposal advance (or the proposal doesn't meet the implementer criteria), I'm not sure they could do much to stop a pro-active proposal owner (not an officially minted editor) from carrying on. It seems the purpose of promotion to Work Item then is to lend a helping hand to good proposals with less-active owners and get them moving even faster in the process. Might be worth calling out the rationale a bit more.

I replied:

Hmm. The intent is that the output of the proposal phase is an explainer, and the output of the work item phase is a revised explainer and a draft spec. This is spelled out in the proposals repo https://github.com/privacycg/proposals but not in the charter. I'll try to figure out how to incorporate that here. Thanks!

More clearly link to the w3c community group page for this CG

Currently the only link to the CG page from this page is the "join" link. I think it would be better to have a clear link so people can go to that pae and find out who's in the group, etc...

Document pre-deliverable proposal and incubation work mode in charter

The intended lifecycle of a proposal in our CG is described in our proposals repository. Broadly, our work is done in two phases:

1. The proposal phase, AKA incubation. This is an extremely lightweight, WICG-style process. Anyone in the group can make proposals at any time. Incubation produces & iterates on explainers. Successful incubation results in a deliverable. (Moving to the deliverable phase requires multi-implementer interest; this is because the CG is committed to a multi-stakeholder, multi-engine web.)
2. The deliverable phase, AKA specification. This is an efficient, WHATWG-like process, during which we iterate on explainers and specifications simultaneously. Successful specification results in migration of the work to a standards-track Working Group or to the equivalent in other standards bodies.

Our charter predominantly describes how we work on deliverables, and when we migrate things elsewhere, but does not say much about how we work on proposals that have not yet become deliverables. That phase is currently only laid out in our proposals repository.

This can leave readers of our charter (e.g. AC reps considering a join request) unaware of our enthusiasm for new proposals and the WICG-like process we have in place for working on them. Worse, readers may think we aren't a venue interested in or equipped for early-stage incubation.

We may want to document the earlier phase in our charter (hence this issue). Alternately, we could raise visibility of this aspect of things in some other way, via an FAQ on the website or some such.

broken link in charter

from @TanviHacks:

This link doesn't seem to work anymore - https://privacycg.github.io/out-of-scope

Ah, its just the charter text links to the wrong thing. should link to https://privacycg.github.io/charter.html#out-of-scope

Work Mode doesn't currently provide for private disclosure of privacy vulnerabilities in our work

Our charter's work mode section states (emphasis mine):

The group will conduct all of its technical work in public.

Given that at least one browser engine "treats circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities" (source), should we have a mechanism in place for private disclosure of privacy vulnerabilities in our work?

Why the limit of three chairs?

"There can be at most three Chairs." seems like a curious limitation for no particular purpose, and should be struck. If the group wants more chairs, they should add them; if they don't, they shouldn't. For example, WICG currently has four chairs, and could probably work quite well with more.

Implementation-defined and optional features

The line “Implementation disagreement should not result in implementation-defined behavior or optional features.” shouldn't appear in a charter. It's a good goal for API design, other things equal, but it's not appropriate for a charter to presuppose answers to API design questions. It's especially inappropriate at the incubation phase where

1. having different implementations test different variations of the same API is likely to help us gather the feedback needed to define the best API, and
2. the API will be released from this constraint when it moves to a working group that isn't covered by this charter restriction.

Some examples of APIs where this restriction would have been a bad idea:

• Geolocation, where the design of the permission dialog is implementation-defined, and where that design has improved over time as implementations were allowed to experiment on it.
• one-time-code where actually filling the code in from SMS is optional.

Privacy Community Group charter should focus on incubation

The Privacy Community Group charter in the Mission, Scope, and other sections, should explicitly mention incubation, and drop & avoid language which implies working-group-like standards development.

Instead, the Coordination should explicitly list where incubations are intended to graduate to, separately from groups expected to coordinate with as relevant.

Also the Process section should also describe exit conditions for an incubation, for how / whether a proposal should be abandoned/dropped from the group, or how a proposal should complete incubation and considerations for how to choose which Working Group it should graduate to.

Some specifics: in the Mission section up front it says “to develop privacy-focused web standards and APIs”. That should for example be changed to say incubate, e.g. “to incubate privacy-focused web standards and APIs”.

In issue #2, there is mention of “2. The deliverable phase, AKA specification.” This should be dropped from the CG charter, as when the incubation phase has completed for a proposal, the next step should be to transition it to a working group.

Label: charter.

(Originally published at: https://tantek.com/2020/030/b1/privacy-community-group-charter-focus)