• Arbitrations
• a20111204.3

• Case Number: a20111204.3
• Status: execution
• Claimants: Michael R
• Respondents: CAcert

• Initial Case Manager: BernhardFröhlich

• Case Manager: UlrichSchroeter

• Arbitrator: BernhardFröhlich

• Date of arbitration start: 2011-12-07
• Date of ruling: 2012-01-05
• Case closed: 201Y-MM-DD
• Complaint: Wrong DoB in account
• Relief: Correct DoB

Before: Arbitrator BernhardFröhlich (A), Respondent: CAcert (R), Claimant: Michael R (C), Case: a20111204.3

History Log

• 2011-12-04 (issue.c.o) case s20111204.984

• 2011-12-06 (iCM): added to wiki, request for CM / A

• 2011-12-07 (A): I'll pick up the case, UlrichSchroeter will be Case Manager.

• 2011-12-07 (A): Sent initiating mail to C and witnesses.
• 2011-12-08 C and Assurer 2 answer to initiating mail and confirm the data recorded in OTRS.
• 2011-12-08 (A): Sent request to Support for Assurers who have assured C's account
• 2011-12-09 Support reports that two Assurers (Assurer 3 and Assurer 4) have already assured the account.
• 2011-12-10 Assurer 1 answers to initiating mail and confirms the data recorded in OTRS.
• 2011-12-12 (A): Rent requests for information to Assurer 3 and Assurer 4.
• 2011-12-19 Support reports that C suddenly can't login to his account. Also the account cannot be found any more in the support interface.
• 2011-12-20 (A): Sent request to Critical Admins to execute the ad-hoc-queries and report the results.
• 2011-12-21 Critical Admins provide results of ad-hoc-queries. They seem to imply that the account was deleted by accident (or software bug).
• 2012-01-04 (A): Given Intermediate Ruling 3 to "undelete" C's account
• 2012-01-04 (A): Sent mail to Critical Admins asking to execute the intermediate ruling.
• 2012-01-04 (A): Support reports execution of statements and provides logfile excerpt
• 2012-01-04 (A): Sent mail to C notifying that the account should now be "undeleted", and asking for information which may confirm the theory.
• 2012-01-04 (A): C replies, he confirms that he has accepted the dispute due to misunderstanding the mail.
• 2012-01-05 (A): Ruling in main issue given.
• 2012-01-05 (A): Followup Ruling 1 given.
• 2012-01-05 (A): Sent mail to Critical Admins asking to execute the ad-hoch statement from Followup Ruling 1.
• 2012-01-06 Critical Admins provide results of ad-hoc-request

Original Dispute, Discovery (Private Part) (optional)

• Link to Arbitration case a20111204.3 (Private Part), Access for (CM) + (A) only)

EOT Private Part

Discovery

• Two Assurers (Assurer 1 and Assurer 2) have sent reliable statements to OTRS that they confirm the claim. Both statements are confirmed in personal mails to the Arbitrator.
• DoB difference is an "off-by-one".
• Two Assurers have already assured the account, one for 10 Assurance Points, the other one for 30 Assurance Points.
• Assurer 3 and Assurer 4 did not reply within three weeks so a ruling will be given based on the reliable statements of Assurer 1 and Assurer 2.

Account Problem

• From SQL queries it seems that C's account was deleted by accident or software bug.
• The statements to "undelete" the account have been tested on the testserver.
• From the logfile excerpt provided it seems that the account's primary mail address has been disputed and the dispute has been accepted. If this theory can be confirmed, the problem was caused by a user error (accepting the dispute). Nevertheless this function could be considered fishy, especially in the light of auditing requirements.
• C confirms that he accepted the dispute message due to misunderstanding it's text. It's still not clear who initiated that dispute.

• A note referencing to this case has been added to Case#879 on the Bugtracker

• From the result of the ad-hoc query the initiator of the email-dispute can be identified.

Ruling

Intermediate Ruling 1

One of the witnessing Assurers (Assurer 2) is a CAcert Arbitrator himself and has extended access to this status page. Therefor any party of this Arbitration may request a copy of the private page of this Arbitration anytime to avoid any advantage in information.

Assurer 2 must not use his extended access to modify this status page or the private page directly.

Munich, 2011-12-07

Intermediate Ruling 2

It looks like something broke down with C's account. It may be caused a software bug or a handling error by the SE. Since the account cannot be found in the SE console a handling error by the user is improbable.

To try to track down the problem I hereby order the Critical Admins to execute a set of ad-hoc SQL query:

• SELECT id, fname, mname, lname, suffix, dob, modified, deleted 
    FROM `users` WHERE email = '<C's email>';
  
  SELECT n.* 
    FROM `users` u 
      LEFT JOIN `notary` n ON n.`from`=u.`id` OR n.`to`=u.`id` 
    WHERE u.`email` = '<C's email>';
  
  SELECT d.`domain`, COUNT(dc.id) 
    FROM `users` u 
      LEFT JOIN `domains` d ON d.`memid`=u.`id` 
      LEFT JOIN domaincerts dc ON dc.domid=d.id 
    WHERE u.`email` = '<C's email>'  GROUP BY d.`id`;
  
  SELECT COUNT(ec.id) 
    FROM `users` u LEFT JOIN emailcerts ec ON  ec.memid=u.id 
    WHERE u.`email` = '<C's email>';

Munich, 2011-12-20

Intermediate Ruling 3

According to the ad-hoc queries C's account is marked as "deleted". No reason could be found why this should be so. The account has not been anonymized, as it would be in a proper Account Deletion Procedure, so it is quite easy to restore most of the account data by using another ad-hoc statement.

Therefor I order the Critical Admins to execute the following statements:

