• Arbitrations
• a20110428.1

• Case Number: a20110428.1
• Status: running

• Claimants: StefanBruening

• Respondents: CAcert

• Case Manager: BernhardFröhlich

• Arbitrator: UlrichSchroeter

• Date of arbitration start: 2011-04-29
• Date of ruling: 201Y-MM-DD
• Case closed: 201Y-MM-DD
• Complaint: Forward of PII to mailing list
• Relief: TBD

Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: StefanBruening (C), Case: a20110428.1

History Log

• 2011-04-28 (issue.c.o) case [s20110428.87]
• 2011-04-29 (A): added to wiki, request for CM / A
• 2011-04-29 (A): I'll take care about this case as (A)

• 2011-04-29 (A): I appoint the (CM) as per Arbitration Team meeting 2011-04-05 decision

• 2011-04-29 (A): sending initmailing to (C) with CCA/DRP acceptance request, CC to involved 3rd party (U1) with request to become addtl. (C2) to this case
• 2011-04-29 (A): Intermediate Ruling
• 2011-04-29 (A): Intermediate ruling notification sent to participiants, with Exec request to Lists-Admins, (C)
• 2011-04-29 (A): order to lists-admin for removal of mail from archive as given by the intermediate ruling
• 2011-04-29 (C): accepts this arbitration
• 2011-04-29 (C): Just to be sure: I have to inform the support-mailing-list about that issue?
• 2011-04-29 (A): answer to (C)'s question
• 2011-04-29 (A): order to Infrastructure t/l for removal of mail from archive as given by the intermediate ruling
• 2011-04-29 (A): added topic for Committee Meeting 2011-05-01 as topic 2.6 Incident Report following SP 5.6 under a20110428.1 (Ulrich)
• 2011-04-29 (A): Summarize, questions about this issue to (Support t/l), (SE), (Infrastructure t/l), (Board)
• 2011-04-29 (Support t/l): responded
• 2011-04-29 (Infrastructure t/l): responded
• 2011-04-29 (A): clarification of the given problem
• 2011-04-29 (Infrastructure t/l): response
• 2011-04-30 (Support t/l): responded
• 2011-04-30 (Infrastructure t/l): exec report, post removed from archive
• 2011-05-02 (former Support t/l): statement, PoV
• 2011-05-03 (A): summarizing potential solution, with details view, to (Support t/l), (SE), (Infrastructure t/l), (Board) for review
• 2011-05-22 (issue.c.o) case [s20110521.19] (2nd new dispute)
• 2011-05-22 (A): Intermediate Ruling
• 2011-05-22 (A): Intermediate ruling notification sent to participiants, with Exec request to Lists-Admins, (C)
• 2011-05-22 (Lists-Admin): post from [s20110521.19] that includes PII removed from archive
• 2011-05-23 (A): results from lists tests with multipart messages, sanitize procedure proposal to (C), (Support t/l) and (SE)
• 2011-05-23 (Support t/l): responded
• 2011-05-23 (A): 2nd summarize and proposal for Forwarding procedure
• 2011-05-24 (SE): responded
• 2011-05-24 (A): summarize responses from (Support t/l), (SE), review of documentations to (C), (Support t/l) and (SE)

Original Dispute, Discovery (Private Part)

• Link to Arbitration case a20110428.1 (Private Part)

EOT Private Part

Intermediate Ruling

1. The users, if not already happened, should be notified by the Triage member (C) about the privacy breach
2. The lists admins should take the necessary steps to remove all private data sent to the list concerning this case (eg. remove the effected attachments from the posts from the public archives or if this is impossible, to remove the complete post from the mailing list)

Frankfurt/Main, 2011-04-29

Discovery

• Problem araises out of Goole Indexing, so each forwarded information becomes indexed by Google, if user does like it or not. Public Support mailing list is opened with Index=Allow

• Users who writes to Support@c.o and first handled by Triage, have no choice to select a private or public forward as under Contact Us website link

