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:

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:

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

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:

  1. 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.

  2. important information is put on the blog

  3. 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
  4. decisions and discussion happen on the particular lists

    • each group maintains its own formal decision process, documented under DecisionNumbers

  5. everything else is less formal

    • probably found on this wiki, or the svn or a maillist archive.

    • will be migrating off the website at some time.

comma/Identity/Communications (last edited 2017-08-19 19:38:11 by EtienneRuedin)