* Case Number: a20141106.2
  * Status: dismissed
  * Claimant: Marcus M, Benny B
  * Respondent: CAcert
  * initial Case Manager: UlrichSchroeter
  * Case Manager: PietStarreveld
  * Arbitrator: EvaStöwe
  * Date of arbitration start: 2016-07-03
  * Date of dismissal: 2016-07-29
  * Case closed: 2016-07-30
  * Complaint: Dispute to analyse strange behaviour on domain dispute

  * Relief: 
   1. I would like to ask critical to perform this sql statement to find out which user account holds the wrong entry: 
    select `users`.`id` from `domains`, `users` where  `domains`.`domain`='[snip:domain]' and `domains`.`memid`=`users`.`id` and (`users`.`assurer_blocked`=1 or `users`.`locked`=1)
   2. With a second sql statement should be checked which domains are linked  to more than one user account.
    Select `domains`.`domain`, Count(`domains`.`domain`) as Count from `domains` where  `domains`.`deleted` = 0  group by `domains`.`domain` having   Count(`domains`.`domain`) > 1

Before: Arbitrator: EvaStöwe (A), Respondent: CAcert (R), Claimant: Marcus M (C1) Benny B (C2), Case: a20141106.2

<<TableOfContents(2)>>

== History Log ==
 . 2014-11-06 (issue.c.o): case [[Ticket:334592|s20141106.37]], reference: [[s20141102.58]]
 . 2015-09-08 (iCM): added to wiki, request for CM / A, sent notification
 . 2016-07-03 (CM): pick up case, EvaStöwe will act as A
 . 2016-07-06 (A): request support to make available missing ticket information and provide name and primary email address of domain owner affected
 . 2016-07-07 (CM): A notified by Support that the ticket s20141102.58 doesn't exist within OTRS
 . 2016-07-29 (A): ruling send to (C1), (C2), board 

== Private Part ==

 * '''Link to Arbitration case [[Arbitrations/priv/a20141106.2|a20141106.2 (Private Part)]]'''

## ==> INCLUDE SECTION BOT
<<Include(Arbitrations/priv/a20141106.2)>>  
## <== INCLUDE SECTION EOT

==== EOT Private Part ====

== Original Dispute (Anonymized) ==

 {{{
> Hi arbitration,
> 
> support observed the following behaviour in the software. This is 
> related to ticket s20141102.58
> A user has two accounts. He tries to dispute the domain from the one 
> account to the other.
> The following information was sent to support:
> Someone has just attempted to dispute the domain [snip:domain] , which 
> belongs to a locked account:
> 
> By searching for the domain it could be found in the second account of 
> the user but both accounts show no sign of blocking or locking.
> 
> Therefore I would like to ask critical to perform this sql statement to 
> find out which user account holds the wrong entry:
> select `users`.`id` from `domains`, `users` where 
> `domains`.`domain`='[snip:domain]' and `domains`.`memid`=`users`.`id` and
> (`users`.`assurer_blocked`=1 or `users`.`locked`=1)
> 
> This sql statement is used to retrieve the "block information" in the 
> software is:
> select 1 from `domains`, `users` where `domains`.`domain`='$domain' and 
> `domains`.`memid`=`users`.`id` and (`users`.`assurer_blocked`=1 or 
> `users`.`locked`=1)
> 
> With the id of the user account returned support looks at the account. 
> According to the outcome of information a bug will be filled to solve 
> the problem.
> 
> With a second sql statement should be checked which domains are linked 
> to more than one user account.
> Select `domains`.`domain`, Count(`domains`.`domain`) as Count from 
> `domains` where  `domains`.`deleted` = 0  group by `domains`.`domain` 
> having   Count(`domains`.`domain`) > 1
> Hopefully we do not get any result here.
}}}

## You may remove unneeded sections at your discretion...

== Discovery ==

Note of CM: The Discovery section below is a preliminary version that I created as part of my training. It is pending a review by the Arbitrator.

=== About the original dispute ===

