Telepresenza? Magari…

Cringely spesso ci azzecca. Spero che ci azzecchi in particolare con questo articolo sulla telepresenza. Io abito a Pisa. Anni fa, quando ho fatto questa scelta, sembrava che il telelavoro fosse alle porte e che in breve tempo gli spostamenti, almeno per certe attività, sarebbero stati pochissimi. Così ho scelto di non spostarmi a Roma o Milano, le due città in cui di fatto c’è la maggior parte del lavoro nel settore della sicurezza (che, DPS a parte, interessa ancora quasi solo a grosse aziende e aziende finanziarie). In effetti, posso fare molto lavoro senza muovermi, ma c’è una cosa che ancora non si riesce a fare da remoto, e cioè le riunioni. La teleconferenza è tuttora un’esperienza mediocre: a parte la qualità delle comunicazioni e delle implementazioni che ho usato, per cui spesso la linea cade, o le persone si sentono poco o sono fuori campo, senza dubbio nell’incontro faccia a faccia la sensazione è diversa. Siamo abituati a utilizzare e a leggere anche il linguaggio del corpo e le espressioni facciali, e di tutto questo nella teleconferenza non rimane traccia, al massimo l’inflessione della voce. Così le riunioni “serie” continuano a dover essere faccia a faccia.

La mia esperienza peggiore da questo punto di vista è stata la seguente giornata, ormai di parecchi anni fa ma ancora me la ricordo: partenza in orario antelucano da Pisa, Cisa, arrivo a Milano verso le 8.30 alla sede del mio committente (una società di consulenza). Attesa di quasi un’ora perché il mio riferimento aveva alcune faccende da sbrigare e per sicurezza mi aveva fatto arrivare un po’ in anticipo… Partenza per Torino (lavori sull’autostrada), arrivo dal cliente, attesa perché il cliente era ancora impegnato con l’incontro precedente. Incontro con il cliente: circa venti minuti, passati essenzialmente a dire: “allora facciamo come deciso al telefono”. Saluti. Ripartenza per Milano, attesa di un’altra ora perché all’arrivo il mio committente ha trovato una cosa urgente da sbrigare. Altro quarto d’ora fra me e il mio committente, essenzialmente per ripeterci: “allora facciamo come concordato per telefono e stamattina dal cliente”. Saluti. Partenza, Cisa, rientro in tardo pomeriggio a Pisa. Una giornata buttata (a parte i costi e la fatica) per due incontri di un quarto d’ora, inutili nella sostanza perché ripetizioni di cose già dette. Mentre riflettevo sul modo idiota in cui avevo buttato la giornata, mi sono allora reso conto che c’è comunque una differenza fondamentale fra dirsi le cose da remoto e dirsele di persona, soprattutto se ancora non ci si conosce: guardarsi negli occhi fa capire molte cose più di una telefonata o di una videoconferenza.

Ho avuto occasione di parlare con alcune persone di Cisco che, chiacchierando, mi hanno magnificato il loro prodotto di telepresenza. La differenza essenziale rispetto a una videoconferenza, a parte la qualità dell’immagine e i costi 😉 , sarebbe che dà effettivamente la sensazione di essere tutti seduti intorno allo stesso tavolo. Per questo, non conta solo la parte informatica ma anche l’ambiente. Ecco, se dovessi dire una cosa per la quale è utile la banda “molto”larga, questa è una. Ma anche qui, il problema è soprattutto di qualità, più che di quantità: la banda offerta deve essere realmente disponibile e garantita, se un sservizio di questo tipo non è affidabile o perde di qualità, perde anche di senso. Riuscirà a sostituire tanti viaggi “inutili”?

Ad esempio, in un’attività di audit spesso un buon 80% del tempo lo si passa ad intervistare persone. Se questa attività, che è essenzialmente di “chiacchiere” potesse essere fatta da remoto sarebbe un grande risparmio, ma è chiaro che è anche un’attività che richiede di stabilire un rapporto abbastanza diretto con l’intervistato. Si potrà fare con la telepresenza, o comunque è una questione di pelle, e serviranno comunque incontri di persona? Naturalmente, nell’ipotesi che scenda di prezzo e che si diffonda almeno come servizio nelle varie città, se non come strumento aziendale o addirittura personale…

