- From: Daniel Glazman <daniel@privowny.com>
- Date: Tue, 24 Sep 2019 06:43:18 +0200
- To: Samuel Weiler <weiler@w3.org>
- Cc: public-new-work@w3.org, "public-privacy (W3C mailing list)" <public-privacy@w3.org>, Jeff Jaffe <jeff@w3.org>, Chris Wilson <cwilso@google.com>
> Le 23 sept. 2019 à 21:10, Samuel Weiler <weiler@w3.org> a écrit : > > We are primarily concerned that the PING is attempting to insert > itself as a required step for all specifications as per > (https://github.com/w3cping/administrivia/blob/process-changes-2019q3/README.md#privacy-review) > without first > focusing on creating a well-developed formal model that can give > actionable advice for developers to assess the privacy risks of > their features. Although we certainly believe effective and > constructive review guidance is > essential, only focusing on anti-patterns is not by itself a > solution. We'd like to see the PING focus on guidance for what a > true privacy-preserving browser might look like based on a > high-quality model of platform surface area - e.g. > removing hardware, screen resolution, and CPU distinguishers to the > greatest extent possible, outlining network-level analysis and the > inability to provide privacy from network actors without > network-channel-noise creation, and > discussing the role of powerful features, 3ps, and various page > construction techniques that need to be defeated for true privacy > preservation. > > Simply establishing themselves as an authoritarian review group > without formally establishing self-serve guiding principles will > cause significant unnecessary chaos in the development of the web > platform. Although we would like the PING to > take a strong role in horizontal review, we are uncomfortable > investing it with Process authority without more experience. > > Additionally, we find the 3+ year charter time frame for the > PING group to be excessive, as this is a significantly different > charter than it has been previously. We would like to suggest that > the charter end date be moved up to 31 > December 2021. Hi there, I'm cc:ing Jeff because that could become an interesting topic for the AB. I tend to agree with Google that this prose is questionable but absolutely not for the same reason... Let me explain: publication of draft specifications trigger requests for comments sent to the whole Membership and even the general public. Including Groups. And of course, comments can in fact come at any time and major comments will have to be addressed anyway, in particular if they reflect Privacy concerns. Even if the PING is not listed as a mandatory Liaison in a given WG Charter and/or about a given specification, even if the PING is not established by Process or its own Charter as a mandatory horizontal review authority, it can always review any draft or candidate spec at any time. A negative and motivated review from this Group would certainly not have the force of a formal objection but I very highly doubt a spec would be able to go over such a negative review. Imagine the reaction of the public to a press article entitled "W3C publishes a new Standard that raises privacy concerns from its own Privacy Group", ahem. In fact, the only good reason why the Privacy Review section of [1] is probably wrong is "because it's a IG and not a WG". I'm not sure a IG should be a horizontal review authority. So in practice, all Groups already have a very powerful review power, that should render better in the Process. I cc:ed Jeff because I think formal objections should be extended, in Process Section 3.3.2, to Working Groups, based on a consensual decision or even vote (hey, we would finally use votes in WGs, isn't that cool?). Only "individual(s) may register a Formal Objection to a decision" for the time being. Last but not least: on another hand, I like "long charter periods". Rechartering has a huge cost for Groups, the Staff, the Chairs, and the Members' legal authorities. It has an negative impact on the serenity of Groups, and then on their work. [1] https://github.com/w3cping/administrivia/blob/process-changes-2019q3/README.md </Daniel>
Received on Tuesday, 24 September 2019 04:50:38 UTC