This Charter is work in progress. To submit feedback, please use https://github.com/antifraudcg/antifraudcg.github.io/issues.
The mission of the Anti Fraud Community Group is to identify and define scenarios involving fraud and abuse, such as unwanted traffic, as well as to incubate and develop web features and APIs to address those scenarios while supporting user security, privacy, and accessibility. Fraud and abuse can include web activity perpetrated by botnets, attackers impersonating users, unwanted traffic, and other activity that intends to deceive and harm users or compromise web services.
The group welcomes participation from anti-abuse service providers, common targets of unwanted traffic, browser vendors, privacy advocates, web application developers, web hosting and cloud service providers, and other interested parties.
The Community Group will discuss issues that server operators (network and web server admins) and anti-fraud service providers face in this area, as well as ideas for new web features, protocols, and APIs intended for and that interface with browsers or similar user agents.
The current definition of abuse is left broad, with the intent that the Charter will be amended in the future once further use case work items are adopted by the Community Group.
The Community Group will discuss and document various forms of fraudulent activity on the web, as well as the properties of such activities that lend themselves to abuse, to establish a foundation for developing web APIs that assist in our mission. The focus is to enable scaled anti-fraud and solutions that are applicable across the ecosystem.
Carve-outs (exceptions to restrictions/limitations) for other web platform work should be brought up in the appropriate group, rather than as part of the Anti-Fraud CG. Features which don't interact at all with the browser (or similar user agent) should be proposed in other standards bodies (IETF, etc).
Meetings will be held biweekly on Friday 12 PM EST/ 9AM PST / 5PM GMT, lasting for one hour. Meetings will be run by one of the Chairs, who will request scribes to take meeting notes that will be made publicly available in the Meetings repository after the meeting. Any action items from the meeting will also be posted to the Community Group mailing list to bring them to the attention of people who did not attend.
Infrequently, face-to-face meetings will be held for the Anti-Fraud Community Group, allowing for more collaboration and iteration between Community Group members.
There are currently no work items that have been adopted by the Community Group. See Proposals for the process of adopting a proposal into the Community Group.
Once a work item is ready for standardization and there is consensus that the work item is ready to be migrated to a standards body, the Chairs will collaborate with the Community Group to prepare a Community Group Report on the item, and work with the Editors to disseminate it to the appropriate standards body.
Proposals that have community group support and result in a deliverable —either as interoperable standards/APIs or documentation— can become CG work items.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
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. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. All technical work will occur in the group's GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked.
Meetings may be restricted to Community Group participants, but a public summary or minutes will be posted to the Meetings repository.
This group will seek to make decisions where there is consensus. Actions/proposals that require consensus should be proposed publicly on the group's mailing list. The chairs should provide ample time for participants to voice concern (7+ days).
If there is no sustained opposition, then an action will proceed. Opposition can be expressed explicitly via the mailing list or to the Chairs.
If there is sustained opposition without changes to the issue, and the proposer still wishes to proceed, the Chairs will hold an approval vote in the Community Group. Each organization will have one vote. This is only to be used as a last resort if consensus can’t be reached and no progress is being made. Generally an approval vote requires simple majority, though amendments to the Charter will require two-thirds majority.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
The Chairs of the Community Group have the following responsibilities. In the case of multiple Chairs, they should ensure that at least one Chair is responsible for each item.
The Community Group can have up to three Chairs, no more than one per organization. Additional Chairs may be appointed by unanimous consent of the then-current Chairs.
If the number of Chairs falls to zero, or if four Community Group Participants — from different organizations — call for an election, the group must use the following process to elect a new Chair, as follows.
Participants announce their candidacies: Participants have 14 days to announce their candidacies. No two candidates can be from the same organization. If there are three or fewer candidates, they become the Chairs. If there are more than three candidates, a vote is held. (If there are no candidates, the Community Development Lead should be consulted for guidance).
Participants vote: Each organization will have a single ballot that can be used to selected any number of candidates, as a form of multiwinner approval voting. The three candidates with the most votes at the conclusion of the vote are appointed chairs. In case of a tie, RFC2777 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 was Dominique Hazaël-Massieux.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The group may make simple corrections and other amendments to the charter by establishing group consensus. The new charter, if approved, takes effect on either the proposed date in the charter itself, or seven days after consensus has been established or the results of the vote have been announced, whichever is later.