Nel frattempo io continuo a viaggiare fra Pisa, Milano e Roma, perché in Toscana, dopo tanti anni, di attività sulla sicurezza per ora ne ancora ho trovata poca, ma di trasferirmi non ne ho voglia, perché la Toscana è bella…

Posted in Varie | Comments Off on Telepresenza? Magari…

Senza parole: Microsoft compra i voti per essere standard

Da PCWorld. Il problema non è il software: sono le pratiche commerciali.

Posted in ict, Varie | Comments Off on Senza parole: Microsoft compra i voti per essere standard

Vulnerabilità in postfix?

Tempo fa ho preso postfix come esempio di programmazione sicura, così mi ha un po’ spiazzato la notizia pubblicata da Heise titolata: “Postfix mail servers under pressure“. Poi ho letto l’articolo ed ho capito: il problema è legato ad un modulo policyd, un modulo per il graylisting che non è parte di postfix ma è sviluppato da terzi. È chiaro che moduli aggiunti possono tranquillamente avere qualità diversa dal codice originale. È una cosa della quale i creatori di software modulari si lamentano sempre, in quanto poi i difetti vengono associati, come in questo caso, al programma. Al riguardo ricordo in particolare le sfuriate sulle mailing list di Bernstein, autore di qmail. Tuttavia, c’è un altro punto che mi lascia perplesso: guardando le statistiche su Sourceforge del progetto policyd, si vede che di fatto il codice ha cominciato ad essere scaricato due o tre mesi fa. Tutto, dalle statistiche alle maling list al Changelog, sembra indicare che è un progetto molto giovane, sviluppato negli ultimi tre mesi. Invece, andando a leggere il codice o le statistiche della distribuzione Debian, risulta che il progetto è attivo addirittura dal 2004, e che Debian lo segue da metà del 2005. In effetti, la maggior parte dei link che si trovano su policyd riguarda Debian. Qual’è il problema? Nello scegliere quale software utilizzare, in particolare software di sicurezza per un servizio pubblico come l’SMTP, la valutazione dovrebbe comprendere la stabilità e la storia di “non insicurezza” del software. Cosa bisogna allora considerare: che è un pacchetto sviluppato e utilizzato da due anni, e che questa è la prima segnalazione di sicurezza, o che di fatto è un pacchetto sviluppato negli ultimi tre mesi e quindi da considerare ancora poco testato?

Il problema del dover utilizzare soluzioni ancora poco stabili era già chiaro per altre tipologie di software, ma sta diventando sempre più frequente anche per prodotti di sicurezza. In mancanza di lunghi periodi di test e verifica della stabilità, è ancora più necessario spooerire con una buona progettazione del software, prima ancora che con la scrittura di buon codice. Diventa quindi ancora più importante che non solo il software venga accuratamente progettato, ma che la logica del progetto sia descritta in modo convincente nella documentazione. Di nuovo, il Postfix originale aveva ben documentato la propria logica e i motivi per cui quel disegno era sicuro, e il tempo gli ha dato ragione: essere in grado di descrivere perché il codice è sicuro è una garanzia che il progetto è stato ragionato, mentre indicare seplicemente che il codice è stato auditato dice veramente poco sulla reale qualità.

Per concludere, l’articolo parla anche (in modo più appropriato per il titolo) di un problema di connessioni terminate in modo anomalo che starebbe interessando particolarmente i server SMTP postfix. La possibilità che un numero elevato di connessioni terminte in modo anomalo possa mettere in crisi un server è un problema (anche di DoS se il server è pubblico) che in sè non ha soluzione. Tuttavia, codice e configurazione anche qui possono fare differenza sull’entità del problema. Qui, come segnalato da Heise, vengono indicati alcuni miglioramenti alla configurazione di postfix che possono aiutare ad affrontare eventuali difficoltà.

Posted in Sicurezza | Comments Off on Vulnerabilità in postfix?