FrOSCon 2016 Session Report

The following report was written by EvaStöwe after a session regarding possible withdraw of cases by CAcert(Support)/CAcert and prior clarification about claimnats. More details are included in the introduction of the report.

It was originally send over board-public mailing list and internal arbitration mailing list at 2016-08-23. The original mail can be found here.

This was followed with a slight discussion which can be found in the context of above link as well.

A follow up mail was send for some further cases that matched a pattern as defined in this session (under 8.).

The executive "decisions" done within the session (and also regarding the additional cases) were afterwards confirmed by board motion m20160921.2:

Resolved, that board withdraws the cases as mentioned in the emails https://lists.cacert.org/wws/arc/cacert-board/2016-08/msg00009.html and https://lists.cacert.org/wws/arc/cacert-board/2016-08/msg00017.html acting for CAcert as claimant of that cases.

(!) All parts in "" in dispute descriptions are direct quotes from the according disputes. They are parts of the claims of one party and as none of the cases were ruled so far, cannot be understood to be a fact. They are the words of the person who filed that dispute. Participants of the session possibly would have phrased those parts differently.


A) Introduction

At FrOSCon Dirk, Gero, partially Piet and me went threw a lot of arbitration cases that were filed by formerly active members possibly in their roles. Partly some other members were present and were allowed to listen and to speak up their minds. The questions, that were discussed were:

  1. if those cases were filed in that role, so if the claimant would be the according team and/or CAcert, of if those cases were personal cases of the persons who had filed the case and
  2. if yes: if the according teams would consider the cases to be of relevance now, as some of those disputes were quite old and/or some things could have changed.

At the beginning of the session an agreement was made that the results of the session would be presented to the complete board (and possibly affected teams) to give them an option to confirm or deny some of the decisions. The arbitration team also should be informed.

The only decisions that were done on arbitration side during this session were done in cases that were already picked up and are named in the context of the respective cases.

As the session was done during an event near or at the booth of CAcert there were multiple breaks. Because of this it would not have been sensible to mark down times, so this was not done. The session started at Sat 2016-08-20 with only Dirk, Gero and Eva present (Piet was informed but did not join in) and continued at Sun 2016-08-21.


B) Table of contents

The protocol is structured like this:


C) People present and their roles


D) General procedure

Eva had prepared a list of cases filed by former members of some teams who had resigned, relatively recently. The list (or parts of it) were send to board and support with the question discussed in this session some weeks ago, but neither board nor support had managed to find the time to answer. One case was an ABC request over a member who had resigned at least partly, recently, where the filing member did not answer the question if that case should be continued, or not (and himself had resigned some months ago).

Most of the filing members were asked according questions prior to the session in a specific or general manner, as well, even if not all cases were named in all situations. None of them had answered. For other cases that were picked up by arbitration, they seem to agree (or even stated that agreement) that the cases were filed out of a role and by this are not their own cases.

The cases were discussed like this:

  1. Eva as member of the arbitration team read the dispute aloud. If they were extremely long or there were possible privacy reasons only summaries were given or the respective parts were left out.
  2. If not completely obvious, it was shortly discussed if the case was filed as a personal case or with the respective team role. Hints for a role-filing were
    1. explicit mentioning of that role
    2. included mails or information that was gained based on that role
    3. requests for authorisation of actions for the according team
    Based on such hints there was mostly direct agreement, if the case was a role case or a personal case. (Cases that could not have been filed out of a role were not mentioned in the session at all.)
  3. If the case was understood to be a role case, Dirk as representative of the according team was asked if he saw a reason to continue that case or if that case should be withdrawn. Dirk mostly added some reasons for his decisions. To be able to do this he sometimes looked up a related ticket on support side. Sometimes some more information was asked from Eva.
  4. Afterwards Gero was asked if he would agree with the "team" decision. In some situations Geros perspective was asked by Dirk first, in those cases Gero provided his point of view, first. In the cases that were understood to now be with board, both Dirk and Gero discussed the situation.
  5. In some cases it was also discussed (mostly at 3. but sometimes later, where it made sense), if there was a wish to update the dispute, as sometimes the original dispute was not understood to make sense (any more).
  6. Eva noted down the according decisions and read here notes aloud so that they could be confirmed or commented by the others. The two cases which were already picked up and partially handled before the session, were not following this pattern. They were handled with CM / Arbitrator authority and the questions that were thought to be appropriate in that context were asked.


