The mission of the Private Advertising Technology Community Group, motivated by the W3C TAG Ethical Web Principles, is to incubate web features and APIs that support advertising while acting in the interests of users, in particular providing strong privacy assurances.
The group welcomes participation from browser vendors, advertisers, publishers, ad buyers, advertising platforms and intermediaries, privacy advocates, web application developers, and other interested parties.
The Community Group will incubate new web platform features intended to be implemented in browsers or similar user agents. The purpose of these features is to support web advertising and provide users with privacy guarantees with a strong technical basis.
The Community Group may consider designs that allow user agents for the same user — including non-browser agents, like Operating Systems — to collaborate in providing advertising features.
The Community Group will develop and document a set of common principles by which proposed private advertising features can be assessed, with respect to the Web Platform Design Principles, including the priority of constituencies.
Initially, the Community Group will also develop a charter for a Working Group with similar scope. This working group shall provide a venue for formal standardization of work that this Community Group incubates.
Features that support advertising but provide privacy by means that are primarily non-technical should be proposed elsewhere.
The primary artifacts of the Community Group will be technical specifications of capabilities that support advertising while implementing the web platform's responsibility to act in the interests of users, including preserving privacy. These technical specifications will be developed in preparation for standardization in other groups.
The Community Group will also develop the initial Privacy Advertising Technology WG charter and a document for Privacy Principles for Web Advertising Features.
The Community Group will record their consensus in documents. The Community Group may choose to formally adopt a document with the intent of producing a Community Group Report.
Chairs appoint Editors for adopted documents.
The current work of the Community Group includes the following documents:
| Name | Editors | Expected Outcome |
|---|---|---|
| Private Advertising Technology Working Group Charter | Chairs | WG Formation |
| Privacy Principles for Web Advertising Features | Robin Berjon | Internal CG Use |
| Threat Model | Erik Taubeneck, Charlie Harrison, Martin Thomson, Chris Wood, Mariana Raykova | Internal CG Use |
This list will be kept updated by the Chairs.
Documents for new features will be accompanied by use cases and any additional test data.
The Community Group will seek to develop a shared understanding of new features. In addition to improvements to feature design, the Community Group will seek to gain implementation experience with features through experimentation.
The Community Group is not a standardization body. Once a feature reaches sufficient maturity, the Community Group will seek to find a venue for standardization of the feature. It is expected that migration will occur by the time that features are ready for widespread deployment. Migrating work to a standardization venue will only be done with agreement from that venue.
Work on migrated work will continue exclusively at the chosen venue and Community Group activities on that work will cease. Documents could become standalone specifications in other groups or some contents could be integrated into one or more existing specifications.
Experience with features might lead to Community Group Participants concluding that the work is no longer likely to be successful. Work on adopted features can be discontinued if the Chairs conclude that there is no longer consensus to continue that work.
Repositories and documents related to discontinued work will be modified to make their status clear and may be archived.
Community Group Participants may propose that the Community Group adopt a document. The Chairs then seek to determine whether the document is in scope for the Community Group and if there is consensus amongst Community Group Participants that the work should be taken on and that the document is a good basis for a Community Group Report.
For adoption of documents that include new features, Community Group Participants also need to reach consensus that the features:
The Community Group will adopt a document that records the principles by which features are judged. During development of this document, the principles it contains might not have consensus. The Community Group will seek consensus on principles and clearly distinguish which principles have attained consensus. These advertising-specific principles will be based on or reference work in the Privacy Interest Group (PING) and Technical Architecture Group (TAG) that defines generic principles.
The Community Group prioritizes its time on adopted work.
Chairs may provide resources, such as repositories, for potential new work or work that is related to the mission of the Community Group.
Individuals or entities may bring relevant proposals to PATCG. PATCG will set up and maintain a separate space with name and instructions defined in the proposals repository. Any individual W3C or PATCG member may bring a proposal to that space with the understanding it will be governed by W3C rules and the W3C Community Contributor License Agreement (CLA). The proposal should also have a notice on the `README.md` file at its base or on the document itself which clearly states "This document is an individual draft proposal. It has not been adopted by the Private Advertising Technology Community Group."
The document's author or Chairs may propose that the Community Group consider if a document in the space is potentially in scope. The Chairs then shall determine whether the document is in scope for the Community Group and if so it will be added to a list of relevant proposals for the community group's work in the PATCG proposals repository and create a repository under the individual contribution space. If the chairs determine the proposal is not in scope, its author will be requested to move it to a different venue. Documents which are determined to no longer be potentially in scope may be removed by chairs.
The Community Group may facilitate but will not prioritize meeting time for documents in the draft space.
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 the work of the Community Group can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
The Chairs of the Private Advertising Technology 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.
Within the above constraints, additional Chairs may be appointed by unanimous consent of the then-current Chairs.
Chairs are added by election if the number of Chairs is reduced below two. Alternatively, if five Community Group Participants — no two from the same organization — call for an election, and no election has taken place in the previous three months, then an election is held to select two Chairs in place of all existing chairs.
The group must use the following process to elect Chairs with a goal of increasing the number of Chairs to two. The Community Group shall consult the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 3797):
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.
Chairs appoint Editors to maintain documents. Editors are responsible for the technical content of documents and are responsible for maintaining documents.
Editors are responsible for
Editors are empowered to make decisions based on their own assessment of the consensus of Community Group Participants. Chairs can override Editor decisions on appeal.
Editors have discretion in how they manage updates to documents, provided they adhere to the requirements of this charter.
Editors have discretion regarding editorial aspects of documents. Changes that are purely editorial in nature can be made, accepted, or rejected by editors. Editors are encouraged to seek Community Group input or consensus on changes.
The group generally conducts its 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 are posted on GitHub and kept up-to-date.
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.
Chairs should notify the group for meetings allowing at least one week notice for teleconferences and four weeks notice for face-to-face meetings.
Minutes from teleconference and face-to-face meetings will be archived for public review.
Conclusions reached in meetings are tentative; see the Decision Policy.
Decisions regarding the contents of documents are adjudged by Editors, with oversight by Chairs.
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. Editors will facilitate discussion to try to resolve objections.
In case of a conflict among Community Group Participants, Editors and Chairs are expected to go to significant lengths to resolve disagreements and address legitimate concerns. Seeking consensus is not obligated if the concerns raised are not consistent with this charter or agreed principles.
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.
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 decisions 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.
Features should not make references to or rely on specific browser engine implementation details.
This charter defines consensus as being equivalent to rough consensus as defined in RFC 7282.
Rough consensus does not require unanimous agreement. Using rough consensus recognizes the potential for there to be some disagreement with decisions. Rough consensus prioritizes progress over seeking full agreement, allowing a decision to be reached over objections if those objection are heard, understood, and recognized.
The W3C definition of consensus is consistent with this, but unsuitable for use in a Community Group due to the integration of the Formal Objection process and procedural aspects specific to the operation of W3C Working Groups.
Community Group Participants may raise substantive issues for resolution by the Chairs.
To raise an issue on a decision, a Community Group Participant must:
If the Community Group Participant finds the outcome of their efforts unsatisfactory, they may appeal by summarizing the issue and their efforts to resolve it. An appeal is then sent to the Chairs with any supporting information. Appellants must forward a copy of their appeal to the Community Group by opening the appeal as a GitHub Issue on the Community Group GitHub administrative repository.
Upon receiving an appeal, the Chairs review the request. Chairs may then seek further information or initiate discussion in the Community Group in order to inform their decision.
Chairs should seek to produce a timely resolution to appeals that is based on the consensus of the Community Group. Once resolved, Chairs notify the group of their decision. Chair decisions on appeals are final.
When the Chairs are required to notify the group of something, they are required to provide written communication in the form of an issue on the Community Group GitHub repositories. All issues and pull requests posted to those repositories are automatically sent to the Community Group's mailing list, public-patcg@w3.org, that all members are subscribed to upon joining the Community Group; refer to the PATCG community page for information to join.
Chairs must provide notice at the next available meeting time.
This group will collaborate with appropriate groups at W3C, WHATWG, Ecma, IETF, and elsewhere, and will migrate new features to the appropriate body when there is agreement that the work is ready for standardization. Groups most likely to be close partners are listed below, but this group is expected to coordinate with other groups.
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 the work of the Community Group.
Participants in this Community Group shall follow the W3C Antitrust and Competition Guidance.
Work Items of this Community Group will use the W3C Software and Document License or a license compatible with the standards body that is expected to eventually adopt the work. The W3C Software and Document License will be assumed unless an alternative license is identified.
If a feature includes parts that are expected to end up as a pull request on the HTML Living Standard, that part should be licensed under the Creative Commons Attribution 4.0 International License.
Chairs are responsible for maintenance of this charter.
Chairs must ensure that the published version includes an accurate record of current, adopted documents and the Editors of those documents.
Other amendments to this charter are the responsibility of Chairs, based on the consensus of Community Group Participants.
Chairs must notify the group of any material changes to the Charter, per the Community and Business Group Process.