The mission of the Privacy Community Group is to incubate privacy-focused web standards 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.
The Community Group will discuss proposals 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.
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 perform horizontal review for privacy at W3C; that is the responsibility of the Privacy Interest Group (PING).
The Chairs of the Privacy Community Group are:
There can be at most three Chairs.
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).
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):
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 was Dominique Hazaël-Massieux.
The Chairs may add Deliverables, but must not add Deliverables which lack the support of at least two implementers.
The Chairs may remove Deliverables.
This document will be updated to reflect the current set of Deliverables of the Community Group.
| Name | Editors | Destination (expected) |
|---|---|---|
| Storage Access API | John Wilander | HTML |
None.
This group will collaborate with appropriate groups at W3C, WHATWG, Ecma, IETF, and elsewhere, and will transition spec proposals 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.
Only privacy-related WICG work items which have the support of at least two implementers are eligible for this group to take up as Deliverables.
The group operates under the Community 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, the Community Contributor License Agreement (CLA), or the Final Specification Agreement are void.
All work and communication within this group is covered by the W3C Code of Ethics and Professional Conduct.
Contributions to Deliverables can only be made by Community Group Participants who have agreed to the W3C 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 the Community and Business Group Process and the particular needs of a group focused on privacy.
The Chairs appoint one or more Editors per Deliverable. Editors are responsible for the technical content of the Deliverable and have sole authority to modify the Deliverable (though their decisions may be overridden by the Chairs; 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 Deliverables without further review, provided they adhere to the requirements in this document.
The group will conduct all of 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.
Any change that represents a feature addition must have the support of at least two implementers.
For any change that removes a feature, the feature being removed must either be not widely implemented, or must be in the process of being removed from implementations.
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 be archived for public review.
Conclusions reached in meetings are tentative; see the Decision Policy.
Editors must respond to substantive issues raised on their Deliverable 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 have multi-implementer support.
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.
If a Community Group Participant believes the Editors’ choice will not have multi-implementer support, and they cannot convince the Editors, then they may appeal to the Chairs. The Chairs may correct or uphold the decision based on their own understanding of support from implementers.
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.
Implementation disagreement should not result in implementation-defined behavior or optional features.
Specifications should not make references to or rely on specific browser engine implementation details.
Community Group Participants may raise substantive issues for resolution by the Chairs.
To raise an issue on a Deliverable for review by the Editors and other Community Group Participants, a Community Group Participant must:
If the Community Group Participant finds those efforts unsatisfactory, they may:
The Chairs then make their determination at their sole discretion.
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 Deliverable.
Deliverables of this Community Group will use the W3C Software and Document License, unless the Editors expect the Deliverable 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 Deliverable expected to end up as a pull request on the HTML Living Standard could be licensed under the Creative Commons Attribution 4.0 International License.
This Charter may be amended at any time by unanimous consent of the Chairs. The Chairs will periodically update this Charter to reflect the addition and removal of Deliverables, Editors, and Chairs.
Per the Community and Business Group Process, the Chairs must notify Community Group Participants of any material changes to the Charter.
This Community Group uses the WHATWG definition 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.”
The WHATWG defines implementer as "an entity that develops one of the core end-to-end integrated web browser platform engines and distributes its integrated implementations widely." This definition is useful for determining multi-implementer support of core web platform features, features which are typically and reasonably implemented within the core end-to-end integrated web browser platform engines, and this Community Group relies on this definition for such features.
Some privacy-related features ship in browsers but are not implemented within browser engines. In cases where multiple entities share a browser engine in common, they only count as multiple implementers of a feature if that feature’s implementations are separate and are not believed to be specific to the internals of the engine.
The Peach Foundation ships Walkabout, a web browser built on the MeshTools browser engine. Nanoware also ships a web browser, Vertex, built on the Shrug browser engine. If a feature has the support in both MeshTools and Shrug, as shipping (or as is expected to ship) in Walkabout and Vertex, it can be said to have multi-implementer support.
Valiant Inc. ships Valiant, a web browser built on the Shrug browser engine. The Avogadro Corporation ships a web browser, Veneer, also built on the Shrug browser engine. A feature implemented in Shrug counts as having one implementer supporting it, even if that feature ships in both Valiant and Veneer.
Valiant and Vertex both ship a feature, but it is not a feature with a shared, underlying implementation in the Shrug engine. Such a feature counts as having two implementers supporting it, even though Valiant and Vertex are both built on Shrug, because this particular feature has seperate, non-shared implementations.
Valiant and Vertex (who, again, share an engine) both express implementer interest in a feature that does not yet have any implementations. If both implementers indicate that they do not expect to share an implementation (they do not expect to land their implementations in Shrug), the feature counts as having two implementers supporting it. If both implementers expect they’d share an implementation in Shrug, it counts as having one implementer supporting it.