E) discussed cases and decisions made

a) Cases filed by Benedikt as internal Auditor

1. a20140712.1 - "Dispute against the acting supporter in s20140623.75"

Link: a20140712.1

short summary of dispute:

Audit got aware of a massive data privacy breach and abuse of supporter power by the respondent. documented in i20140625. 3 times violation of two parts of Privacy Policy and also abuse of power to request additional information and provide false information (see also a20140624.1). Request: ask arbitration to handle the individual prosecution"

Dirk and Gero (both: role board):

Dirk (role support)

Dirk also stated that this would be in the interest of the support team.


2. a20140815.1 - "Attempted privacy data breach"

Link: a20140815.1

short summary of dispute:

Audit got aware of a attempted data privacy breach and abuse of supporter power (documented in i20140814.1) by attempting to look up the data related to an email address posted to the public mailing list with a support question.

further comments

when asked by Gero and Dirk, Eva revealed to them, that respondent of a20140712.1 is same as of this case (This possible relation was already named by Benedikt.)

Dirk and Gero (both: role board):


b) other cases, possibly for support (filed by Werner or Marcus), or for software (filed by Benny or Michael)

3. a20120113.1 - "CCA violation, Close Account"

Link: a20120113.1

summary of dispute:

"Dispute against [a member] since he seemingly uses an account with fake data. His account shall be closed and his certificates revoked." - This was the reaction to a mail send by that member with the request to help to reset the password where the user had issues to enter the correct birth date in the automated process.

support(Dirk):

please hand back case to support, as there is another "policy" within Support that names a lot of other options in such situations to handle such situations (for example to propose request to close account so that another can be created, but maybe there were only some issues with entering the birth date).

board(Gero):

ok


4. a20141027.1 - "Request for precedence ruling for accounts with obviously fake or non-personal names"

Link: a20141027.1

summary of dispute:

"Support observe during support case handling that" names in an accout are "obvious fake names, which is a CCA violation." [Data for one specific case]

"Support should have the rights to act as follows:"

support (Dirk):
  1. why does one see those accounts?
  2. how to know that it is fake data?
  3. if at all support should address those if they use their correct data with a nice mail and a reference to CCA, with no further consequences based on b. - there is no allowance to look up the account later again
  4. if there are assurances it has to be assumed that those assurances are valid, if there is no reason to doubt this by someone who has seen the data of that person (another assurer) [if there were assurances can be seen as supporter without looking up the assurer]
    • => withdraw

board (Gero):

ok


5. a20120305.2 - "CCA Violation"

Link: a20120305.2

summary of dispute:

"Account created by user contains data that are not met by CAP form nor ID shown during face to face meeting."

This was filed after two members had contacted support about issues with that assurance and when the member was not answering support

support (Dirk):
  1. there could be issues with email provider if someone does not answer
  2. there is no requirement to answer support, only requirement to answerarbitration
  3. old assurances could sometimes be an issue, because AP (and CCA) was installed only later and some points had to be clarified, first, this is known and it's probably hard to get CAP forms or anything, now, if older then 7 years
    • => withdraw

board (Gero):

ok

note of Eva when preparing protocol:

In the discussion there was the assumption that the case was filed because the member did not response to support, but some deeper reading when preparing the protocol revealed something else. (There are multiple somewhat unorthodox sorted mails in the private part of the case file and not enough information in the public part.)

I suggest to review the decision because of this.


6. a20120331.1 - "Bogus Account"

Link: a20120331.1

summary of dispute:

