Privacy Community Group Charter (original) (raw)

Mission

The mission of the Privacy Community Group, motivated by theW3C TAG Ethical Web Principles, is to incubate privacy-focused web features and APIs to improve user privacy on the web through enhanced browser behavior.

The group welcomes participation from browser vendors, privacy advocates, web application developers, and other interested parties.

Scope

The Community Group will discuss ideas for new privacy-focused web platform features intended to be implemented in browsers or similar user agents. The group will also discuss potential modifications of existing web platform features aimed at improving user privacy on the web.

Out of Scope

Features or ideas that don’t pertain to privacy and have applicability in a browser (or similar user agent) should be proposed elsewhere.

This group does not performhorizontal review for privacy at W3C; that is the responsibility of thePrivacy Interest Group (PING).

Chairs

The Chairs of the Privacy Community Group are:

The Chairs are responsible for the day-to-day running of the group, including:

The Chairs have a number of other powers and responsibilities which are defined throughout this document.

No two Chairs can be from the same organization.

Except where otherwise specified, all decisions made by the Chairs are expected to be made by consensus. If consensus cannot be found among the Chairs, and unanimity is not otherwise required, the Chairs may make decisions by supermajority (at least 2/3rds support).

Announcements

When the Chairs are required to notify the group of something, they will raise an issue in theprivacycg/adminrepository labeledannouncement, and will ensure the topic is covered at the next meeting.

Chair Selection

Within the above constraints, additional Chairs may be appointed by unanimous consent of the then-current Chairs.

If the number of Chairs becomes zero, or if five Community Group Participants—no two from the same organization—call for an election, the group must use the following process to elect a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777):

  1. Participants announce their candidacies. Participants have 14 days to announce their candidacies. No two candidates can be from the same organization. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. (In the unlikely event that there are no candidates and the number of current Chairs is zero, Community Group Participants should ask the Community Development Lead for guidance on how to proceed.)
  2. Participants vote. Multiple Participants from the same organization collectively share one vote. Participants have 21 days to vote for a single candidate. In case of a tie,RFC 2777 is used to break the tie.

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.

The Community Development Lead is a member of W3C staff chosen by W3C leadership to manage the Community Groups program. As of the drafting of this charter, the Community Development Lead wasDominique Hazaël-Massieux.

Proposals

A Proposal is an idea brought to the Community Group for consideration and potential adoption as a Work Item.

Each Proposal has one or more Champions, beginning with the Community Group Participant who proposed it. Champions are self-organized. Proposals should explicitly list their Champions, and Champions should keep this list updated as the set of Champions for the Proposal changes.

Any Community Group Participant may make a Proposal by filingan issue in theprivacycg/proposalsrepository on GitHub, stating the problem they would like to address and how they propose to address it.

The Community Group may discuss the Proposal on GitHub and during teleconferences or face-to-face meetings.

Champions are responsible for the technical content of their Proposal. They are expected to solicit input from Community Group Participants, and they may consider and respond to comments, suggestions, and objections on their Proposal from Participants and the public.

Champions may ask the Chairs to create a dedicated repository for their Proposal. The Chairs will generally honor such requests, though they may choose not to (if, for example, they believe the Proposal to be out of scope).

Proposals begin as or evolve intoexplainers which describe a user-facing problem which needs to be solved and how the authors propose to solve it. Explainers are Community Group Reports as defined in theCommunity and Business Group Process, but they are not Specifications as defined in that document.

Proposals may be withdrawn by their Champions, or may be closed by the Chairs (if, for example, the Chairs deem the Proposal to be out of scope, or if its number of Champions drops to zero). If such a Proposal has a dedicated repository, the Chairs and Champions should take steps to ensure the data is not lost, perhaps by archiving the repository or by transferring it to a different organization or user.

Work Items

This Community Group may produce Work Items—a special kind of Community Group Report whose purpose is to work toward interoperability between independent implementations of the features it defines. Work Items are Specifications as defined in theCommunity and Business Group Process. Each Work Item has one or more Editors, who are appointed by the Chairs.

The current set of Work Items of the Community Group are:

Name Editors Expected Destinations
Client-Side Storage Partitioning Anne van Kesteren Various
Cookies Having Independent Partitioned State Dylan Cutler &Aaron Selya IETF
The Login Status API John Wilander WebAppSec
Private Click Measurement John Wilander HTML
Storage Access API Benjamin VanderSloot,Johann Hofmann,Anne van Kesteren HTML &Storage standards
Navigational-Tracking Mitigations Ben Kelly,Pete Snyder,Jeffrey Yasskin Fetch &HTML standards

This list will be kept updated by the Chairs to reflect the current set of Work Items of the Community Group.

The Community Group may adopt a Proposal as a Work Item if it is the consensus of its Champions and the Chairs that such a Work Item would be likely to enable and lead to independent, interoperable implementations. The Chairs and Champions may solicit commitments from organizations to provideadequate implementation experience of the Proposal's features, and may take such commitments or other such expressions of implementer interest into account when making their decision.

Each Work Item should be accompanied by an explainer describing its proposed changes to the web platform. Editors should keep the Work Item's explainer up-to-date with the Work Item as it evolves.

Because Work Items begin life as Proposals, they typically start out with an explainer already written, and Proposal Champions are typically appointed Editors.

When a Work Item's Editors deem the Work Item ready for migration, they will notify the Chairs. The CG may produce a Final Community Group Report at this time. The Editors and Chairs will identify the best destination standards body or bodies, and will then work with those bodies to successfully migrate the Work Item.

When migrated to the standards track, Work Items might become standalone specifications, they might be integrated into one or more existing specifications, or they might result in a combination of these options.

The Chairs may remove Work Items. The Chairs must notify the group of the removal of Work Items, and this notice must include rationale. Some possible reasons for removing a Work Item are:

The Chairs should take steps to ensure the repositories of removed Work Items are not lost, perhaps by archiving the repository or by transferring it to a different organization or user.

Coordination

This group will collaborate with appropriate groups atW3C,WHATWG,Ecma,IETF, and elsewhere, and will migrate Work Items to them when they’re ready for the standards track. Groups most likely to be close partners are listed below, but this group is expected to coordinate with other groups as relevant.

W3C Groups

Privacy Interest Group (PING)

This group will coordinate with PING and will take into consideration outputs of PING when evaluating Proposals and Work Items.

Web Application Security Working Group (WebAppSec)

WebAppSec is expected to be a destination for transitioning Work Items to the standards track.

Web Platform Incubator Community Group (WICG)

WICG is expected to be a major source of Proposals for this group.

External Organizations

Web Hypertext Application Technology Working Group (WHATWG)

Many of our Work Items will likely result in pull requests on various WHATWG specs.

Process

The group operates under theCommunity and Business Group Process. This Charter is the sole operational agreement of the Community Group. Terms in this Charter that conflict with those of the Community and Business Group Process, theCommunity Contributor License Agreement (CLA), or theFinal Specification Agreement are void.

All work and communication within this group is covered by theW3C Code of Ethics and Professional Conduct.

Contributions to Proposalsand Work Items can only be made by Community Group Participants who have agreed to theW3C Community Contributor License Agreement (CLA).

This group’s process, asynchronous work mode, and efficient decision policy are based on those of the WHATWG. These policies have been adapted to fit both the requirements of theCommunity and Business Group Process and the particular needs of a group focused on privacy.

Editors

Editors are responsible for the technical content of their Work Item and have sole authority to modify the Work Item (though their decisions may be overridden by theChairs; see below).

Editors are responsible for

Changes of an editorial nature can be made, accepted, or rejected by editors without discussion.

Editors may solicit input from Community Group Participants, and may consider and respond to comments, suggestions, and objections from Participants and the public.

Editors may commit changes to their Work Items without further review, provided they adhere to the requirements in this document.

Work Mode

The group generally conducts its technical work in public.

Community Group participants agree to make all contributions in the GitHub repository the group is using for the particular document. This might be in the form of a pull request, by raising an issue, or by adding a comment to an existing issue or pull request.

This group practices responsible disclosure of security and privacy vulnerabilities in our work. The Chairs will ensure that instructions for reporting security or privacy issues areposted on GitHub and kept up-to-date.