• Has OTRS an option to disable forwarding of attachments ?
• Has the public mailing list an option to disable attachments ?
• this is the 2nd PII breach issue within a 2 months period
• So the common practice to forward Support tickets to public mailing list is in question
• Triage challenge is online, but such things as proper sanitizing are not part of it yet.

• Assumed Triage member was trained well as given under ruling a20110228.1, the possible solution paths can be:

  1. disable Index=Allow of Support mailing list for Google indexing

     • Pro:
       Generally the list archives are a great resource for people looking for
       information. So having them archived and publicly available is a good
       idea.
       
       Con:
       1. is a common discussion topic, but doesn't prevent sending of PII to a mailing list
       2. There are also list archives by third parties like gmane
          http://blog.gmane.org/gmane.comp.security.cacert.user.general
          how do we deal with those?
       3. But we need a way to have a method for fast removal as like on
          request of sender.

  2. disable attachments forwarding from within OTRS to public mailing lists by either disable attachment forwarding from within OTRS -or- disable attachments on receiving side of the mailing list software

     • needs to be checked by application administrators
       
       Pro:
       I know, you can limit attachments in some way.
       ... there should be some option in the software.
       
       Con:
       There is also no option in the frontend of the mailing list. Apart from that this might break things like gpg/mime or even s/mime signatures and sometimes users want to post e.g. screenshots to this list.

  3. prevent common practice to forward mails to Support@c.o to public mailing list by Triage members, move tickets to Support-Engineers instead

     • Con:
       moves the PII problem from Triage to SE

  4. to add sanitize of PII also for attachments to the training material.

     • Con:
       1. is a soft solution but crosses the border of a pure "triage" job
       
       2. The general idea was that there are too few SEs so we need to pass all
          work we can to the mailing list. Maybe we can do a compromise and be
          less aggressive when choosing what to forward.
          I.e.
          a.) only forward requests which don't have to be sanitized at all.
          b.) Or we could also completely avoid forwarding by sending the user a
              standard reply that his request is general enough that he should send
              it to cacert-support@lists.c.o because otherwise we can't handle the
              workload
       
       Discussion: What to sanitize ?
       1. I am wondering what is sanitized at all. Nearly all posts I have seen
          contain names and / or email addresses of senders. So in fact no real
          anonymization happens and the info you usually do not want to is
          archived. And if it contains another domain name (than from the email) I
          would not care that much. The problem is more name and / or email
          address which makes the sender identifiabe.
          (problem: dispute case included also:
                    postal address, website, phone and other infos)
       
       2. As long as email or name are included, I would not care that much and
          consider sanitising optional. However, forwarding mail to a more or less
          open mailing list sent to a private address like support should not
          happen. Or at all, just with all information removed and also name and
          email stipped.
       3. But also forwarding just name and email reveals enough information which
          is findable by search engines. First of all the email address is exposed
          to spammers by having it a) harvested by search engines and b) available
          to malware of list subscribers - by the number of subscribers the latter
          is quite likely, although CCA demands to keep the computer safe.
          Even just the name or email address (which often contains the name)
          reveals enough information: What the user is interested in (CAcert) and
          also other information regarding the request. E.g. that he is not able
          to remember a password or operating servers.
       4. So this essentially is a question whether we can do any forwards at all.
          Because if we don't include the email address in the forward, the
          mailing list members can't write the answer to the person needing it. We
          could add a pseudonym but then we needed to reforward mails to that
          pseudonym back to the member which makes the whole thing more
          complicated than handling the issues within support.
       5. The decision that names and email addresses in forwards are OK was made
          quite some time ago. I'm OK with saying that nothing should be forwarded
          from the private channel support@ to the public mailing list (as there
          were quite some complains) but if we only forbid forwarding and let
          support handle everything then support will definitely drown. So we need
          another option to handle the additional traffic.

  5. restructure Triage to 1st level Support, and SE as 2nd level Support

     • Good idea. I already suggested a structural change. Drop the Triage
       concept and make Triage a First level support. Have them answer all
       requests, which are coming in which can just be answered. If some action
       is required, e.g. by SE by accessing the system or by arbitration,
       forward the mail to the related queues as second level support. We also
       might establish something like third level support in the proposed
       concept, which are the teams working in the background, e.g. system
       administration or software development.

  6. Alternate Queues
     1. refuse accepting requests, advice requestor to send to public list

        - just refuse to handle such issues within support and refer people to
        the mailing list (potential problem: people feel that no one is helping
        them and they just get redirected from one person to the next,
        especially if they just receive a short explanation on the mailing list
        but then have to return to support again)

     2. private mailing list

        - a private mailing list where tickets can be forwarded, that has no
        archive but may be subscribed by the same people subscribed to
        cacert-support (potential problem: the information is not really private
        – someone might keep an archive and publish it, maybe even services like
        gmane are subscribed)

           * make the support mailing list a closed one.  Only CAcert people.
           * signal no external archiving
           * enforce client certs
           * moderate it, SEs being able to accept the mail after a check of PII.

     3. another OTRS queue

        - another OTRS queue, a whole lot of accounts, a new group for helpers.
        Everyone who wants to help out gets an OTRS account without much
        questions asked, and can answer tickets moved to that queue (potential
        problems: quite some admin activity required to create those accounts
        and barrier is higher than just subscribing to another mailing list.
        Information is still not really private as someone could take
        screenshots or do copy & paste of the tickets, etc. but that's more
        cumbersome than taking an email archive. No sanitizing of information
        from Triage possible as the ticket history can be seen in full)

