PROPOSED Private Advertising Technology Working Group Charter

The mission of the Private Advertising Technology Working Group motivated by the W3C TAG Ethical Web Principles, is to specify web features and APIs that support advertising while acting in the interests of users, in particular providing strong privacy assurances. The Working Group welcomes participation from browser vendors, OS vendors, mobile application vendors, advertisers, publishers, ad buyers, advertising platforms and intermediaries, privacy advocates, web application developers, and other interested parties.

Join the Private Web Advertising Working Group.

This proposed charter is available on GitHub. Feel free to raise issues.

Charter Status	See the group status page and detailed change history.
Start date	[dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date	[dd monthname yyyy] (Start date + 2 years)
Chairs	[chair name] (affiliation), [chair name] (affiliation)
Team Contacts	[team contact name] (0.1 FTE)
Meeting Schedule	Teleconferences: We expect to meet every 1-3 months for longer-than-hour blocks, which might be spread over several days Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Scope

The Working Group will specify new web platform features intended to be implemented in browsers or similar user agents. The purpose of these features is to support web advertising without compromising user privacy. Here "privacy" minimally refers to appropriate processing of personal information. Ways in which new features might enable inappropriate processing include (but are not limited to) enabling of cross-site or cross context recognition of users or enabling same-site or same-context recognition of users across the clearing of state.

The Working 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.

Out of Scope

Features that support advertising but provide privacy by means that are primarily non-technical should be proposed elsewhere.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents further in this charter period.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

Private Attribution Measurement: This specification defines how to privately measure advertisement attribution/conversion rates without revealing whether any individual user converts or does not.

The Working Group intends to add other normative specifications as the technology becomes ready. The expectation is that those specifications will be incubated in the PATCG and then, when they are ready for standardization, transition to PATWG. Potential areas include:

Pre-campaign planning
Intra-campaign decisioning and optimization

Interest-based ad or content decisioning
User List Marketing/Remarketing
Fraud detection and prevention
Abuse detection and prevention
Frequency and recency controls
Error reporting and mitigation
Device resource management

Post-campaign reporting and attribution

Other Deliverables

Other non-normative documents may be created such as:

Use case and requirement documents;
Test suite and implementation report for the specification;
Primer or Best Practice documents to support web developers when designing applications.

Timeline

Charter +1 month: First teleconference
+6 months: FPWD for Private Attribution Measurement

Success Criteria

The WG will progress its normative specifications through the following standardization process: First Public Working Draft, Working Draft, Candidate Recommendation Draft, and Candidate Recommendation Snapshot. It is expected that to reach the Candidate Recommendation Snapshot stage, each normative specification is expected to have at least two independent implementations of every feature defined in the specification.

Each normative specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.

There should be testing plans for each specification, starting from the earliest drafts.

Normative specifications which have user-facing features should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review. Additionally, the technologies this Working Group will be considering will be relevant for other standards development organizations such that the group is encouraged to coordinate with the appropriate groups at the WHATWG, Ecma, and IETF as needed.

The WG will coordinate with the Private Advertising Technology Community Group to solicit feedback from a wider community of interest. At any time, but always when a specification is undergoing a state change, the WG will ask the CG for feedback. The WG will allow the CG at least 4 weeks to gather that feedback.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

Private Advertising Technology Community Group (PATCG): This Working Group will work closely with PATCG. The expectation is that PATCG will incubate proposals which it then hands off to this Working Group for standardization. Most proposals in this Working Group should start in PATCG.

Privacy Interest Group (PING): This Working Group will coordinate with PING on the development of principles that will guide the development of advertising capabilities.

Web Application Security Working Group (WebAppSec): WebAppSec is both a potential venue for standardization of security-related capabilities and a source of expertise on web privacy.

Privacy Community Group: The Privacy Community Group is developing privacy-focused features. The PATWG is expected to regularly coordinate with the Privacy CG to ensure that the work of the two groups is not in conflict.

Technical Architecture Group (TAG): The TAG develops general design principles that will guide the work of this Working Group. The TAG might provide input and guidance on specific aspects of the work.

Improving Web Advertising Business Group (Web-Adv): The Improving Web Advertising Business Group includes representation from the potential consumers of these technologies, some of whom are not members

Anti-Fraud Community Group: The Anti-Fraud Community Group is working to identify and define fraud and abuse scenarios, then incubate countermeasures while maintaining security, privacy, and accessibility. Advertising use cases or proposals that are exposed to the potential for fraud might need to integrate with work from this group.

External Organizations

Web Hypertext Application Technology Working Group (WHATWG): WHATWG is a likely venue for standardization of new features. In particular, WHATWG standards include core web platform infrastructure upon which new advertising features could be built.

IETF: A number of IETF working groups are likely venues for standardization of protocol components that advertising features depend on and research groups are investigating issues that will feed into the designs this group will consider.

Participation

To be successful, this Working Group is expected to have 6 or more active participants originating from more than 2 separate parties for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The Working Group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, as participation is limited to Working Group members.

Information about this Working Group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the PATWG Working Group Home Page.

Most Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

At the discretion of the Chairs and subject to a consensus call, the Working Group may designate a Design Team to study a particular subject, and report back to the Working Group their findings and a recommendation. These Design Teams shall consist of a small group of volunteers who commit to investing significant amounts of time on the task over a short, time-bound, period.

This Working Group primarily conducts its technical work in the PATWG GitHub repository, which is configured to send all issues and pull requests to the public mailing list: public-[email-list]@w3.org (archive). The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This Working Group will seek to make decisions through consensus and the documented decision making process of the W3C Process Document (Section 5, Decisions). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the Working Group and other reviewers, and consensus emerges with little formal voting being required.

After discussion in a GitHub issue and other informal discussion, substantive change proposals should be submitted as GitHub pull requests. These can come from the editors or from WG members. Editors are responsible for “curating” the pull requests to reject frivolous ones and substantive ones that the Chairs have determined do not comply with the IPR policies.

Chairs are responsible for determining whether or not there is WG consensus for the changes contained in a pull request. Unanimity is not required, but the Chairs should strive to make consensus decisions where there is significant support and few abstentions.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a Working Group vote and record a decision along with any formal objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the Chair's evaluation of the consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the Working Group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

Anti-Trust

This Working Group operates under the W3C antitrust policy.

About this Charter

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

Charter Period	Start Date	End Date	Changes
Initial Charter	[dd monthname yyyy]	[dd monthname yyyy]	none

Change log

Changes to this document are documented in this section.