Before: Arbitrator: EvaStöwe (A), Respondent: CAcert (R), Claimant 1: Florian L (C1), Claimant 2: CAcert (Support - originally filed by Werner D) (C2), Case: a20141022.2

Contents

  1. History Log
  2. Original Dispute
  3. Pre-Arbitration activity
  4. Discovery
  5. Elaboration
  6. Ruling
  7. Execution
  8. Similiar Cases
  9. Account Deletion Procedure

History Log

Link to Arbitration case a20141022.2 (Private Part), Access for (CM) + (A) only

EOT Private Part

Original Dispute

Original Dispute by Florian L

Hello, 

please close/delete my Account. 

Many thanks
regards,

Original Dispute by Werner D for Support

Dear Arbitrators,

I need your decision.

I wanted delete this account with the usual routine but got an error message
that not all certificates are expired or revoked. This error message is wrong
since indeed all certificates are long enough revoked. To fix the software
error we nee the raw data from the date base from the critical admins, which
requires your authorisation.

Original Follow-up Dispute by Florian L

Hallo,
ich glaube ich habe vor einiger Zeit mein Konto sperren lassen. Heute
habe ich verucht mein Konto Passwort zurückzusetzen. Dies gelingt mir,
aber ich kann mich trotzdem nicht einloggen.

Pre-Arbitration activity

Initial Decisions by Arbitrator

1. In the OTRS there is more than the dispute filed by Werner D that was added to the wiki by the iCM.

The original delete account request has to be added to the case as well, because

a) It was not finally handled by support.

b) Support is not able to handle it further as the ticket was moved to Arbitration.

c) Support did not manage to match this case with a ruled precedents case, so it has to be handled by Arbitration.

d) Even as the supporter requested something else, it WAS the original request and the original "dispute", as CCA says that by default delete account cases are arbitration cases.

2. Update parties and relief

By this we have two quite different requests (and relief) in this case:

 * close the account, with everything that is missing

 * deal with the request of the supporter regarding the access to the data from the productive server

For each request there is a different claimant.

I as Arbitrator think that the person who wanted the account closed by this also is a claimant of this case. And Werner was acting as a support engineer, so "CAcert (Support)" has to be a claimant for that second part. There is no indication that he was filing the case personally.

The case file should be updated accordingly.

Discovery

For simplicity "claimant" in the next part means C1 (Florian L):

Regrettably this was not what was done. And even worse claimant was not informed about the derivation of the announced process.

Instead what happened was:

This case was filed as "Access to database needed to track down user interface error", because this was what the support engineer had requested.

Ironically this lead to this case not being picked up for some while, as arbitration was busy to deal with a lot of delete account cases at that time which were given some more priority. As this case was not marked as a delete account case, it's priority was considered to be lower.

Regarding the issue of the support engineer

With the dispute some account data was provided. It showed an active PGP signature.

The research done by the Case Manager (after discussion with the Arbitrator) suggests/confirms that the account could not be deleted at the requested time, because of this signature.

Because those signatures cannot be revoked, an account cannot be closed while the signature is active. As with certificates, the same retention time has to be applied, afterwards.

The PGP key expired in 2015. Since about mid 2015 it should be possible to delete the account with the standard procedure.

Addendum

Elaboration

Ruling

Ruling Part I (close account)

In the following "claimant" is the member who had asked to close his account (Florian L).

1. The account of the claimant should be closed by support directly without further checks or mails to the claimant as this steps were already covered. The case number of this case should be used for the closing process.

2. If support has issues to close the account with the automated process, the manual procedure should be used. This should be  done in coordination with the Arbitrator and - if the Arbitrator sees the need - critical team.

3. If the account of the claimant was already closed by some other case, the above becomes obsolete.

4. All risks, liabilities and obligations of the claimant which were caused by the fact that the account was not closed at the time that the claimant was told as the time when his account would be closed, are transferred to CAcert. As the delay was singularly caused by CAcert and the claimant was not even informed that his account was open and that he remained to be a member with those risks, liabilities and obligations, he cannot be made responsible for that period.

5. If either the account is already closed or the account can be closed directly without issues by support, no need for further investigations regarding the data of the claimant exists, the according request will be dismissed.

Eva Stöwe, 2016-08-10

Ruling Part II

1. The CAcert membership of Florian L is terminated at 2016-08-11.

2. The request from the support engineer to get "the raw data from the data base from critical team" to "fix the software error" is rejected and dismissed for the following reasons:

a) There was no error with the software to begin with. The behaviour of the software was the expected one, regarding the ruled process for closing accounts. At the time when that supporter tried to close the account, there was a non-expired PGP signature in the account. An account may not be closed in such a case.

b) Even if there would have been an error it would not have been the task of support to "fix the error", so providing even additional data to support would have been unreasonable.

c) There has to be a good reason for looking up the data of a member. While it may be necessary to identify or verify a software error, in general there have to be prior steps and checks done. If possible there should be a specific theory about what could be the issue to be checked or excluded. Looking up user data should not be the first step to identify a possible bug. In normal situations there should be at least a bug filed, the respective code checked for expected behaviour and if reasonable some attempt to re-create the issue on the test server. The estimate could be different in a critical situation. Nothing of this was mentioned in the current case.

Eva Stöwe, 2016-08-11

Execution

Similiar Cases

There is a multitude of similar account deletion cases. They are available through the Categegory links mentioned towards the end of this case log. For brevity only the applicable precedents cases are listed here.

a20111128.3

Delete Account cases which may be handled by SE - No Assurances given, no certs or certs expired

a20141024.1

Terminate account

a20140713.1

Delete assurer account with all assurances older than 7 years

a20140123.1

Close my assurer account

Account Deletion Procedure

Arbitrations/a20141022.2 (last edited 2016-09-10 17:28:40 by PietStarreveld)