"at the "List of Tverify Admins" I stumbled over the entry "The Most Reverend Sherlock H[...]. He even has 150 points, yet from one single TTP assurance." dispute against user to change to ral name and to revoke certificates, though they are expired, maybe delete account dispute against assurer to warn him for giving wrong assurances.

support (Dirk):

analogue as above, no CCA, no AP, please hand back to support

board (Gero):

ok

note of Eva when preparing protocol:

Further below there is a note by the filing person, that it was a known fake account "that will be deleted anyway in the near future, so there is no special action needed"


7. a20121114.1 - "Change in Data Base"

Link: a20121114.1

summary of dispute:

"In the list of received assurances I found the following annoying entry:" [assurance details in method and/or location field an entry with a lot of "\\\\"]

suggested precedents case, because of other similar cases: Support should be allowed to

"No essential contents shall be changed, that would still be up to arbitration"

support (Dirk):

withdraw

board (Gero):

ok


8. CCA-violation cases (possibly fake name or not responding):

There were multiple further "CCA violation" cases filed from support team members, either based on

To safe time they were not handled separately, because of the following request from support side:

support (Dirk):

withdraw, hand back to support

board (Gero):

ok

Candidate cases for this are:

The following candidates were collected in detail by Eva after the session and included in the protocol:

Which cases are covered by this will have to be analysed in detail.


9. a20140627.2 - "discrepancies in account"

Link: a20140627.2

summary of dispute:

there is a support ticket: in database user was bale ot grant 15 AP, when he entered assurances. Recently he is only able to issue 10 AP.

[all assurance data provided to arbitration]

The problem is assumed to be related to an entry with 0 in the old calculation. If it would be 10 everything would be fine. After discussion with software a query to look up the assurances the user got was created to see where the error came from. Maybe also need to look into log files.

support (Dirk):

no withdraw, because user is asking for clarification of this issue, but would want to updated the specific request regarding the query, it would provide too much unnecessary information

board (Gero):

ok


10. a20140819.1 - "Arbitrated Background Check over Felix D"

Link: a20140819.1

note by iCM(Eva):

the respondent already had confirmed that he wants to continue the case, the claimant had not answered an according question (but also has left that team and board)

software(Dirk):

wait for ruling in a20150916.1 and until software is active

board(Gero):

ok


11. a20140914.1 - "name change from ss to ß umlaut"

Link: a20140914.1

summary of dispute:

A member wants to get the spelling of his last name changed in his account from "ss" and "ß", because of issues with different spelling in his certificates. "ss" is an allowed and official secondary spelling for "ß" if that character is not available.

Support had filed with arbitration because it could not be handled with a precedents case

support (Dirk):

remove support as claimant, as the request is more or less covered by the user

board:

ok


About here date changed, additional persons present


12. a20130530.1 - "AdHoc SQL Query to get info about accounts with DOB in the future."

Link: a20130530.1

activity by Arbiration

support (Dirk):

is case of support not personal case

board (Gero):

ok

Arbitrator (Eva):

claimant is CAcert(Support)

summary of case:

Accounts with date of birth (DoB) newer than the account creation date were found.

Dispute was a request to find and lock all those cases and if there is no activity to anonymise them in a way that the email address could not be used to create a new account. When user would request access to those email addresses, thy should get the chance to fix the DoB. (There was a later bug-fix that accounts could not be created with a DoB in the future.)

The provided query was changed by Arbitrator to cover all accounts with a DoB newer than the creation date. The query revealed 161 accounts.

Neither the former nor the current Arbitrator would allow the requested block, as that would not help to fix the issue.

Dirk for Support:
  1. check assurances of those accounts
    • if assured:
    • revoke assurance (inform both sides)
    • if assurer appear multiple times: warning about better assurances (information where to find training or rules)
  2. up to 3-times an automated mail to all those accounts:
    • write to them and explain issues, and options to fix or to close account

Gero for board:

not too much work


13. a20131128.1 - "SQL Query - Request for analysing"

Link: a20131128.1