The dispute is a request to Arbitration to allow the Critical team to run two queries against the production database. Claimants state that they need the output of the queries to enable them to further investigate what they describe as ''strange behavior on (a) domain dispute''.

The Claimants describe one occurrence of strange behavior that involves a user with two valid and active accounts and a domain in one of them that the user wants transferred to the other. Upon using the dispute domain menu to perform that action the user then receives a notification that the domain can't be disputed for administrative reasons and that he could contact Support. Support receives a ''Someone has just attempted to dispute this domain '%s', which belongs to a locked account'' notification of the event.

The Claimants consider this behavior to be strange and suspect a ''user account with a wrong entry'' to be causing it.

Claimants therefore want Critical to run the following queries against the production database and use the output for further investigation:

 1. an ''sql statement to find out which user account holds the wrong entry''

 this query is meant to list '''all locked account-ids''' that link to the '''one specific domain''' that the user was trying to dispute

 2. an sql statement to check ''which domains are linked to more than one user account''

 this query is meant to list '''all active domains''' that link to '''more than 1 user'''

=== Evaluation of the request ===

The description of the event as presented by Claimants is probably incomplete. A ''third locked account'' linked to the domain that the user tried to dispute provides a plausible and simple explanation for what occurred. This is also the account (or one of the accounts) that the first query as suggested by Claimants is going to reveal.

The fact that the link to the (deleted) domain in that locked account is considered a ''wrong entry'' by Claimants, while in fact it is a perfectly valid entry from an operational and design perspective, points to a mis-perception of what actually occurred. A less invasive slightly different query showing only a count of locked accounts would have done just as well here. Claimants fail to provide a valid reason for needing specific user-ids for further investigation.

The second query that Claimants propose doesn't bear any relation to the observed behavior and would never return results, if any at all, that would be helpful for investigating the ''strange behavior on domain dispute'' issue. The Claimants fail to provide a substantial reason for this query in their request.

=== Known bugs and fixes related to similar behavior in domain and email disputes ===

The behavior described in the example presented by Claimants is not so much strange as unwanted and it affects both email and domain disputes. Due to a missing check for deletion the dispute code doesn't handle deleted emails and deleted domains in locked accounts similar to deleted emails and deleted domains in active accounts.

