Communications Practices
0. Prelims
This document is a practices, not a policy. That is, it documents what we do. In this case it does not head up to a formal audit-related policy, rather it is maintained and implemented by the Community, and approved by the Board from time to time. m20090815.4:
RESOLVED, that the board prepare a new communications practice that is substantially open and community-driven, and
FURTHER RESOLVED that this new communications practice is intended to replace the CAcertCommunication\"Policy\".
Tight control is in Appendix 1. This Practices deprecated things shown in Appendix 2. Community Information Channels are listed in Appendix 3.
1. Access to Community Tools
Where a system is not a critical system, and is for the purposes of community work, access control to the benefits of the application should be light. In general this applies to these applications: Wiki, Blog, IRC, Email, Maillists, SVN, etc.
By default, all members who are Assurers and are in assigned roles are to be automatically given access. An administrator should apply common sense in adding people without "roles" and should think broadly and inclusively. If members have the skills, put them to use!
Certificate is the Preferred mode
As a technical, systems and business priority, certificates should be used where and when possible. Administrators should pursue client-certificate authentication as the preferred way of access control, unless it is slowing down access to the real resource.
Access for the Public
For the public (people who are not Members of the Community) there should still be wide visibility. Because of the potential for attacks (especially spam) the following principles are evolving:
General information should be read-accessible over HTTP. Refers to www, wiki, blog, maillist archives. Comments, posts, edits and changes should be turned off over these tools. Note that some of CAcert's pages are popular, and are used for advertising / fund raising activities, so we have a vested interest in promoting readable and popular pages.
Information should only be changeable over HTTPS with client certificates. That is, to edit a wiki page, post a comment on the blog, upload to SVN, etc, this should all be done with our client certificates.
Robots / search engines
Currently, many services are open for robot/search engine mining, including many maillists.
TBA. This spot is subject of some current discussion & controversy. Wait and see...
2. Statements & Content
Content
In general, posts and other statements made by Members using the community tools are contributions to the Community, following CCA#1.3.
Removal
Administrators can remove mails under the following conditions:
- spam / UCE. The administrator makes an immediate judgement call, and removes.
- grossly offensive reasons. Although we would like to maintain an open debate environment, sometimes the discussion exceeds normal societal bounds. Where it gets excessive, in the judgement of the adminsitrator, the administrator should remove the content, then file dispute to confirm.
where information that is clearly private is posted without permission, by ommission or by accident. This is provided for in the general sense of a20090913.1.
Note that a20090913.1 states that contributions made freely do not get removed later on.
CAcert email addresses
Your CAcert email address should be used for all CAcert-related business. A use of an email address does not indicate an official statement. There is no ban on doing personal stuff with a CAcert email address, but note Contributions above, and also the general intention to archive all email for CAcert business related purposes (e.g., m20070920.2).
Formal Statements for the Public
Formal Statements by the Association are to be signed (words or cert) by a Director, with the words "for the Board of CAcert" or similar so as to indicate that these are official announcements. It should be accompanied by a Board Resolution, as referenced with a motion number (see the example at top). Use of an email address does not constitute a formal statement.
Formal Decisions by any group are to be numbered and documented as per DecisionNumbers. These are also formal statements of the Community.
CAcert Assurer Reliable Statement
An Assurer makes a reliable statement to the Community when doing an Assurance. The same reliability in any statement can be expressed by adding the terms CAcert Assurer Reliable Statement or CARS to the statement, or by otherwise establishing that what you say is reliable.
This is an evolving concept, being led by the Assurance team so as to create an auditable WoT. See Assurance Handbook on CARS.
3. Administration
Administrators should keep reviewable documentation of who has access to what, where restricted by names. At least two administrators should be listed for each access, and either of them can adjust the access (not dual control, but perhaps 4 eyes).
Any differences in opinion can be referred upwards to infrastructure team leader / board. Ultimately, as all our members are under CCA and Arbitration, the final place for disputes would be Arbitration, but that is not expected.
The board is to keep a list of systems that have some form of "tight control" on them. See Appendix 1. The board can approve tight access control, but does so cautiously because we are an open organisation, and volunteers do not have the time to work through "channels" and "access control mechanisms".
Appendices
Appendix 1. Systems with Tighter Control
- COD
- placing items in draft/policy status limited to documentation officer as approved
- accounts - restricted interface for support persons
- Paypal
- banks
- online accounting system (not yet made)
- maillists:
- list-admin list (private)
- cacert-arbitration and cacert-disputes (private)
- support@ email address (private) and support-se list (private)
- private board list (private)
- private members list (private)
- system log list (no-post)
- key persons registry (private)
- SVN:
- critical code is controlled by software assessment team
- AuditI (private)
- email address
- some role-titled email addresses are limited to approved people: privacy, audit, treasurer, secretary...
- name-titled email addresses are to be more open
- Members email addresses in online system
accessible by officers & directors (implementation dependent)
- wiki
TrustedGroup includes Board, and such long term persons as the board dictates
SupportEngineerGroup includes Support Engineers only.
Appendix 2 -- deprecated
Note this practice replaces m20090310.2 and CCP
Appendix 3. Channels
The channels that take the information to the community are not written in stone. Over the last year or so, this is what we have been doing, in rough order of decreasing importance:
- essential information has to be mailed out directly to members
- this requires Arbitrator approval under Security Policy as an ad hoc script
see Brain/Study/COrbitCA for examples.
- important information is put on the blog
snippets of news are transmitted via Community/Update
- this is maintained by the community
- and may be put on the blog from time to time
- decisions and discussion happen on the particular lists
each group maintains its own formal decision process, documented under DecisionNumbers
- everything else is less formal