Ce vocabulaire entend permettre à des administrateurs de sites ouverts à l'expression des internautes (wikis, blogs, forum, etc.) de s'échanger des données pour permettre un traitement semi-automatique du SPAM. Ce vocabulaire traite de la pratique de SPAM la plus courante dans ce genre de cas :
la publication de liens renvoyant à des sites choisis par le spammeur. Nous proposons donc ici un vocabulaire permettant, sous réserve de validation préalable, de filtrer les domaines qui sont l'objet de SPAM. [Attention : il ne s'agit pas de filtrer l'IP des spammeurs (ces derniers pouvant en changer très régulièrement), mais de filtrer les contenus publiés : on filtre donc les contenus qui contiennent des liens vers des sites qui n'ont rien à voir avec le sujet du wiki.] [Note pour moi-même : ce qui veut dire par exemple qu'un wiki dont le sujet serait le viagra, serait évidemment heureux d'accueillir certains liens que de nombreux autres sites considéreraient évidemment comme du SPAM. --
CharlesNepote.]
Principes
Principes généraux :
- le SPAM est relatif à un contexte, par conséquent, il n'est pas généralisable :
- un contenu considéré comme du SPAM à tel endroit, peut ne pas l'être ailleurs
- un contenu aujourd'hui considéré comme du SPAM à tel endroit, peut ne plus l'être quelques temps plus tard
- le filtrage d'information peut faciliter l'atteinte à la liberté d'expression, par conséquent :
- il doit rester possible de vérifier voire valider son exercice
- il doit rester possible d'invalider son exercice
[à revoir] Contraintes :
- sur un site donné : aucun contenu ne peut être filtré sans avoir fait l'objet d'une validation par une personne habilité
- un domaine ayant été signalé et validé par erreur comme objet de SPAM doit pouvoir être inversement rapidement signalé comme sain
- un domaine ayant été signalé et validé comme objet de SPAM à un moment donné possède une date de révision à laquelle il doit être à nouveau validé comme objet de SPAM
Scénario d'usage
- sur le site xyz, un utilisateur publie le nom d'un domaine comme étant objet de SPAM ; l'utilisateur explique sa motivation ; le domaine est alors signalé comme objet de SPAM ; ce site ne filtre pas encore ce domaine
- sur le site xyz, un administrateur fonctionnel vérifie que ce domaine est bien objet de SPAM (idéalement cet administrateur doit déontologiquement consulter le domaine incriminé pour vérifier) :
- si c'est le cas, le domaine est confirmé, sur xyz, comme objet de SPAM : xyz filtre alors ce domaine
- si ce n'est pas le cas, l'administrateur peut effacer ce domaine (?) (il motive la non recevabilité du signalement)
- le site xyz publie au format RDF une liste de tous les domaines signalés comme objet de SPAM (cette liste correspond en fait à sa liste des domaines qu'il a confirmé pour son usage comme étant objet de SPAM ; les domaines qui sont signalés (mais non confirmés) sur xyz comme objet de SPAM ne sont pas communiqués dans cette liste : il faut éviter par exemple qu'un domaine sain signalé à tord comme objet de SPAM ne se transmette à d'autres sites)
- un site abc vient lire la liste de xyz :
- si ce site n'est pas considéré comme sûr par abc, xyz ne traite pas ces informations
- si ce site est considéré comme sûr, tous les domaines publiés par xyz sont importés dans abc et deviennent des domaines signalés comme étant objet de SPAM
- l'administrateur technique de abc doit alors confirmer les domaines ainsi signalés
(imaginer un scénario ou un site propose à un autre site de lui fournir des domaines (push), permettant ainsi à un domaine d'être rapidemment signalé comme du SPAM dans un réseau de site toujours plus grand ?)
Cas d'utilisation
(rédigé selon la méthode UML des cas d'utilisation)
Déclaration d'un domaine comme étant objet de SPAM
Préalable : l'utilisateur est identifié sans quoi le cas est impossible.
- l'utilisateur demande au système la possibilité de déclarer un nom de domaine étant objet de SPAM
- le système demande à l'utilisateur de renseigner le domaine
- l'utilisateur renseigne le domaine
- le système vérifie que le domaine n'existe pas déjà
- le système stocke les données suivantes : le domaine, l'état du domaine (signalé), la date de déclaration et l'auteur de la déclaration
- cas alternatif : le système informe l'utilisateur que le domaine a déjà été déclaré (en précisant le déclarant et la date de déclaration) ; si l'utilisateur est habilité, le système propose à l'utilisateur de confirmer le domaine
Confirmation d'un domaine comme étant objet de SPAM
Préalable : l'utilisateur est identifié sans quoi le cas est impossible.
[à compléter]
Question : est-ce qu'un administrateur peut confirmer des domaines qu'il a lui-même déclarés ? Forcément dans le cas d'un wiki personnel. Cela peut-être aussi recommandable dans le cas d'une attaque massive où un seul admin est alors présent sur le site. On peut donc répondre oui à condition que cette information soit publiquement loguée sur le wiki.
Analyse d'un domaine avant publication
Préalable : l'utilisateur a validé son contenu et le système analyse chaque lien URL. Nous décrivons ici l'analyse d'un de ces liens.
- Le système vérifie que le domaine n'a pas été confirmé
- Le système vérifie que le domaine n'a pas été signalé
- Si le domaine a été confirmé, le système informe l'utilisateur que le contenu ne peut être enregistré ; éventuellement, le système enregistre cette tentative de l'utilisateur
- Le système enregistre le contenu
- Si le domaine a été signalé, le système informe l'utilisateur que le contenu est signalé comme du SPAM en signalant l'auteur de la déclaration et la date de la déclaration ; il demande à l'utilisateur de confirmer le contenu
- L'utilisateur confirme le contenu
- Le système enregistre le contenu
Vocabulaire 1 (brouillon)
[à jardiner]
Il faut tout d'abord gérer l'association d'un nom domaine à son utilisation à des fins de SPAM :
- il existe la notion de nom de domaine
- il existe la propriété de nom, d'un nom de domaine utilisé à des fins de spam :
Il faut aussi trouver un mécanisme social permettant d'être sûr que le nom de domaine déclaré n'est pas un site inexistant ou bien un site qui n'est pas utilisé à des fins de SPAM.
- il existe la notion de site déclarant ou confirmant un domaine utilisé par un spammeur
- il existe la notion de date de déclaration (doit permettre de lister les derniers domaines recensés)
- il existe la notion de site auxquel je fais confiance
- il existe
- soit la notion de domaine confirmé comme utilisé à des fins de spam
- soit la propriété de "nom confirmé" ?
- il existe la notion de domaine signalé comme objet de SPAM + date + auteur du signalement : idéalement, aucun automatisme ne devrait permettre de filtrer un domaine qui a été seulement signalé : il faut une action de confirmation par un administrateur fonctionnel du site qui reçoit cette information
- il existe la notion de domaine confirmé comme objet de SPAM + date + auteur de la confirmation : sur un site donné, cette notion s'applique à un domaine qui a été confirmé par un administrateur du site comme étant objet de SPAM ; cette notion ne devraient pas être exportée hors du site au sein duquel il a été confirmé
- il existe la notion de domaine signalé comme sain + date + auteur du signalement : un site peut avoir été signalé comme objet de SPAM par erreur ou par malveillance ; un nom de domaine qui n'a pas été renouvelé par son propriétaire spammeur, peut être réutilisé comme nom de domaine sain ; il faut donc pouvoir le déclarer sain ;
- il existe la notion de domaine confirmé comme sain + date + auteur de la confirmation : cette notion est similaire à celle de domaine confirmé comme objet de SPAM
- il existe la notion de date de révision de l'état d'un domaine : si un domaine a été déclaré comme objet de SPAM il y a deux ans, le nom de domaine peut avoir été abandonné par le spammeur et réutilisé par quelqu'un d'autre, il convient donc, après cette date, de réévaluer l'état de ce domaine : objet de SPAM ou sain. Cette date est déterminée de la manière suivante : soit on compte un an après la déclaration (le nombre minimal d'années nécessaires avant le renouvellement d'un domaine) ; soit on regarde dans le whois la date d'expiration du domaine
Vocabulaire au format N3
[à compléter]
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <#> .
:domain a rdfs:Class .
:site a rdfs:Class .
:name a rdf:Property .
:name a owl:InverseFunctionalProperty .
:name rdfs:domain :domain; rdfs:range rdf:Literal .
:saidToBeASpamOn a rdf:Property .
:saidToBeASpamOn rdfs:domain :site; rdfs:range :domain .
:confirmedToBeASpamOn a rdf:Property .
:saidToBeASpamOn rdfs:domain :site; rdfs:range :domain .
:revisionDate a rdf:Property .
:revisonDate rdfs:domain :domain; rdfs:range rdf:Literal .
Exemple d'utilisation
En
N3, ça pourrait donner quelque chose comme :
@prefix spam_ont: <http://wikini.net/spam_ont/> .
@prefix : <#> .
:ceSite a spam_ont:site .
:domaine1 spam_ont:name "foufounette.org" .
:domaine1 spam_ont:saidToBeASpamOn :ceSite .
:domaine1 spam_ont:confirmedToBeASpamOn :ceSite .
:domaine1 spam_ont:revisionDate "2006-05-08" .
En français, ça se traduit par :
sur le site internet "ceSite", le nom de domaine "foufounette.org" a été confirmé comme étant un objet de spam ; cette situation devra être réévaluée le 08/05/2006.
Pour ceux à qui ça ne dit pas grand chose, voici ce qui serait stocké comme triplet en base de donnée :
"
http://www.wikini.net/anti-spam/domaine1", "
http://wikini.net/spam_ont/name", "foufounette.org".
Pour intégrer ce vocabulaire à
WikiNi, il suffit :
- de stocker ce triplet en base,
- d'écrire une interface capable d'ajouter un domaine utilisé à des fins de SPAM
- d'écrire une fonction capable d'analyser, pour chaque lien contenu dans une page, si le domaine de ce lien n'est pas utilisé à des fins de SPAM
- en option : d'écrire une fonction capable de produire des listes de domaines en RDF
- en option : d'écrire une fonction capable de lire des listes de domaines en RDF
Ailleurs