A Ovest Di Paperino

Rieccomi!

>è proprio quello che ti facevo notare: nel precednte articolo si trattava solo di tue
> opinioni, non della dimostrazione formalmente corretta di una tesi.
>Faccio un esempio: il fatto che un sistema operativo sia integralmente
> seguito dallo stesso team di persone ed un'altro sia seguito
>da una moltitudine più eterogenea di persone non rende di
>per se il primo migliore o più sicuro. Se tu affermi questo
>stai semplicemente esplicitando la tua opinione.

Attenzione, ho messo l'accento sul fatto che

a. il team di persone è controllato da un'unica entità che garantisce che le persone abbiano una conoscenza adeguata dei problemi legati alla sicurezza, sia che scrivano kernel, sia che scrivano campo minato.

b. tali procedure abbiano portato a risultati concreti e misurabili

> Questo dipende da quanto e intrinsecamente sicuro
> (o insicuro) l'airbag in questione, e anche da quanto lo
> è nel suo contesto. Un'automobile con l'airbag, ma
> strutturata nel resto in maniera non adatta può
> capovolgere la funzione dello stesso airbag
> trasformandolo in uno strumento pericoloso.

Nel campo dell'informatica la relazione tra ricerca e implementazione è molto più stretta per il fatto che implementare un algoritmo è meno complicato che implementare un processo di produzione meccanica. Il fatto che molte misure di sicurezza provengano da laboratori di ricerca dovrebbe dare una certa garanzia sulla loro efficacia.

Detto questo è chiaro che se gli airbag sono 'implementati' male potrebbero essere più pericolosi; ma in linea di massima quando si parla di airbag lo si fa facendo riferimento all'implementazione canonica. È per questo che - una volta che si dimostra l'efficacia di una misura - tutti i produttori si affrettano a implementarla pena la perdita di quote di mercato.

Trasponendo nel campo dell'informatica: in passato c'è stato qualcuno che in cerca di gloria si è arrampicato sugli specchi cercando di mostrare come il flag /GS introducesse una vulnerabilità (il caso fece scalpore); nel dimostrare la sua tesi tirò fuori una procedura estremamente complessa perdendo di vista il fatto che il flag /GS aiuta a proteggere da buffer overrun e che nel suo stesso esempio - se il flag /GS fosse stato disabilitato - compromettere il codice sarebbe stato estremamente più semplice. Questo nonostante nessuno avesse mai detto che tale misura fosse impenetrabile.

È per questo che la tabella che riportavo nel post precedente fa vedere che anche nel mondo Linux tali misure vengano prese in considerazione (anche se sono leggermente indietro). Quella di dire che 8 airbag potrebbero essere più pericolosi di niente mi sembra una distensione del ragionamento troppo filosofica e facendo discorsi 'filosofici' si perde spesso il lato pratico della questione legato a concetti più banali di 'convenienza'. Un mio amico dice: non affannarti a cercare di proteggere la tua rete wireless in maniera assurda; sniffa intorno e se c'è più di qualcuno che non ha neanche attivato il WEP sei apposto già con WPA. Alla fine il discorso fila, no?

> L'analisi statistica ci da un'informazione solo su cosa è
> più probabile, ma si tratta di una valutazione
> puramente empirica. Di per se non dimostra una tesi.

Verissimo, ma nell'analisi statistica c'è una misura che si chiama correlazione. Quanta correlazione c'è tra sicurezza dell'OS e alcuni dati? Tantissima ed in passato tale correlazione è stata usata per dimostrare la tesi opposta (*). Cito, tra i tanti numeri, il fatto che nei primi 90 giorni di vita della mia distro preferita Ubuntu 6.06 (quella considerata LTS), sono stati patchati 71 bachi di sicurezza, 27 dei quali classificati Highly Critical. Nello stesso periodo in Vista tale numero corrisponde a 1. Rapporto bachi di sicurezza Vista:Ubuntu = 1:71; rapporto bachi Highly Critical = 1:27. Se non ci fosse correlazione tra causa (SDL) ed effetto (bachi) come si spiegherebbero questi numeri? A meno che non si voglia credere a priori che MS non sia capace di rovesciare il tavolo a suo favore , come Oracle ha sempre creduto (vedi nota sotto)

> Potrei dirti che sono immortale, ma per dimostrartelo
> in modo esclusivamente empirico
> occorrerebbe tutta l'eternità.

Ahiahiahiahi. Deduco che non hai mai provato a spiegare a quelli che credono nella teoria dei 'ritardi' sulle estrazioni del lotto che - se avessimo l'eternità a disposizione - ci sarebbero numeri che ritarderebbero anche per mille estrazioni. Dal punto di vista statistico è dimostrabile; dal punto di vista empirico no, ma ciò non rende la verità meno vera. Lo stesso Gödel aveva dimostrato che ci sono teoremi veri ma che non sono dimostrabili. .

Nel caso dei SO le cose sono addirittura più semplici. Come gli esseri umani hanno una vita limitata. Il più longevo - windows XP - è durato "6 anni" (più supporto). In quell'intervallo di tempo - se guarda caso XP fosse stato sempre il sistema operativo più sicuro - a quest'ora la discussione non avrebbe avuto neanche luogo.

> Il resto prosegue con opinioni personali dell'autore o
> comunque soggettive (essendo buono non dirò "inquinate").
> Mi sono preso la libertà di ometterle, ma su richiesta posso approfondire.

Spero tu non consideri i numeri di una fonte come Symantec inquinati (http://www.internetnews.com/ent-news/article.php/3607456, link provided by Blackstorm) ma volentieri. Sono davvero molto interessato visto il tono della discussione davvero cordiale.

-quack!

(*) Questo mi ricorda un episodio di ~7 anni fa.

Oracle ha sempre giustificato il prezzo esoso del suo database portando a supporto la tesi che il loro database - misurato attraverso i benchmark standard del TPC - fosse molto più veloce di MS SQL Server; andandoci giù pesante un po' come fa Apple (solo che nel loro caso i numeri - entità misurabile - erano a chiaro favore di Oracle). Nel 2000 accadde l'"improbabile": il team di SQL server, in uno scatto di orgoglio, tirò fuori il database più veloce del mondo. La risposta di mr. Oracle? La velocità non è tutto in un DataBase... (rumore di unghia contro gli specchi)