JeuWeb - Crée ton jeu par navigateur
[Gestion des joueurs] Logs d'action : limites et bénéfices. - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Gestion des joueurs] Logs d'action : limites et bénéfices. (/showthread.php?tid=6441)

Pages : 1 2 3


[Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 01-02-2013

Bonjour à tous,

J'inaugure ce sujet sur les logs d'action et sur la pertinence de ce type de système pour "lutter contre les multicomptes".

Je propose pour commencer à discuter de ce sujet de partir sur une petite réflexion personnelle. N'hésitez pas à l'enrichir, la critiquer, à apporter votre point de vue sur ce mode de détection.


Avant toute chose, il est important de préciser que tout ce qui suit provient de mon expérience d'administrateur et de développeur d'un jeu qui a comporté un bon millier de joueurs actifs au plus fort de son activité.

Cette approche est donc double : d'une part en tant que développeur je peux évaluer la charge de travail que représente la mise en place des systèmes de détection de multi-comptes et d'autre part en tant qu'administrateur je peux évaluer la pertinence des différents systèmes de détection.

Le système que j'avais mis en place au lancement de mon jeu (à l'orée 2008) reposait intégralement sur la détection par IP. Au fur et à mesure que les joueurs, et donc les "cas" de multicomptes supposés, augmentaient, je percevais les limites évidentes de ce système.

La première de ces limites est d'ordre technique : les nouveaux terminaux mobiles produisent un nombre conséquent de faux positifs (exemple : deux personnes de Free se connectant via le réseau 3G sur mon site pourront avoir la même IP, de même que deux personnes utilisant un même relais public).

