Ce vocabulaire entend permettre à des administrateurs de sites ouverts à l'expression des internautes 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.]
Cas d'utilisation
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 :
- 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 ?)
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