activity by Arbiration

support (Dirk):

support case, not Marcus

board (Gero):

ok

Arbitrator (Eva):

claimant is CAcert(Support)

summary of case:

"7", 1 * "12", 1 * "15" assurances.

Arbitrator (Eva):

summarised first results, question how to proceed, wants more input than just "do it"

board (Gero):

first results probably to be discussed in board - added this topic to board agenda


14. a20141022.3 - "Dispute about who decides how support organizes its work internally"

Link: a20141022.3

initial comment

* Eva declares to be conflicted, before presenting dispute

background of dispute (based on referenced mail and Evas summary - requested by Dirk and Gero to understand dispute)

In 2014 an update to the CCA was done, this required a mail to all members to inform them about this change. This mail was send under the name of Eva as PolicyOfficer, returns would be sent to support. "For statistic reasons" support wanted to direct all returns into a specific queue and to be able to file a dispute for CCA failure against everybody where there would be a bounce. The idea was to use the legally required mail as a secret ping against all members. Eva protested against this. Software and critical team organised sending of mail before such a queue could be installed.

Later she saw that entries in the list of deleted accounts were sometimes marked with an additional "C", after the CCA change mail was send out. [There are rulings with a specific description how the cases should be noted in the wiki, the "C" is not covered.]

Even later Eva discovered that delete account requests as answers to the CCA change mail were not tagged as "delete account" as they normally were, but as "mass mailing".

Eva then had send a request to support to not handle the returns to the mail that was signed by her, differently than other mails and to remove this specific category at least for the returns from that sending, other normal tags.

summary of dispute:

dispute to clarify who has the power to decide how support tags tickets in the OTRS. These tags are needed to

"Eva now demands that support stops tagging and delete all tags"

"As she quotes herself in her mail she tried to influence how support structures its work before."

As "a result of her interference into support work" "support has no chance to get statistical information about these tickets" The dispute shall clarify who decides how support tags and structures on its internal needs on support tools that are not open for public view.

support (Dirk):

withdraw, support is re-organised and this case is not needed any more, without a request by board, PolG or Arbitration such a separation of tickets would not be allowed

board (Gero):

no further comment

[Piet present, witness of these decisions]


15. a20141106.1 - "Dispute to fix bug 807"

Link: a20141106.1

summary of dispute:

after bug 807 https://bugs.cacert.org/view.php?id=807 was released on 2014-06-01 certificates with sha-384 were signed by sha-512 instead. This was not recorded, so that there is missing information Issue was fixed on 2014-06-13.

Left are entries which do not have any record about signature algorithm, the according field is blank.

This will cause issues if certificates are renewed.

Request to apply an sql statement to add missing entries into DB "Please check if these sql statements can be used so the fix the problem." Possible before first certificates are due for renew on 2014-12-01

software (Dirk):

it's a case from software, withdraw, case too old, people have probably acted on it, anyway, it's nearly 2 years ago, anyway

board (Gero):

was not present


16. a20150725.1 - "Harm to swift processing of security issue"

Link: a20150725.1

initial comments

Benny B (C1a) (TL blocked by CoI), CAcert Support Team (C2) rep. by Marcus M (C2a)"

(R2)

everybody who could say something is conflicted


F) Summary:

continued cases

1

case continued by board

1

3

cases continued by support

9, 12, 13

1

case continued by software

10

1

case continued as personal case of a member

11

withdrawn / merged cases

1

case merged into another

2

5

cases withdrawn by support with request to hand case back to support

3, 4, 5, 6, 7

1

case withdrawn by support

14

1

case withdrawn by software

15

undecided cases

1

case undecided because everybody was conflicted

16

further cases

10

cases are candidates to also be withdrawn with the request to hand case back to support

8

Note:

All in all 15 specific cases were discussed, 10 other cases are likely to be covered as well, which makes a total of 25 cases. 7 cases will be continued.

Up to 18 cases will be withdrawn or merged. This is about 15% of the open cases in the wiki.