La deuxième de ces limites est d'ordre conceptuel : une identification par IP tend à produire un univers où l'IP fait office de référence dans l'analyse. C'est à dire qu'il est difficile de bien garder à l'esprit qu'une adresse IP ne signifie pas forcément un terminal. Ca peut paraître évident comme ça en tant que développeur mais... c'est loin d'être aussi simple à concevoir dans les faits en tant qu'administrateur.
Dans les faits, on prend rapidement le parti de traiter tous les cas ambigus de connexion à partir d'une même IP comme étant des multi-comptes, tout simplement parce que c'est une solution de facilité (dans la nébuleuse c'est notre seul indice) et parce qu'il faut être efficace face aux nombres de cas qui peuvent exploser (je dirais qu'il y avait 10% des comptes du jeu qui était des multis). Le soupçon a tendance à l'emporter sur le doute, et ça, ça craint !
Pour être un peu plus clair, à chaque fois que je devais traiter des affaires de multi-comptes ou de partages de compte supposés je me sentais vraiment mal à l'aise à justifier nos sanctions par une connexion à partir d'une même connexion (même lorsque d'autres indices corroboraient un multi-compte). En ayant conscience des limites de l'interprétation des traçages d'IP, j'étais coincé entre les besoins de justice des joueurs ("ouais, machin c'est un multi-compte !") et le principe que le doute profite à l'accusé. En somme, en se basant sur l'IP comme preuve, on est jamais sûr à 100% qu'on prend une décision juste.

Voici ma petite conclusion concernant le traçage par IP : cette solution est probablement la moins fiable des techniques et elle a tendance à nous forcer à prendre une décision (qui peut être erronée !). S'affranchir de cette donnée est impossible totalement, mais selon moi elle ne doit intervenir QUE lors de la détection des cas à analyser et ne doit JAMAIS servir de preuve. Elle n'est et reste qu'un témoin vague d'une relation entre deux comptes (relation qui peut être fortuite comme volontaire et parfois même obligatoire).

A partir de ces différents constats, j'ai décidé de chercher un autre modèle de gestion des comptes de joueurs avec différents principes :
1. Il y a dans ce nouveau modèle une distinction claire et nette entre les arguments utiles à la détection des multi-comptes supposés et ceux utiles à leur évaluation.
2. Les arguments utiles à la détection de multi-compte peuvent être : l'adresse ip, le navigateur utilisé et sa version, la géolocalisation, le mot de passe, l'adresse email, ...
3. L'argument utile à l'évaluation des multi-compte peut être : les logs d'action des joueurs.

L'utilisation des logs d'action est une solution qui permet de s'affranchir du doute lié aux limites techniques d'internet. Par exemple, dire à un joueur "je te sanctionne car tu as donné la moitié de tes ressources à un autre joueur lié à ton compte, ce qui est formellement interdit par la charte", ça ne souffre d'aucune discussion, alors que dire "je te sanctionne car il y a eu plusieurs connexions te reliant avec un autre compte", c'est nettement plus discutable (ça peut être son frère, son meilleur pote, ils peuvent s'être connectés à l'école, ...).

Cette gestion des logs implique une structure solide que je n'aborderai pas ici mais qui vaut certainement la peine de s'y intéresser. L'idée est la suivante : archiver toutes les actions pertinentes des joueurs afin de discriminer tout comportement anormal au vu du règlement.

Il y a plusieurs approches par rapport aux logs d'action :
1. Comparaison macro-chronologique : on cherche à déterminer les habitudes des joueurs (certains font toujours les mêmes actions en se connectant ou se connectent aux mêmes heures (plage horaire de jeu)). Deux joueurs se connectant toujours aux mêmes heures sont, supposément, plus susceptibles d'être des multi-comptes que deux joueurs se connectant à des heures différentes.
2. Comparaison micro-chronologique : on cherche à déterminer sur un cours laps de temps les "switchs" entre deux comptes de jeu. Ce switch se fait à la seconde près. Selon moi, c'est l'arme la plus puissante pour déterminer un multi-compte. Ca permet par exemple de voir qu'un joueur met une offre sur le marché à 15:05:10 et qu'un autre joueur la prend à 15:05:15.
L'intérêt de ces comparaisons micro-chronologiques est de mettre au jour un switch clair et net entre les deux comptes. C'est à dire qu'à aucun moment les deux comptes n'auront une activité à la même seconde ou à une ou deux secondes près.
Un développement graphique peut être particulièrement intéressant dans ce cas-ci. Exemple (joueur 1 en vert, joueur 2 en rouge, chaque cran représente une seconde) :

[Image: log.png]

3. Comparaison contextualisée : là on s'intéresse véritablement aux actions entreprises par le joueur. Il s'agit d'analyser les relations entre les actions entreprises par deux joueurs. L'un attaque un joueur, l'autre suit à chaque fois.

Ces trois approches sont complémentaires évidemment, mais selon moi les deux dernières sont plus puissantes que la première. La deuxième est particulièrement incisive et met clairement au jour le "switch" du joueur entre ces deux comptes qu'il ne peut pas gérer de façon simultanée (à moins d'avoir deux ordis et de bouger les deux souris en même temps, mais personne ne joue comme ça...).

J'ai pas encore eu l'occasion d'expérimenter cette solution à grande échelle, en dehors de prototypes et de beta de certains jeux, mais je suis persuadé que c'est la meilleure solution qui existe avec les moyens dont nous disposons actuellement. Elle permet une approche pragmatique (elle repose sur des éléments factuels non discutables) et efficace (pas cent mille choses à mettre en place). Ca me semble être un bon compromis entre le temps qu'on doit investir pour ce genre de système et les bénéfices effectifs.


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Thêta Tau Tau - 02-02-2013

Très intéressant résumé.

N'ayant jamais administré de jeu, je vais pas forcément pouvoir y apporter grand chose, j'ai cependant quelques questions/pistes :

+1 pour ne pas accorder plus d'importance que ça à l'IP, parce que d'un c'est pas fiable, mais surtout que ça entraine des mesures qui empêchent de jouer avec des gens qu'on connais ou le rends plus difficile, et ça c'est complétement naze. D'ailleurs il y a (avait?) même de gros jeux qui faisait ça à un moment, comme les royaumes renaissant....

Tes approches "Comparaison macro-chronologique", "Comparaison micro-chronologique" et "Comparaison contextualisée" sont puissantes, et à priori faire un script pour comparer 2 comptes est possible (un script qui ne sert qu'à sélectionner les "suspects" avant que le modérateur prenne le relai). Cependant, comparer deux à deux tous les joueurs me semble difficilement réalisable dès qu'il commence à y avoir un peu de joueurs (1000 joueurs = 1million de combinaisons), à moins de trouver un script ultra optimisé. Je vois plusieurs moyens de "présélectionner" les couples à analyser (ip, hash de mot de passe, échanges entre comptes, balance commerciale anormale d'un compte, progression anormalement rapide etc.), mais concrètement, qu'utiliser dans la pratique?

Une petite précision qui manque un peu dans ton résumé (peut être jugée trop évidente), c'est que tes 3 comparaisons doivent être vérifiées plusieurs fois, sur un pas de temps assez long, car deux joueurs jouant ensemble sur le même ordi seront "positifs" pour les 3 à certains moments (mais pas tout le temps).

PS : améliorer un peu la présentation du résumé serait un réel plus.


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 02-02-2013

(02-02-2013, 01:30 PM)Thêta Tau Tau a écrit : Cependant, comparer deux à deux tous les joueurs me semble difficilement réalisable dès qu'il commence à y avoir un peu de joueurs (1000 joueurs = 1million de combinaisons), à moins de trouver un script ultra optimisé. Je vois plusieurs moyens de "présélectionner" les couples à analyser (ip, hash de mot de passe, échanges entre comptes, balance commerciale anormale d'un compte, progression anormalement rapide etc.), mais concrètement, qu'utiliser dans la pratique?
Dans les faits, c'est très généralement les progressions anormalement rapides ou les similitudes de comportements in game qui servent de détection primaire. A partir de là, j'utilise un module de comparaison de joueurs qui peut me fournir :
- Les similitudes de mot de passe.
- Les mots de passe des joueurs (je les compare moi-même).
- Les similitudes d'adresses IP, ...
Et de façon plus avancée :
- Les balances commerciales anormales.
- Les 2 comparaisons chronologiques (qui peuvent être automatisées), couplées à une analyse "humaine" des logs (comparaison contextuelle).

Pour mon jeu, la détection primaire des multi-comptes supposés reposaient sur le travail des modérateurs. Ils avaient la possibilité de vérifier certaines données et pouvaient me signaler tout comportement suspect. Evidemment, ce type de fonctionnement n'est viable que lorsqu'on a qu'un millier de joueurs et que l'univers de jeu est commun à tous. Pour des plus gros sites, c'est pas à conseiller je pense.

Un processus de détection automatique serait un énorme plus, mais doit être chaud à mettre en place, si quelqu'un a déjà expérimenté le truc et peut expliquer ça plus en profondeur ça doit être pas mal intéressant.

Une solution alternative qui me semble particulièrement intéressante (de nouveau un compromis entre coût et bénéfice) : donner la possibilité aux joueurs de signaler un joueur. D'expérience, je peux vous dire qu'il y a certains joueurs qui sont de véritables chiens de garde, ils connaissent mieux le jeu que vous au point qu'ils détectent mieux les comportements anormaux.
Evidemment, un joueur ne pourrait être "analysé" par l'équipe de modération que tous les X semaines, histoire de pas avoir un joueur signalé chaque semaine pour rien. Cette possibilité de signalement peut être confié à une minorité de joueurs expérimentés également. Fin y a pas mal de modalités.
Par exemple, je ne sais pas si certains d'entre vous jouent à League of Legends, mais il y a un système de tribunal qui repose sur la multiplication des signalements de comportements litigieux. C'est-à-dire qu'à la fin de chaque partie, les joueurs peuvent reporter tout joueur qui aurait mal agi. Après un certain nombre de reports, le joueur est "jugé" par le tribunal (l'ensemble des joueurs se prononce sur son cas). Sans aller jusqu'à cette dimension collective du jugement, on peut en retirer un modèle viable pour la détection des "multi-comptes".

Personnellement, un modèle de ce type me semble viable à toute échelle (100 ou 10000 joueurs) :
- Les joueurs demandent une vérification sur les comportements in game d'un joueur (signalement).
- A partir de X signalements, l'équipe de modération vérifie les agissements du joueur. En fonction de leur analyse qui reposent sur de bons outils d'analyse (comparaisons des logs, des mots de passe, des adresses mails et ip, ...), l'équipe de modération déclenche une procédure de sanction.
- L'équipe d'administration prend une sanction en conséquence (cette tâche peut être confiée aux modérateurs).

(02-02-2013, 01:30 PM)Thêta Tau Tau a écrit : Une petite précision qui manque un peu dans ton résumé (peut être jugée trop évidente), c'est que tes 3 comparaisons doivent être vérifiées plusieurs fois, sur un pas de temps assez long, car deux joueurs jouant ensemble sur le même ordi seront "positifs" pour les 3 à certains moments (mais pas tout le temps).

PS : améliorer un peu la présentation du résumé serait un réel plus.
Effectivement Wink J'améliorerai la présentation à la fin du mois, quand j'aurai un maximum de retours et de contributions Smile


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 06-02-2013

Je me permets de up le sujet pour ajouter un petit détail qui a son importance, cette technique de comparaison des logs d'action permet aussi de casser, en partie, une technique très puissante utilisée par les plus douées des multicomptes, à savoir l'utilisation d'un VPN. En effet, même au-delà des différences d'adresses IP, on peut voir le switch entre les différents comptes, et ça, ça n'a pas de prix.


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Sephi-Chan - 06-02-2013

Je ne comprends pas trop pourquoi l'utilisateur aurait besoin de se déconnecter de son premier compte ? Qu'est-ce qui l'empêche d'ouvrir plusieurs navigateurs (ou d'utiliser plusieurs "utilisateurs" dans Chrome) ?

J'ai bien une idée de réponse : à savoir qu'il doit obtenir une nouvelle IP (même via le VPN).


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 06-02-2013

(06-02-2013, 10:09 AM)Sephi-Chan a écrit : Je ne comprends pas trop pourquoi l'utilisateur aurait besoin de se déconnecter de son premier compte ? Qu'est-ce qui l'empêche d'ouvrir plusieurs navigateurs (ou d'utiliser plusieurs "utilisateurs" dans Chrome) ?

J'ai bien une idée de réponse : à savoir qu'il doit obtenir une nouvelle IP (même via le VPN).
Ah mais justement, il peut très bien ne pas se déconnecter, mais grâce aux logs d'action, tu peux voir les actions entreprises sur les deux comptes.

Je vais donner un exemple plus concret :
Joueur 1 a écrit :[10:04:01] Connexion.
[10:04:03] Augmentation de la production.
[10:04:06] Consultation du forum.
[10:04:08] Déplacement sur la carte.
[10:04:15] Attaque de joueur 3.
[10:04:50] Augmentation de la production.
[10:04:56] Modification des paramètres du compte.

Joueur 2 a écrit :[10:04:30] Consultation du forum.
[10:04:34] Rédaction d'un message sur le forum.
[10:04:40] Déplacement sur la carte.
[10:04:45] Attaque du joueur 3.

Si comme ça les deux logs pris séparément ne révèlent rien de particulier, en les mettant en parallèle, on peut avoir ce genre de résultat :
Comparaison a écrit :[10:04:01] Connexion.
[10:04:03] Augmentation de la production.
[10:04:06] Consultation du forum.
[10:04:08] Déplacement sur la carte.
[10:04:15] Attaque de joueur 3.

[10:04:30] Consultation du forum.
[10:04:34] Rédaction d'un message sur le forum.
[10:04:40] Déplacement sur la carte.
[10:04:45] Attaque du joueur 3.

[10:04:50] Augmentation de la production.
[10:04:56] Modification des paramètres du compte.


# Le trou d'activité du joueur 1 (de 35 secondes) correspond à peu de choses près à l'activité du joueur 2.

Ca peut vous sembler caricatural comme comportement, mais dans les cas de multicompte et de partage de compte, ce genre de résultats est vraiment fréquent. Et parfois, dans les cas les plus grossiers, il y a effectivement déconnexion du navigateur pour switcher entre les deux comptes. Mais même sans que les joueurs se déconnectent, vous aurez souvent des "plages d'activité" (de quelques secondes à quelques minutes) qui seront marquées nettement et qui permettront de voir un switch d'activité entre les deux comptes. Comme je l'ai dit plus haut, à aucun moment les deux comptes n'auront des plages qui se superposent réellement (au delà de l'anecdotique).

Pour vous convaincre, il vous suffit de vous imaginer utilisant un multicompte :
- Vous ouvrirez sûrement un deuxième navigateur (ou une deuxième session), donc pas de trace de déconnexion.
- Vous ferez quelques actions sur l'un, puis vos actions sur l'autre.
- Et là vous vous faîtes chopper car en comparant les logs on voit clairement que vous "manipulez" le premier puis le second à tour de rôle.


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Thêta Tau Tau - 06-02-2013

Si le joueur ne se connecte/déconnecte pas, il reste quand même possible de définir des plages d'activités/inaction. Par exemple si le joueur prends 5 secondes pour une action en moyenne, si on voit qu'il ne fait rien pendant 30 secondes, on peut considérer qu'il n'a pas été actif pendant +/- 25 secondes. Cela dit ça me semble très complexe à automatiser si on veut générer des graphiques comme celui du 2. de Holy et les analyser automatiquement (parce que son exemple est très propre, mais avec un joueurs qui a 5 comptes et qui fait des petites poses pour aller sur un autre site par exemple, ça risque de pas être du tout évident).

Perso je fonctionnerais de manière purement statistique en analysant les intervalles entre 2 actions. Par exemple je peux calculer la fréquence des intervalles de moins d'une seconde pour un joueur, puis recalculer en fusionnant les logs de deux joueurs (qui n'ont rien à voir) qui jouent dans en même temps. Ensuite je calcule cette même fréquence pour la fusion des logs de deux comptes suspects, et je regarde si ça "ressemble plus" à deux comptes indépendants ou à un seul compte (auquel cas c'est un multicompte).


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Sephi-Chan - 06-02-2013

Ça permet de détecter une activité séquentielle sur les 2 comptes. C'est effectivement la façon de détecter la plus évidente à mon sens et sûrement l'une des plus efficaces.
Pour le joueur, masquer ça est vraiment délicat car ça implique de se forcer à manipuler les comptes tantôt en parallèle, tantôt en l'un puis l'autre (en laissant passer un peu de temps) : bref, se fondre dans la masse.

Par contre, pour détecter ça, il faut vraiment depiler les logs à la pelle ! Avoir un daemon qui ne fait que ça toute la journée : prendre 30 minutes de logs de tous les joueurs (ça peut représenter une quantité énorme de lignes) pour essayer de voir qui fait quoi au même moment, puis recommencer en faisant varier un peu la fenêtre, en faisant augmenter un score de doute, puis investiguer plus en détail entre les comptes suspects. Je n'ai jamais réalisé ce type d'algo, mais je pense que ce serait assez sympa d'en parler.


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 08-02-2013

(06-02-2013, 11:04 AM)Sephi-Chan a écrit : Ça permet de détecter une activité séquentielle sur les 2 comptes. C'est effectivement la façon de détecter la plus évidente à mon sens et sûrement l'une des plus efficaces.
Pour le joueur, masquer ça est vraiment délicat car ça implique de se forcer à manipuler les comptes tantôt en parallèle, tantôt en l'un puis l'autre (en laissant passer un peu de temps) : bref, se fondre dans la masse.

C'est clair. Pour moi c'est vraiment le point fort de cette approche pragmatique. L'idée sous-jacente étant que la seule chose qu'un joueur ne puisse pas dissimuler facilement, c'est l'activité humaine derrière chaque compte.

(06-02-2013, 11:04 AM)Sephi-Chan a écrit : Par contre, pour détecter ça, il faut vraiment depiler les logs à la pelle ! Avoir un daemon qui ne fait que ça toute la journée : prendre 30 minutes de logs de tous les joueurs (ça peut représenter une quantité énorme de lignes) pour essayer de voir qui fait quoi au même moment, puis recommencer en faisant varier un peu la fenêtre, en faisant augmenter un score de doute, puis investiguer plus en détail entre les comptes suspects. Je n'ai jamais réalisé ce type d'algo, mais je pense que ce serait assez sympa d'en parler.
L'automatisation des détections représente un travail considérable mais une fois en place ça doit être extrêmement puissant ^^ Pour l'heure, moi je me base sur le signalement des comportements suspects par les joueurs eux-mêmes afin de déclencher une procédure de vérification par l'équipe de modération. C'est la seule alternative crédible que j'ai trouvée en prenant en compte les problèmes d'échelle (entre un jeu avec 100 et 10000 joueurs, y a une nette différence).

Je prépare actuellement une version plus présentable de cette approche sur mon blog, je reprendrai en partie les remarques que l'on m'a faite ici Smile


RE: [Gestion des joueurs] Logs d'action : limites et bénéfices. - Holy - 08-02-2013

Et voilà le travail : Comment lutter efficacement contre les multicomptes ?

J'espère avoir été le plus clair possible, si jamais vous avez des remarques à faire, n'hésitez pas ! C'est un exercice plutôt neuf pour moi Smile

Je ferai sans doute un autre article si des choses pertinentes ont encore été dites dans les prochaines semaines.