Maurizio Codogno
CSELT, GCN
Nota: per comodità di coloro che non siano esperti di news, senza per altro volere inutilmente appesantire il testo dell'intervento, ho incluso un glossario contenente la definizione di alcuni termini e sigle usati. I rimandi vengono fatti mediante link ipertestuali, nella migliore tradizione HTML.
Nonostante la sua nascita sia ancora relativamente recente (l'idea venne lanciata due anni fa, in occasione di un altro convegno NIR-IT, e la nascita vera e propria avvenne nei primi mesi del 1995), la gerarchia di messaggi Usenet in lingua italiana it.* ha ormai superato la fase di nascita iniziale e ha raggiunto non dico certo la maturità ma comunque una certa robustezza. Sono ormai passati i tempi in cui i primi pochi newsgroup che erano stati creati ex officio dal GCN contenevano così pochi messaggi che in una giornata bastava meno di un quarto d'ora per leggerli tutti. Come le statistiche preparate dall'ottimo Stefano Suin, manutentore ufficiale della gerarchia it.*, mostrano, il traffico è salito a 2000 messaggi al giorno, in più di 100 newsgroup diversi, e tende ancora ad aumentare. Possiamo tranquillamente trattare da pari a pari con le altre gerarchie nazionali europee, e anzi per una volta siamo nel gruppo di testa quanto a conoscibilità ed interesse mostrato dai partner. Tanto per cambiare, solo la Germania è forse ancora al di fuori della nostra portata... ma ce la faremo a raggiungerla!
La nostra preoccupazione principale, però, è il non cercare di ottenere solo risultati quantitativi lasciando completamente da parte la qualità. La cosa non è così semplice a dirsi: la migliore definizione di Usenet che io abbia mai trovato è "anarchia dittatoriale" (oppure "dittatura anarchica", per chi preferisce vedere le cose da un altro punto di vista), e occorre sempre accertarsi di procedere sullo stretto crinale che divide i comportamenti definiti accettabili dalla gran maggioranza degli utenti da quelli sentiti come censura. L'evoluzione di Usenet nel corso di quasi vent'anni ha però portato alla politica che si pogrebbe chiamare "degli orticelli": chiunque può delimitarsi una sua piccola o grande zona che al momento sia libera, e coltivare in questo orticello le sue regole. Chi non fosse d'accordo non ha altro da fare che cercarsi un proprio orticello con le stesse caratteristiche di base.
Cosa significa tutto questo applicato alla nostra realtà? Ci sono due punti di vista distinti da considerare. Da un lato si può vedere la cosa da un punto di vista locale: esistono dei singoli gruppi in cui una o più persone si sono impegnate, all'atto della sua creazione, per effettuare una scrematura dei messaggi ivi contenuti. Queste persone sono i moderatori del gruppo, che gestiscono secondo un insieme di regole da loro stessi stabilite. Esiste però anche un secondo punto di vista, che vede nella sua globalità la gerarchia italiana, e consiste nell'emanare regole di buon comportamento, o netiquette, per consentire l'uso migliore, per quanto possibile, dei gruppi stessi. I due punti di vista portano a soluzioni completamente diverse, come vedremo nel seguito: per il momento il problema più sentito è stato il primo, e perciò sono già stati approntati degli strumenti pratici per l'ausilio alla moderazione: sta ora prendendo importanza anche il secondo punto, e accennerò pertanto agli sviluppi che il GCN sta considerando per l'implementazione.
Quando nel paragrafo precedente ho parlato di moderazione, ho in realtà semplificato parecchio quello che all'atto pratico si vuole avere. Mentre è infatti vero che dal punto di vista del protocollo NNTP c'è una precisa distinzione tra lo stato dei gruppi, che possono essere moderati oppure non moderati, negli anni d'utilizzo pratico si sono avute parecchie estensioni logiche del concetto di moderazione, che adesso sta a significare cose affatto diverse tra loro.
Il concetto di moderazione sopra indicato, dove tutti i messaggi vengono fisicamente letti ed approvati da uno o più moderatori, risulta spesso troppo oneroso, e può comportare notevoli ritardi nella propagazione degli articoli, quando il moderatore è assente per un qualunque motivo. In molti casi, ci si accontenta di un controllo molto più blando, in cui la maggior parte del lavoro viene fatta in maniera automatica, e il moderatore si limita ad intervenire personalmente in casi eccezionali. Si parla in questo caso di robomoderazione e retromoderazione: col primo termine si intende significare che il filtro della moderazione è totalmente automatico e si limita a bloccare articoli che non seguono delle regole formali prestabilite, mentre con il secondo si introduce il concetto secondo il quale tutti i messaggi cominciano a circolare, ma il moderatore si riserva in ogni caso il diritto di cancellare se necessario gli articoli che non rispettano il manifesto del gruppo, e nel caso di reiterate violazioni giunga ad impedire che il reo possa continuare a postare articoli nel gruppo in questione. Queste diverse tipologie di moderazione possono poi anche frammischiarsi tra di loro, rendendo ancora più ingarbugliata la situazione finale.
Risulta evidentemente chiaro che in Italia non stiamo inventando l'acqua calda, e che soluzioni a tutti questi problemi sono già state trovate da più persone. Sembrerebbe pertanto che la risposta sia semplice: prendiamo chiavi in mano un sistema già sperimentato all'estero, e inseriamolo pari pari da noi. Purtroppo si è visto che un approccio come questo è troppo semplicistico: ci sono infatti delle peculiarità proprie dell'approccio italiano alle news - se mi consentite un termine tanto ampolloso - che hanno richiesto delle soluzioni ad hoc, adattando e a volte ampliando le capacità del programma. Inoltre la cultura news degli italiani non è poi così ampia come negli altri paesi, e i programmi per la lettura delle news utilizzati non permettono tutta quella flessibilità necessaria per una gestione completa di un gruppo moderato. Occorreva pertanto adottare una filosofia "italiana", che consentisse di ovviare a tali limitazioni.
Si è così scelto per la gestione dei gruppi moderati di adattare un programma scritto da Bernhard Muenzer (mue@gsf.de) per la moderazione del gruppo soc.culture.midwifery. In realtà il programma era ancora in versione alfa: lo sviluppo del programma originale ha pertanto condotto a un risultato un po' diverso da quello che è capitato per la versione italiana, oltre naturalmente alla localizzazione. La struttura di base del "robottino", come viene familiarmente chiamato il programma, è rimasta la stessa: un file script, scritto in Korn shell, che assolvere a due distinte funzioni. Esso può infatti ricevere gli articoli inviati dagli utenti e smistarli a un moderatore, oppure processare i comandi inviati dal moderatore: esiste anche poi una terza opzione, per creare i file di configurazione necessari dal programma.
Come accennato sopra, il moderatore non deve affatto inviare tutto l'articolo, ma si limita ad inviare un comando al robottino, indicando se vuole accettare o rifiutare l'articolo stesso. Per fare ciò, il programma salva tutti gli articoli ricevuti e dà loro un numero di codice (per i curiosi, il codice è composto dalla data e dal numero del processo che tratta il file), trattenendoli in una directory temporanea. In caso di accettazione, il file viene spostato in un'apposita directory (che se si vuole, si può anche rendere disponibile via WWW); in caso di rifiuto, viene spostato ancora in un'altra directory, cosa utile per verificare eventuali contestazioni. La retichetta vuole che in caso di rifiuto il moderatore avvisi chi ha postato l'articolo del suo rifiuto e delle cause di esso: il robottino prevede che il testo inviato dopo il comando di rifiuto (separato dal comando stesso con una riga vuota) sia inviato al mittente, assieme al testo originale del messaggio. Non è però necessario scrivere tutte le volte un messaggio specifico: si possono infatti preparare delle lettere di rifiuto predefinite, e indicare semplicemente il nome della lettera corrispondente come causa di rifiuto. Questo è utile nel caso di classi di messaggi che purtroppo impazzano per Usenet, come le catene "Make Money Fast" e simili. Alcuni tipi di messaggi sono poi riconosciuti dal robottino e rifiutati da lui stesso: esempi tipici sono i file binari, oppure i crosspost selvaggi. Le euristiche utilizzate in proposito sono crude, ma efficaci: interessante la concezione di "selvaggio" per il crosspost, calcolata facendo il prodotto del numero dei gruppi in cui il messaggio è stato postato per il numero in cui il followup è inviato per default.
Oltre ai comandi di accettazione e rifiuto, ne esistono anche degli altri: è così possibile modificare il testo di un articolo inviato (anche se farlo è generalmente sconsigliato: tutt'al più si possono inserire all'inizio delle spiegazioni, scritte in modo tale da rendere chiaro che l'aggiunta è del moderatore); è anche possibile "fidarsi" del mittente, e fare in modo che da quel momento in poi tutti i messaggi provenienti da tale persona vengano immediatamente accettati; si possono infine chiedere informazioni sulla storia di un messaggio, e se necessario recuperarlo dall'inferno degli articoli rifiutati. Tra l'altro, non è necessario che il moderatore sia unico: si possono avere più moderatori per lo stesso gruppo, e il robottino si incaricherà di smistare ai vari moderatori i messaggi. Il moderatore può a questo punto anche "mettersi in vacanza", in modo che non gli arrivino più messaggi, oppure passare la palla agli altri, se è indeciso sull'effettivo valore del messaggio.
Fin qui il programma originale. A parte la traduzione in italiano dei messaggi di rifiuto e delle istruzioni ai moderatore, un primo utilizzo del robottino sui gruppi it.annunci.vari e it.faq mi ha fatto scoprire alcune manchevolezze, che sono state prontamente tappate. D'altra parte, servirà pure a qualcosa avere a disposizione i sorgenti dei programmi!
La cosa più semplice da modificare è stata la possibilità di moderare gruppi binari. Ho dovuto infatti aggiungere un parametro per evitare il blocco sui messaggi binari oppure MIME, lasciando nel contempo tutti gli altri controlli. Ho inoltre aggiunto la possibilità di aggiungere automaticamente alla fine di ogni articolo una frase (come una specie di signature), in modo che il moderatore possa aggiungere delle "istruzioni per l'uso".
Più interessanti certamente sono le altre modifiche, legate ai gruppi robo- e retromoderati. In entrambi i casi, infatti, il moderatore non riceve i messaggi, che vengono immediatamente smistati. In primo luogo, è stato così necessario modificare il robot (che già prevedeva una sorta di robomoderazione) in modo che il comportamento di default sia l''approvazione dell'articolo, e non il suo rifiuto. Il moderatore ha poi due nuovi comandi a disposizione: egli può infatti aggiungere o togliere persone da una lista dei "cattivi", persone cui si vuole momentaneamente impedire la possibilità di scrittura nel gruppo, oppure può cancellare un articolo già apparso. La cosa in questo caso è infatti un po' più complicata: infatti come si sa è possibile cancellare direttamente un articolo solo se si è colui che l'ha scritto: però in questo caso lo "scrivente" è in realtà il robot, quindi è lui che deve inviare il comando di cancellazione. Ma come fa il moderatore a scoprire qual è il codice dell'articolo, visto che questo non gli è stato inviato? Beh, il trucco c'è. Il Message-ID dell'articolo, infatti, è costruito in maniera tale da contenere al suo interno il famigerato codice. Et voilà!.
Per quanto riguarda le soluzioni globali, non è stato ancora messo in pratica nulla, anche se a breve termine si pensa di implementare presso serra.unipi.it, il nodo centrale per le news in Italia, un meccanismo automatico mutuato da quello utilizzato nei gruppi francesi, e detto convenzionalmente newsbot. Il programma funziona come "channel" news: in pratica, quando gli articoli news arrivano a serra, vengono anche dati in pasto a questo robot che controlla se essi corrispondono alle linee guida stabilite. In caso contrario, viene inviato un messaggio di cancellazione, assieme con un messaggio al mittente che lo avvisa della cancellazione, dandogli inoltre alcuni suggerimenti su come ovviare all'inconveniente.
Le linee guida che sono state stabilite nell'ultima riunione dei News Administrator italiani, tenutasi lo scorso 5 novembre 1996 a Milano, sono in realtà molto poche: il blocco dei messaggi binari scritti al di fuori della gerarchia it.binari.*, dedicata apposta a tali file, e quello dei messaggi che si possono definire spamming, sia con crosspost multiplo che se postati singolarmente su più gruppi. Si pensa di usare valori soglia ragionevoli dal punto di vista dell'occupazione di spazio - e quindi irragionevoli per molti utenti, ma non si può pretendere tutto... - per la dimensione di un file binario. Visto che la dimensione media di un articolo è circa 4 KB, quello dovrebbe anche essere il valore oltre al quale un file binario è considerato realmente tale. Quanto al numero di gruppi che fanno toccare la soglia di spam, il limite attuale è stato posto a dieci, anche se alcuni amministratori lo vorrebbero portare a cinque. In questo caso, però, si avrebbero altri problemi, dato che alcune FAQ sono postate su molti gruppi. La soluzione definitiva consisterà probabilmente nell'aggiungere delle "scappatoie" riconosciute dal newsbot e che permettano a quei pochi messaggi che lo richiedono di sfuggire al fato della cancellazione.
Molte delle cose che ho detto in questo articolo stanno sicuramente suonando come censura alle orecchie di alcune persone. Ritengo pertanto opportuno terminare questa presentazione con alcune spiegazioni ulteriori sulla filosofia alla base di queste scelte.
Innanzitutto, è opinione assai diffusa su Usenet che se un gruppo è moderato, il moderatore è un "ducetto". Esistono delle procedure formali che permetterebbero di far decadere un moderatore nelle principali gerarchie mondiali, ma all'atto pratico non mi pare di ricordare un singolo caso in cui siano state applicate. Un moderatore può inserire nel manifesto del gruppo una procedura democratica di sfiducia, e questo è in effetti applicato in alcuni gruppi controversi, ma non c'è nessun obbligo di fare ciò. Il GCN, per quanto riguarda i gruppi italiani, ha portato tale situazione alle estreme conseguenze: se un gruppo di persone non è soddisfatto dell'operato di un moderatore, può chiedere la creazione di un altro gruppo con praticamente lo stesso nome e lo stesso manifesto formale. Tale richiesta avrà lo stesso iter di quella originale (discussione e votazione), e se il voto passerà ci saranno due gruppi con lo stesso manifesto ma moderatori diversi. Sarà poi il mercato... scusate, l'utenza stessa a privilegiare uno oppure l'altro gruppo. Insomma, la dittatura del moderatore può sempre venire aggirata in questo modo, e la sua possibilità di censura rimane pertanto invalidata all'atto pratico.
La situazione per quanto riguarda il newsbot è più delicata, e conviene che sia preceduta da una precisazione che molto spesso viene dimenticata. Nonostante quanto possa apparire a un osservatore esterno, il GCN non ha alcun potere impositivo sulla gerarchia it.*. Se un server news o anche un semplice utente vuole crearsi il gruppo it.insulti.creativi, ad esempio, non ha che da inviare il messaggio di controllo per la sua creazione - vabbé, supponiamo che sappia come farlo, il che non è certo cosa comune - e poi mettersi d'accordo con altri server in modo che essi accettino il messaggio di controllo e creino il gruppo stesso. Insomma, a casa propria ognuno fa ciò che vuole: il GCN non potrà fare altro che inviare un altro messaggio in cui si dice "Attenzione! Il gruppo it.insulti.creativi non è stato creato secondo le regole della gerarchia it.*, e perciò vi invitiamo a cancellarlo, con il comando...". (Nota: non viene inviato direttamente il messaggio di cancellazione). D'altro canto il GCN è emanazione degli amministratori news italiani: essi si fidano di noi e quindi processano automaticamente i messaggi di controllo da noi emessi, sapendo che seguiamo certe regole. Se però questi chiedono delle regole aggiuntive, come quelle indicate nella sezione precedente, noi abbiamo il diritto/dovere di implementarle. E l'amministratore che non è d'accordo con tali regole, vi chiederete? Nessun problema: visto che la cancellazione di un articolo avviene sempre per mezzo di un messaggio di controllo, il newsbot è scritto in modo da indicare chiaramente la paternità dei suoi messaggi di cancellazione, e un server è sempre libero di ignorare tali messaggi.
Ricordo infine che non si intendono assolutamente porre limitazioni globali basate sul contenuto semantico degli articoli, né si vede come si potrebbero fare senza leggere gli articoli stessi: non si pensa nemmeno di cercare all'interno dell'articolo parole da censurare o cose simili. Gli unici criteri utilizzabili sono quelli che riguardano l'articolo come un tutto (dimensione, numero di copie esistenti, formato di codifica...) Questo per assicurare la libertà di parola. È sufficiente? Non ne sono certo. Però almeno ci sono regole chiare, e c'è sempre la possibilità di utilizzare altre gerarchie, o crearsene una nuova, nel più puro spirito anarco-dittatoriale...