Meetings

The Community Group may hold teleconferences and face-to-face meetings. The Chairs will determine the schedule, logistics, and agenda of each, in consultation with Editors and Community Group Participants. Minutes from teleconference and face-to-face meetings will bearchived for public review.

Conclusions reached in meetings are tentative; see the Decision Policy.

Decision Policy

Editors must respond to substantive issues raised on their Work Item by Community Group Participants. Editors have discretion to resolve issues based on available information.

To afford asynchronous decisions and organizational deliberation, any conclusions reached in a face-to-face meeting or teleconference are tentative, and will be recorded in the relevant issues, pull requests, or repositories for consideration by Community Group Participants. Any Community Group Participant may object to a decision reached at a face-to-face meeting or teleconference within 14 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs and Editors will facilitate discussion to try to resolve the objection.

In case of a conflict among Community Group Participants, Editors are expected to go to significant lengths to resolve disagreements. In the end, they make a judgment call to pick the best option they believe will preserve privacy and lead to independent, interoperable implementations.

If a Community Group Participant is not satisfied with the resolution of an issue, they may request that the Editors revisit the issue. If not satisfied with the Editors’ final response, Community Group Participants may appeal to the Chairs. The Chairs may correct or uphold the decision based on their own understanding of what will best preserve privacy and lead to independent, interoperable implementations.

It is the Chairs’ responsibility to ensure that the decision process is fair and does not unreasonably favor or discriminate against any Community Group Participant or organization.

The Chairs may override Editors’ decisions, or remove Editors.

Implementations can always override the editors by implementing something else. Whenever that happens a breakdown in communication has taken place that the Community Group should seek to overcome and find ways to prevent it from happening again.

When implementations disagree, the Editors will try to find a solution that is privacy-preserving and mutually acceptable to implementers. If no such solution is identified, the Editors will research expectations of existing web content and specify the most privacy-preserving, web-compatible approach. If there isn’t enough existing web content affected by the change to make compatibility a concern, the Editors will, to the extent possible, be consistent with our goal to increase user privacy and align with implementer majority.

Work Items should not make references to or rely on specific browser engine implementation details.

Appeals

Community Group Participants may raise substantive issues for resolution by the Chairs.

To raise an issue on a Work Item for review by the Editors and other Community Group Participants, a Community Group Participant must:

  1. Identify the issue clearly (technical problem, interoperability issue, inconsistency with theW3C TAG Ethical Web Principles, etc.) and recommend a solution;
  2. Post the issue for review in the Work Item’s repository; and
  3. Endeavor to resolve the issue with the Editors or in concert with other Community Group Participants.

If the Community Group Participant finds those efforts unsatisfactory, they may:

  1. Summarize the issue and the efforts to resolve it, and forward the summary and any supporting details to the Chairs, with a copy to the Community Group.
  2. The Chairs may then invite the Editors and other Community Group Participants to comment, may request additional materials, schedule a meeting, or take other actions for its review.

The Chairs then make their determination at their sole discretion.

Patent Policy

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization’s legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a group Work Item.

Licensing

Work Items of this Community Group will use theW3C Software and Document License, unless the Editors expect the Work Item to transition to a standards body which uses a different license. In such cases, the Editors may use the license of the target standards body.

A Work Item expected to end up as a pull request on theHTML Living Standard could be licensed under theCreative Commons Attribution 4.0 International License.

Amendments to this Charter

This Charter may be amended at any time by unanimous consent of theChairs. The Chairs will periodically update this Charter to reflect the addition and removal of Work Items, Editors, and Chairs.

Per theCommunity and Business Group Process, the Chairs must notify the group of any material changes to the Charter.

Glossary

consensus

This Community Group uses the WHATWGdefinition of consensus: “the parties concur. Consensus may be established tacitly. By way of example, so long as (1) proposed actions are clear and visible, (2) participants have opportunities to voice concerns, and (3) there is no sustained, substantive opposition, then Consensus may be established simply by moving forward on the proposal or a course of action; this is anticipated to be the norm for most matters.”

About this Charter