• UPDATE `domains` SET `deleted`=0 WHERE `domains`.`memid`='<ID>';
  UPDATE `email` SET `deleted`=0 WHERE `memid`='<ID>';
  UPDATE `users` SET `deleted`=0 WHERE `id`='<ID>';

Of course Critical Admins are encouraged to point out potential problems before executing the script, if they should see any.

In addition to executing the statements Critical Admins shall provide relevant logfile entries to help tracking down the cause of this problem.

Munich, 2012-01-04

Ruling in main issue

Based on the reliable statements of two Assurers and the statement of the account owner I give the following ruling:

The Date of Birth in the Claimant's account shall be changed by support according to the claim. No reduction of Assurance Points or Experience Points is considered necessary.

The Arbitrator reserves the option to issue a warning against Assurer 3 and Assurer 4, depending on future responsiveness and cooperation, in a followup ruling.

The issue of the email-dispute resulting in the temporary account deletion shall be further investigated, and followup rulings will be given if necessary.

Munich, 2012-01-05

Followup Ruling 1

To find out the originator of the email dispute execution of the following ad-hoc query is ordered:

• SELECT CLAIMANT.fname, CLAIMANT.lname, RESPONDENT.lname, DE.* 
    FROM disputeemail DE LEFT OUTER JOIN users CLAIMANT ON (CLAIMANT.id=DE.memid), 
         users RESPONDENT 
    WHERE DE.oldmemid=RESPONDENT.id AND DE.oldmemid=<Account ID of Claimant>;

Munich, 2012-01-05

Note: For future uses the primary mail address of the CLAIMANT table should also be selected to reliably identify the account...

Followup Ruling 2

From the collected information it seems that the email dispute has been initiated by accident.

The initiator of the "email-dispute" shall be notified about what happened, and shall be educated of the "email-dispute" function. Since no malicious intent is perceived, no further penalty is considered necessary.

Munich, 2012-01-06

Precedence Ruling

Prerequesites

• Account must already have Assurance Points (otherwise the account owner can make the change him/herself)
• The difference must be minor (see below for details)
• No malicious intent is recognizeable
• The account owner files or confirms the claim

What is a minor difference?

A minor difference is a mismatch which can be easily overlooked and is not changing the data significantly. Typical examples include:

• Usually one missing, additional or modified character in the recorded name. An Exception to this is when the difference turns the name into another usual name (Maier -> Mayer or Meier -> Meiser) or the difference is very obvious (Hans -> Xans)

• Off-By-One in Date of Birth. Day, month or year differ by one.
• Mixup of month and day in DoB
• One different digit in day or month

Process for Support

• Check for minor difference. If difference is not minor ==> Arbitration

• If dispute is not filed by account owner
  • Send mail to account owner asking for a statement

  • If account owner rejects statement or does not answer within 14 days ==> Arbitration

• Ask for two CARS by Assurers confirming the claim. If the two statements cannot be found within a reasonable time (about one month, longer periods may be accepted if it seems appropriate) ==> Arbitration

• Ask Assurers that have already assured the account ("Hasty Assurers") for a statement, requesting an answer within 14 days.
  • If an Assurer can confirm the claim from notes, this counts as one of the needed confirmations.

  • If an Assurer explicitly rejects the claim ==> Arbitration

  • If an Assurer cannot contribute information or does not answer within 14 days nothing happens (at the moment)
• When two confirmations can be collected and noone rejects the claim the precedence ruling may applied and the following actions shall be made:
  • Add the OTRS case number to the list at the end of this status page, by mailing it to the disputes bucket in OTRS if necessary access is not available.
  • Modify the account according to the claim
  • If the difference was in the recorded name, all certificates including the wrong name shall be revoked
  • The "Warnings Database" (which still has to be implemented) shall be checked if any of the Hasty Assurers already has two warnings recorded.
  • Hasty Assurers which do not already have two warnings shall be sent a mail encouraging them to administer more care in the future and have a warning added to the "Warnings Database".

  • If a Hasty Assurer already has two warnings recorded, file a new Dispute against the Assurer.

Notes

• Every party (including the Support Engineer) may request to transfer a case to Arbitration
• Every action and mail communication of the Support Engineer must be recorded in the ORTS case
• Until the "Warnings Database" is implemented the warnings may be skipped.
• This precedence ruling is intended to be reviewed and refined once the detailed requirements of the Warnings Database are known.

Munich, 2012-01-17

Execution

• 2012-01-05 (A): Sent mail to Support to execute ruling in main issue
• 2012-01-06 Support reports the DoB is changed.
• 2012-01-06 (A): Notified Claimant, Assurer 1 and Assurer 2 that the DoB is corrected and the Assurances may be completed.
• 2012-01-06 (A): Sent notification to initiator of "email-dispute"
• 2012-01-06 Assurer 1 notices that the DoB in the account is still wrong!
• 2012-01-06 (A): Sent request to Support to re-check the actions made.
• 2012-01-06 Initiator of "email-dispute" answeres, he was mislead by the term "dispute" and thought that it should be used for standard disputes.
• 2012-01-06 Support replies, it's unclear what happened. SE is sure that he changed the date and commited the change. Modification is re-done and has been verified by the Arbitrator.
• 2012-01-12 (A): Sent reminder to Assurer 3 and Assurer 4
• 2012-01-12 Assurer 4 replies, asking for phone call.
• 2012-01-17 (A): Proposed Precedence Ruling made final

Caselist where precedence ruling was applied

• Date of Account correction	Support Case Number	Type of Case (Name/DoB)	Number of Warnings recorded
  2012-01-29	s20120129.53	DoB	none
  2012-02-16	s20120213.22	DoB	none
  2013-02-09	s20130208.90	DoB	none

Similiar Cases

---

• CategoryArbitration

• CategoryArbCaseAccountDataDoB

• CategoryArbCaseEmailDispute