Bugtracker currently reports 3 overlapping/duplicate bugs related to similar 'strange behavior' in both automated email and domain disputes:

 * [[https://bugs.cacert.org/view.php?id=1310|Bug 1310]] - The check about email during email dispute works incorrect
 * [[https://bugs.cacert.org/view.php?id=1384|Bug 1384]] - Problems to add a domain to an account that was assigned
 * [[https://bugs.cacert.org/view.php?id=1415|Bug 1415]] - treat deleted emails like free emails in email disputes

For Bug 1310 a fix was submitted that addresses the unwanted behavior in both email and domain dispute functionality. This fix for Bug 1310 made it to the testerver-stable branch in 2014 but is still awaiting a final review and was never merged into the release branche. Until the fix for Bug 1310 is reviewed and merged into the release branch unwanted behavior similar to that described in this and similar cases is bound to occur in both email and domain disputes.

=== Reviews of Respondents and Claimants ===

At the time of the filing the Claimants were a member of the Support Team and a member of the Software team.
 
The case log doesn't reveal whether the affected domain owner ever got in touch with Support over this nor whether Support ever got in touch with the affected owner.

Additionally there are no references to the affected domain owner to be found nor in the case log nor in the ticket:
 * the affected domain owner was removed from the original support notification as described in ticket s20141106.37;
 * when so requested by the Arbitrator, Support was unable to retrieve the ticket referenced as s20141102.58 from OTRS.

The Arbitrator therefore is unable to determine the domain owner whose dispute is the basis for the request nor can she add the domain owner to the list of Claimants or ask for additional information if she so
choses.

== Ruling ==
{{{
Before the case could be started it was relevant to
a) clarify who is claimant of this case and
b) what kind of data the queries would provide

Depending on the answer to both questions the case either has to be entered or dismissed.

It was not possible to identify the claimant who entered the "domain dispute" via the website, because
 * that information was deleted from the dispute that reached arbitration and
 * there was no case found either by support or by arbitration for the case number that was named in the dispute to arbitration.

Even as the Arbitrator wanted to add that member to the list of claimants, this was not possible.

The claimants who filed the dispute with arbitration are a lot farther away from the data, as it is not their data.



Regarding the "issue" described by the claimants in the dispute: there exists a valid possible situation which would clearly explain the situation and which also already was addressed in bugs by the software team at the time being (without that becoming productive).

As both claimants were quite active in the software area at the time when the dispute was filed and when those bugs were handled (both were involved in them), they should have been aware about that issue and should have been able to address the issue and to create a comparable situation on a test-system as the Case Manager has done.


Regarding the first query: It is also not possible, to use that data to solve the original issue, as the ticket with the original issue cannot be found. This possible need for the data provided by the first query does not exist.

Without being able to identify and consulting with the original member, that query should not be executed, if there is a good explanation.


Regarding the second requested query: It would have provided a list of all domains that ever were entered with CAcert which were transferred between accounts at least once. There was absolutely no motivation provided for that request and there is also no reason visible how that information would have helped to fix any software bug at all.

The Arbitrator cannot see any situation where the result of that query ever would be allowed to be provided to another member. If at all a counter would be allowed.

The request for such kind of information without any motivation comes close to be an attack to the data or privacy of our members. It is highly dubious.

Board should be informed about this requests, to consider if it has to be documented further or if any other action in the executive branch has to be taken.

As both claimants have left their posts in the critical teams and by this it is unlikely that they would file according requests outside of such roles, again, no further steps should be taken.

It should be noted, that the domain in question was provided in the dispute to arbitration. By this is was shared with the second claimant, without consent of the member or an arbitration request. The consent of the member that the data is shared with arbitration can be assumed as the member was filing a "domain dispute". But there is no evidence at all that the member gave his consent to get that data shared with software assessors.

The dispute is dismissed.

Eva Stöwe, 2016-07-29
}}}

== Execution ==
 . 2016-07-29 (A): ruling send to (C1), (C2), board 

== Addendum ==

 * [[Arbitrations/a20141106.2/Addendum|Bug Tracker references and test scenario's]]

== Similiar Cases ==

==== Domain Disputes ====

|| [[Arbitrations/a20100827.1|a20100827.1]] || [[Arbitrations/a20100827.1|domain dispute not solved by auto-domain-dispute]] ||
|| [[Arbitrations/a20110315.1|a20110315.1]] || [[Arbitrations/a20110315.1|Domain dispute, turned to CCA violation, administrative delete account]] ||
|| [[Arbitrations/a20110407.1|a20110407.1]] || [[Arbitrations/a20110407.1|Please remove <domain> from my Organisational Domains]] ||
|| [[Arbitrations/a20120305.1|a20120305.1]] || [[Arbitrations/a20120305.1|Password Reset, Domain Dispute, Paypal Dispute]] ||
|| [[Arbitrations/a20120723.1|a20120723.1]] || [[Arbitrations/a20120723.1|Cert Renewal problem, Domain Dispute, Remove Mail from Mailinglist, various issues]] ||
|| [[Arbitrations/a20150824.1|a20150824.1]] || [[Arbitrations/a20150824.1|Domain Dispute]] ||
|| [[Arbitrations/a20151130.1|a20151130.1]] || [[Arbitrations/a20151130.1|Identify person who tried to add the domain to her account.]] ||

==== Comparable Email Disputes ====

|| [[Arbitrations/a20110226.1|a20110226.1]] || [[Arbitrations/a20110226.1|Auto dispute request doesn't work (Account cleanup)]] ||
|| [[Arbitrations/a20160621.1|a20160621.1]] || [[Arbitrations/a20160621.1|Email dispute on locked account]] ||

== Technical References ==

 * [[Software/Database/StructureDefined|CAcert Software Database Structure Defined]]

----
 . CategoryArbitration
 . CategoryArbCaseDomainDispute
 . CategoryArbCaseSystemTasks
 . CategoryArbCaseOthers