/
charter.html
360 lines (358 loc) · 15.2 KB
/
charter.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
<!DOCTYPE html>
<html lang="en">
<head>
<title>
Anti-Fraud Community Group Charter
</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="//www.w3.org/StyleSheets/TR/base">
<style>
body {
max-width: 60em;
margin: auto;
}
*:target {
background-color: yellow;
}
li {
margin-bottom: 9pt;
}
.note {
background-color: yellow;
padding: 10px;
}
.remove {
background-color: yellow;
}
</style>
</head>
<body>
<h1>
Anti-Fraud Community Group Charter
</h1>
<p>
This Charter is work in progress. To submit feedback, please use
<a href="https://github.com/antifraudcg/antifraudcg.github.io/issues">
https://github.com/antifraudcg/antifraudcg.github.io/issues</a>.
</p>
<h2 id="goals">
Goals
</h2>
<p>
The mission of the <a href="https://www.w3.org/community/antifraud/">Anti
Fraud Community Group</a> 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p class=note>
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.
</p>
<h2 id="scope-of-work">
Scope of Work
</h2>
<p>
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.
</p>
<h3 id="out-of-scope">
Out of Scope
</h3>
<p>
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).
</p>
<h2 id="meetings">
Meetings
</h2>
<p>
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 <a href="https://github.com/antifraudcg/meetings">Meetings</a>
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.
</p>
<p>
Infrequently, face-to-face meetings will be held for the Anti-Fraud
Community Group, allowing for more collaboration and iteration between
Community Group members.
</p>
<h2 id="deliverables">
Deliverables
</h2>
<h3 id="work-items">
Current Work Items
</h3>
<p>
There are currently no work items that have been adopted by the Community
Group. See <a href="#proposals">Proposals</a> for the process of adopting
a proposal into the Community Group.
</p>
<p>
Once a work item is ready for standardization and there is
<a href="#decision">consensus</a> 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.
</p>
<h3 id="proposals">
Proposal and Work Item Lifecycle
</h3>
<p>
<ul>
<li>
New Proposal - A document put forward by a group of <b>author(s)</b>
to be considered by the CG. Any participant may submit proposals to
the <a href="https://github.com/antifraudcg/proposals/">proposals
repository</a>. If there is substantial documentation/work, the
proposal authors can ask the Chairs to set up a dedicated repository
for a proposal. Proposals should generally include an Explainer
document describing the changes to the web platform and impact of the
proposal.
</li>
<li>
Closed Proposal - A document that has been withdrawn from
consideration of the CG (1) by the author(s), or (2) if the number of
authors has dropped to zero, or (3) by CG consensus that the proposal
is out of scope. The Chairs will check-in with active proposals to
ensure the set of active authors is kept up-to-date.
</li>
</ul>
</p>
<p>
Proposals that have community group support and result in a deliverable
—either as interoperable standards/APIs or documentation— can
become CG work items.
</p>
<p>
<ul>
<li>
Proposed Work Item - A document proposed to become a CG work item. To
be adopted as a work item, a proposal should be sent out to the CG
mailing list, and there must be at least two supporters of the
proposal. For work items intended to become a web-exposed API, at
least one supporter should be a browser vendor (as an indication of
interest in implementation). Chairs should work with the authors to
help ensure that a proposed work item is within the scope of the CG
and that there is sufficient likelihood that the work item will be
implemented in the ecosystem.
</li>
<li>
Work Item - When consensus has been established, proposed work items
become official work items of the CG for further iteration, driven by
a group of assigned <b>editor(s)</b> who are generally the proposal
authors.
</li>
<li>
Completed Work Item - A document that the CG is satisfied with and may
be sent on to a working group for standardization.
</li>
</ul>
</p>
<h2 id="process">
Community and Business Group Process
</h2>
<p>
The group operates under the <a href=
"https://www.w3.org/community/about/agreements/">Community and Business
Group Process</a>. Terms in this Charter that conflict with those of the
Community and Business Group Process are void.
</p>
<p>
As with other Community Groups, W3C seeks organizational licensing
commitments under the <a href=
'http://www.w3.org/community/about/agreements/cla/'>W3C Community
Contributor License Agreement (CLA)</a>. 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 <a href="#deliverables">Deliverable</a>.
The section on <a href="#contrib">Contribution Mechanics</a> describes
how W3C expects to monitor these contribution requests.
</p>
<p>
The <a href="https://www.w3.org/Consortium/cepc/">W3C Code of
Ethics and Professional Conduct</a> applies to participation in
this group.
</p>
<h2 id="contrib">
Contribution Mechanics
</h2>
<p>
Substantive Contributions to Specifications can only be made by Community
Group Participants who have agreed to the <a href=
"http://www.w3.org/community/about/agreements/cla/">W3C Community
Contributor License Agreement (CLA)</a>.
</p>
<p>
Specifications created in the Community Group must use the <a href=
"http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document">
W3C Software and Document License</a>. All other documents produced by
the group should use that License where possible.
</p>
<p>
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.
</p>
<p id="githublicense">
All Github repositories attached to the Community Group must contain a
copy of the <a href=
"https://github.com/w3c/licenses/blob/master/CG-CONTRIBUTING.md">CONTRIBUTING</a>
and <a href=
"https://github.com/w3c/licenses/blob/master/CG-LICENSE.md">LICENSE</a>
files.
</p>
<h2 id="transparency">
Transparency
</h2>
<p>
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.
</p>
<p>
Meetings may be restricted to Community Group participants, but a public
summary or minutes will be posted to the
<a href="https://github.com/antifraudcg/meetings">Meetings</a> repository.
</p>
<h2 id="decision">
Decision Process
</h2>
<p>
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).
</p>
<p>
If there is no sustained opposition, then an action will proceed.
Opposition can be expressed explicitly via the mailing list or to the
Chairs.
</p>
<p>
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.
</p>
<p>
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 <a href="#decision">decision process</a>.
</p>
<p>
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.
</p>
<h2 id="chairs">
Community Group Chairs
</h2>
<h3 id="chair-responsibilities">
Chair Responsibilities
</h3>
<p>
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.
<ul>
<li>Organize/run virtual and face-to-face meetings/conferences.</li>
<li>Encourage/solicit participation in the Community Group.</li>
<li>Maintain GitHub organizations/repositories.</li>
<li>Triage and respond to general issues on the repositories.</li>
<li>Ensure compliance with the W3C CG/BG Process and CLA.</li>
<li>Uphold the processes and scope determined by the CG charter.</li>
<li>Mediate contentious CG issues.</li>
<li>Determine whether the CG has consensus on actions/issues.</li>
<li>Coordinate with other W3C and external groups.</li>
</ul>
</p>
<h3 id="chair-selection">
Chair Selection
</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
<b>Participants announce their candidacies</b>: 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).
</p>
<p>
<b>Participants vote</b>: 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, <a href="https://datatracker.ietf.org/doc/html/rfc2777">RFC2777</a>
is used to break the tie.
</p>
<p>
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.
</p>
<p class=note>
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
<a href=https://www.w3.org/People/functions/w3m#dom>Dominique
Hazaël-Massieux</a>.
</p>
<h2 id="charter-change">
Amendments to this Charter
</h2>
<p>
The group can decide to work on a proposed amended charter, editing the
text using the <a href="#decision">Decision Process</a> 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.
</p>
</body>
</html>