* Case Number: a20100309.1
  * Status: closed
  * Claimants: Daniel B, Mario L.
  * Respondents: CAcert
  * Case Manager: SebastianKueppers
  * Arbitrator: BernhardFröhlich
  * Date of arbitration start: 2010-11-30
  * Date of ruling: 2010-12-20
  * Case closed: 2010-12-20
  * Complaint: periodic transfer of email addresses for general announcements

{{{
The General Announcements setting of a members profile is under-utilized in CAcert. The setting, available to members at the URL https://secure.cacert.org/account.php?id=36, provides a good communication form for sending mails to subscribers. Its storage location on CAcert critical infrastructure protect members privacy quite well however it inhibits utilisation because:
1. It is inaccessible to those who need to email announcements (would require frequent arbitrator authorizations)
2, the critical infrastructure is poorly suited to the 100,000 emails (currently) that would be generated upon a general announcement.

In consultation with t/l of the Critical Systems Administration
team I propose that:
1. The SQL query extracting only general announcement email address ("SELECT users.email from users, alerts WHERE alerts.general = 1") be run on the webdb server.
2. results from the query are emailed over local or encrypted link to a lists.cacert.org mail box
3. results are loaded into a cacert-announce list which has the following properties:
   a) members of the list are not viewable by the public or other members (only the list owner and list administrator can view list)
   b) posting to the list is restricted to official communication authorized by the board
4.This process is to be automaticly run monthly (or more frequently should there prove to be sufficient demand and within the capabilities of the critical infrastructure to handle this load). Updates to this list will remove from the announce list members who no longer wish to receive general announcements.

The lists.cacert.org infrastructure already protects privacy information in arbitrator, support engineers and board-private email lists.

An arbitrators decision is desired  in favour of this operation under section 8.5 of the Security Manual.

I accept the Arbitration under the CAcert Community Agreement and the Dispute Resolution Policy. I accept the the governing law will be that of NSW Australia.
}}}

  * Relief: TBD

Before: Arbitrator name arbitor (A), Respondent: CAcert (R), Claimant: Daniel B (C1), Mario L. (C2), Case: a20100309.1