Intermediate Ruling #2

1. The users, if not already happened, should be notified by the Triage member (C) about the privacy breach
2. The lists admins should take the necessary steps to remove all private data sent to the list concerning the case

[s20110521.19] (2nd new dispute) (eg. remove the effected attachments from the posts from the public archives or if this is impossible, to remove the post from the mailing list that includes the PII)

Frankfurt/Main, 2011-05-22

Deliberations

The PII breach issue is a repeating event. Training cannot solve this problem alone. One suggestion that was made is, to make the public support mailing list a "walled garden". That has its advantages and its disadvantages. The advantage is to limit the count of involved users. The disadvantage is, that the count of potential helpers also becomes limited.

Questions to answer:

1. Which informations about a user can be published?
   • Publishing the name and the email of the user is not on discussion, so the answers given can reach the requestor.
   • Addtl. informations about a user, often added as a footer, with full address, phone, webaddress and so on is a problem. Also informations about a 3rd party (Assurees).
   • Triage members are trained to sanitize these infos before forwarding mails to the public mailing list.
   • But by the nature of multipart/mixed messages, the addtl. informations still left in the attachment part within the ticket system, that causes the PII breach after the forward to the mailing list
2. What is about a moderated forward ?
   • Moderating mode of the mailing list means, at least 2 people have to handle each post. From the services side this is an unrealistic venture and as seen in the PII removal requests to the lists admins this results in a removal of a complete post because no modifications can be made within the posts.
3. Preventing multipart/mixed messages from forwarding ?
   • Preventing forwards of multipart/mixed messages to the mailing list can be an option.
   • One may argue, that someone can send attachments within his mail, to explain his problem.
   • The answer here is: starting with the mailing, a potential supporter can get in contact with the user and the addtl. infos can be send later between the P2P contact.
   • So there is no real need to allow attachments in the public support mailing list.
   • This option needs some testing ...
     • Sending mulitpart/mixed messages allowed includes the attachments to the post
     • Sending multipart/mixed messages to be forwarded to moderators does only allow rejection or approval, no modification
     • Sending multipart/mixed messages and to strip the mulitpart/mixed and attachments is impossible within the mailing list software, but delete attachments on forwarding within OTRS is possible
   • On Forwarding messages from Triage queue to public support mailing list
     1. Delete Attachments
     2. Sanitize message text
   • can be trained to the Triage members
4. Prevent Google indexing and external archives ?
   • publishing all the email addresses of everyone who needs support, that seems like a dumb idea for a supposed privacy organisation.
   • So the archive has to be restricted to subscribers only.
   • To send a signal: no external archiving

Ruling

Execution

Similiar Cases

• CategoryArbitration

• CategoryArbCaseSystemTasks