== History Log ==
 . 2010-03-09 (issue.c.o) case [[https://issue.cacert.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=9194&ArticleID=16492&QueueID=1|s20100309.75]]
 . 2010-03-10 (UlrichSchroeter): added to wiki, request for CM / A
 . 2010-11-12 (BernhardFröhlich): issue.c.o case [[https://issue.cacert.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=47030|s20101112.4]]: Mario L. supports the claim and wants to be added as Claimant.
 . 2010-11-12 (BernhardFröhlich): I'll take this case as Arbitrator, any CM available?
 . 2010-11-28 (SebastianKueppers): I'll be CM for this case.
 . 2010-12-01 During discussion C2 extends the request to all alert flags (country, regional, local announcements), not only general announcements.
 . 2010-12-05 A: Sent mail to SysAdmin Team Leader requesting a statement about the interface.
 . 2010-12-05 SysAdmin Team Leader answers, see Discovery.
 . 2010-12-06 A: Sent another mail to clarify the Point of View on the pull interface for specific searches.
 . 2010-12-07 SysAdmin Team Leader replies to claifying questions.

== Discovery ==

 * The proposed statement is faulty, a slightly more correct statement would be
{{{
SELECT users.email FROM users, alerts WHERE alerts.general = 1 AND alerts.memid=users.id;
}}}
 * Additional restricions are needed to exclude accounts marked as deleted, disabled or anonymised. 
 * [[http://www.cacert.org/index.php?id=10|PrivacyPolicy]] does not adress internal use of mail adresses.
 * Position of Privacy Officer [[https://wiki.cacert.org/Officers|is currently vacant]]
 * SecurityManual does not give instructions for transfer of data to other systems
 * [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|Security Policy]] (SP) has to be considered. Especially relevant sections probably are 3.1.1.2. "Internal connectivity", which rules that additional connectivity must be approved by System administration team leader, and 3.4.2. "Special Authorisation", which defines access authorisation for special functions, like our Interface will probably be.
 * There may be problems with inactive users, who have long forgotten their passwords, and so cannot change their alert settings themselves any more. Some solution has to be provided for such users to change their alert settings without a full password reset.

=== Statement of SysAdmin Team Leader ===
{{{

The proposal is to export the result of an SQL query on the webdb server
to retrieve the general announcement e-mail address list, like:

   SELECT users.email FROM users, alerts WHERE alerts.general = 1 AND
      alerts.memid=users.id;

on a monthly basis to the lists.cacert.org system, to be used for general
announcement e-mail shots. We are expecting that the lists.cacert.org
administrator will make available for this purpose an e-mail address to
which this SQL query result can be sent by e-mail on an automatic basis.
In order to avoid accidental disclosure of the e-mail by transport problems,
a private gpg key should be associated with the target e-mail address, so we
can encrypt the data with its public key.
The information will be provided on a 'push'-basis, there will not be a way
for lists.cacert.org or any other system to 'pull' this information out of
the webdb system. Thus this data transport will use an already existing
outgoing channel of the webdb system, i.e. SMTP e-mail.

As the Critical Systems Administrator Team Leader, I am happy to implement the
above proposal with the stated restrictions, and will document its use of the
(already documented) SMTP egress channel in the CAcert Security Manual when we
proceed to implement it.

}}}

Clarifying his position in a second mail his position on the subject can be summarised:
 * He supports the periodic export of mail adresses for general announcements, like in the initial request.
 * The periodic export is not considered as a special access in the sense of SP 3.4.2. It does not create additional connectivity since mail connectivity is already implemented and documented.
 * A "pull" (or request driven) interface is considered as a more complicated way to do the job. Since the specific mailings can be handled by the core system, due to considerable lesser amount of mails, he would prefer to improve and automate the already existing process of handling ATE mailings.

=== Outlining the process in discussion ===

The process of export which is under discussion here is outlined as:
 * A cronjob runs the SQL query on the database and exports the result on the core system.
 * The resulting file is encrypted with public keys of the person(s) authorised to operate the general announcements.
 * The encrypted file is sent via mail to an adress provided by the mail operator. The mail should not be transferred outside CAcert infrastructure.
 * If authorised by a board motion the operator decrypts the mail adresses and starts the mailing.
 * After the mailing is finished the decrypted mail adresses are securely deleted as soon as possible.

== Reasoning ==

 * An explicit statement from the Privacy Officer can not be acquired since the position is currently vacant. So the Arbitraton must try to evaluate the Privacy Officer's point of view on the problem.
 * Though the alert settings are activated by default, they are prominently displayed on the sign on page, so it may be assumed that the user accepts being notified if the flags are not removed.
 * The management of a mailing list on a system separate from the core system can be considered a valid technical requirement. Due to access restrictions managing software like mailing list software on the core system is not easily done.
 * Though care has to be taken not to compromise the mail adresses of members, a potential compromise of the mail adresses would only reveal little information about the member. It would more or less connect the fact of membership with the mail address. No further personal identifying information (like names, birthdates or other mail adresses) can be linked to the mail adress on the mailing system.
 * Adding the location of the user to the transfered data would partly invalidate the reasoning above. So the mail adresses for more specific notifications (country, regional, local announcements) must be handled with another process.
 * Concerning SP 3.4.2. and 3.1.1.2. the view of SysAdmin Team Leader is adopted. Documenting a new role for the mailing operator in the Security Policy is not considered necessary. The SysAdmin Team Leader is responsible for documenting connectivity, if needed.

== Ruling ==

Taking into account the facts and reasoning listed above I give the following ruling:

The export of mail adresses from accounts which have activated the "General Announcement" setting is hereby authorized if the following requirements can be satisfied:

 * It must be assured that the exported mail adresses are not compromised during transfer to and storage on the mailing system. 
 * Only the primary mail address of an account may be exported.
 * Access to the exported data must be restricted to trusted personnel. It should have been subject to an Arbitrated Background Check and been recommended for a security sensitive job.
 * The mail addresses may only be used to send mails approved as General Announcements by a CAcert Inc. board decision.
 * It must be assured that adresses of users who reset the general announcement setting will be deleted from the mailing system within a reasonable time.
 * The frequency of export runs may be adjusted to technical requirements. To assure deletion of adresses with revoked agreement, the frequency for an automatic export should be at least once per month. 
 * The software implementing the export on the core system has to be approved according to Chapter 7 of Security Policy and Security Manual.
 * Until another arbitration defines a standard on how to handle them, non-delivery- and similar reports shall be deleted as soon as possible after reception. They may be counted for statistical evaluation.
 * Statistical evaluation of mail adresses (for sent mails and/or NDR) may not be more detailed than on a top level domain basis.
 * A process has to be provided for inactive users to reset the alert settings without a complete password reset. Each mailing should include (as text or as link to an internet page) a description of this process.
 * Exports for more specific (country, regional, local) announcements are not adressed in detail by this Arbitration. Improving the existing process of ATE mailings is left to Software Development team.

== Execution ==

 . 2010-12-20 (A) Sent mail to claimants informing them about the ruling.

Case is closed.

== Similiar Cases ==
|| [[Arbitrations/a20090525.1|a20090525.1]] || [[Arbitrations/a20090525.1|Event officer request recurrent notification to assurers near the location of the following ATEs]] ||

----
 . CategoryArbitration
 . CategoryArbCaseSystemTasks