Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen
Lies, damn lies and statistics

Premessa: in questo post non voglio fare nessunissima insinuazione

Con cadenza mensile Net Applications rilascia alcune statistiche di market share che spesso sono spunto di discussione. Ci sono alcuni blogger che con la stessa cadenza dedicano un post intero all’analisi di tali statistiche. Considerando che tali statistiche siano poco indicative dello status quo in quanto poco affidabili, mi faccio la seguente domanda: com’è possibile che ci sia una variabilità significativa quando si confrontano le statistiche di Net Applications con quelle di altri servizi equivalenti? Cito Wikipedia:

  Windows OSX Linux
Net Applications 88.26% 9.93% 0.83%
W3 Counter 88.89% 5.16% 2.06%
XiTi Monitor (*) 93.30% 4.46% 1.20%
OneStat (*) 93.72% 3.66% 0.47%
Valore mediano 91.10% 4.81% 1.02%


(*) XiTi e OneStat riportano i dati di dicembre 2008 a differenza di Net App e W3 che riportano quelli di gennaio 2009.

Net Applications sembrerebbe rilevare una percentuale doppia rispetto al valore mediano della share di OSX. Similmente W3 Counter sembrerebbe spostato “significativamente” verso Linux.

Curioso.

-quack

Pubblicato domenica 8 febbraio 2009 alle 1:05 AM - 44 commenti so far
Archiviato in: Cazzate

UAC: il buono, il brutto e il cattivo

Per motivi di tempo e perché mi aspettavo che la questione si sarebbe conclusa nel migliore dei modi a stretto giro di posta, mi sono astenuto da intervenire sulla debacle dei nuovi setting di default di UAC in Windows 7.

Comincio dalla fine: i nuovi setting di default, nonostante la mia tendenza paranoica, mi piaciono parecchio. L’obbiettivo delle modifiche apportate in Windows 7 è quello di cercare di distinguere le azioni iniziate dall’utente che clicca su qualcosa, da quelle delle applicazioni che impersonano l’utente. La questione è un po’ il Sacro Graal dell’informatica: chiunque ci riuscisse avrebbe inventato il primo sistema operativo a prova di malware, moderna macchina del moto perpetuo informatico. Gödel per fortuna ci dice che ogni sforzo è vano: se non si può capire a priori se un programma termina, figuriamoci se si può capire a priori cosa realmente fa il prograUACmma e con quali intenzioni. But I digress…

In Vista molto spartanamente è stato diviso l’amministratore in due entità separate e tutti i task che richiedono permessi amministrativi richiedono un prompt di conferma o la password. Questo significa che anche cambiare il fuso orario richiede un prompt UAC. Qualcuno però abituato ai silenzi di Windows XP ha dipinto la questione in maniera molto peggiore della realtà, come se vivesse a confine tra due fusi orari e avesse la necessità di cambiare questi importanti setting di sistema ogni 5 minuti. In Windows 7 Beta si è scelta un’altra via, evoluzione di tanti esperimenti fatti nelle build intermedie: è stata creata una lista di applicazioni di sistema (white-list) che a livello UAC di default consente all’utente loggato di auto-elevarsi ad amministratore senza nessun prompt, ovviamente a patto che l’utente appartenga al gruppo degli amministratori. L’intento, come citato sopra, è di dare ai vari pannelli di controllo la possibilità di cambiare i setting di sistema senza necessariamente disturbare l’utente.

L’idea della whitelist non è una grandissima novità in quanto anche su Unix esiste un meccanismo simile preso in considerazione anche prima del rilascio di Vista; pero tale meccanismo ha un punto debole che nell’ecosistema Windows non è sostenibile: qualsiasi amministratore può aggiungere/rimuovere applicazioni dalla whitelist. Nel passaggio tra XP a Vista il meccanismo sarebbe stato ampiamente abusato da tutti i produttori di applicazioni pigri (e quindi tutti) che tra rendere l’applicazione capace di girare senza permessi di amministratore e settare un flag sull’eseguibile avrebbero scelto la seconda senza pensarci due volte considerando che l’installer gira sempre con permessi amministrativi. L’idea è stata perciò accantonata con Vista e ripresa con Seven usando un espediente semplice e geniale: la whitelist è sigillata con una firma digitale e quindi non è manipolabile in nessun modo.

La whitelist rilasciata con la beta è ben lungi da essere perfetta ma tra le tante applet quella che ha dato più nell’occhio è stata l’applet che gestisce i setting UAC. Siccome l’applet esegue un’auto-elevazione senza altre misure di protezione è stato possibile scrivere uno script che emula la pressione di alcuni tasti in sequenza e disabilitare UAC automaticamente. Rafael Rivera ha pubblicato un post a riguardo che è rimbalzato in tutta la blogosfera catturando una notevole attenzione mediatica; Rafael e tanti altri proponevano di rimuovere l’applet UAC dalla whitelist ed in tal modo qualsiasi tentativo di cambiare il setting UAC dall’esterno avrebbe richiesto un ulteriore prompt mettendo in guardia l’utente. Però come in un dialogo tra muti e sordi la risposta ufficiale ‘by design’ è suonata un pochino stonata. Il ping pong tra Jon DeVaan e i vari blogger ha assunto connotati surreali fino a quando una nota di ‘retromarcia’ è apparsa sul blog Engineering Windows 7 portando finalmente giubilo, pace e serenità. Se si legge tra le righe si comprende bene qual’era il vero problema e la giusta soluzione: il problema non stava nel fatto che cambiare i setting di UAC non richiedesse nessun prompt ma che l’applet fosse pilotabile da altre applicazioni; individuato il problema (la pilotabilità) la soluzione è diventata ovvia: anziché usare il secure desktop basta aumentare il livello di integrità in cui l’applet gira per impedire che riceva messaggi dalle applicazioni desktop che girano sotto l’utenza normale. Basterebbe questo per risolvere il problema e rimuovere UAC dalla whitelist non diventa più necessario; quest’ultima cosa è stata comunque fatta più per motivi psicologici (su cui concordo pienamente!) che per necessità contingenti.

La cosa più buffa di tutta la questione è stato vedere gente che non sa neanche cos’è un security boundary sostenere con forza l’una o l’altra posizione o elargire consigli a destra e a manca.

C’est la vie

Linkografia a futura memoria:

Windows 7 auto-elevation mistake lets malware elevate freely, easily
List of Windows 7 (beta build 7000) auto-elevated binaries
Second Windows 7 beta UAC security flaw- malware can silently self-elevate with default UAC policy
Update on UAC
Is UAC broken in Windows 7 beta-
Microsoft’s worst nightmare- Windows 7 deemed less secure than Vista
Permanent Link to UAC in 7- Exponential Silent Attack Vector Multiplier
UAC Feedback and Follow-Up
Users prevail- Microsoft changes Windows 7 UAC control panel behavior to address security flaw
Microsoft backtracks on Windows 7 UAC, pretends it was all part of the plan

-quack

P.S. il mio consiglio: se non usate un antivirus, lasciate pure i setting di default di Windows 7 Beta, siete abbastanza accorti da evitare di far girare certa robaccia sul PC. Se usate un antivirus…. è uguale!

Pubblicato venerdì 6 febbraio 2009 alle 11:20 PM - 62 commenti so far
Archiviato in: Windows, Security

The myth of multitasking

willreturn Pensavo fosse SADAE ma invece era multi-tasking. Ho letto da pochissimo questo libercolo che si manda giù in minuti.

Lo consiglio vivamente ha fatto completa breccia nel mio pensiero.

Io ho cominciato seriamente a prendere provvedimenti, cominciando con il comprare un disco orario come quello raffigurato da appendere fuori dalla porta e obbligare tutti a rispettarlo.

O cominciare a predicare come stavo peggio quando ero un ex-multitasker ex-switchtasker.

-quack

Pubblicato giovedì 5 febbraio 2009 alle 10:52 PM - 8 commenti so far
Archiviato in: Cazzate, Recensioni

Ancora guai: WHS restore

La serie dei guai non è finita, ma per fortuna comunque si è risolto tutto per bene. Siccome stavolta la colpa non è del laptop ma del Restore CD di Windows Home Server, non aggiungo questa nota in calce a tutte le altre.

Antefatto: ho provato a pasticciare con i driver bluetooth di DELL forte del fatto che tra Windows System Restore e il backup di Windows Home Server avessi due reti di protezione molto robuste. La prima mi ha però dato qualche problema e ho dovuto fare un restore del laptop via WHS. Poco male visto che non avevo mai provato il restore su un PC a 64 bit.

Fatto: masterizzo il Windows Home Server Restore CD, riavvio, BSOD subito dopo il lancio del sistema. Cerco online le origini del problema che vengono descritte come “unrecognized boot device”. Sapevo che il supporto AHCI non è proprio al 100% trasparente ma non pensavo che il restore CD non supportasse AHCI (in giro leggo che una nuova versione potrebbe aver risolto il problema, ma io non ho provato). Tra scaricare 200MB di roba che quando vai di fretta la connessione scende a 13KB/sec e disabilitare temporaneamente AHCI ho preferito la seconda. Modifica del parametrillo nel BIOS, riavvio e back in business. Fino al momento del riconoscimento dei driver:

WHSRestore1

La scheda di rete non è riconosciuta di default e qualsiasi tentativo di installare i driver, che sono appositamente copiati su un pendrive, fallisce miseramente. Clicco Continue sperando che ci siano altre soluzioni e mi infilo in un vicolo cieco:

WHSRestore2

Non si può tornare indietro e sono costretto a riavviare. Cosa che non sarebbe molto tragica se non per il fatto che WinPE ci mette circa 6 minuti a fare il boot da CD e che al secondo reboot ho cliccato di nuovo Continue accidentalmente mentre toccavo il sensibile touchpad in maniera chiaramente troppo decisa ed incazzata. Terzo riavvio e ancora bisogna cercare il modo per far riconoscere la scheda di rete.

Ravano in giro e scopro l’inghippo di Colombo: i driver sul PenDrive sono a 64-bit, l’immagine WinPE è a 32: non funzioneranno mai. Però basta scaricare i driver giusti, scompattarli e metterli sul PenDrive che tutto funziona alla perfezione.

Riflettendo a posteriori tutta questa manfrina, nel momento gioco forza tragico in cui si ricorre ad un restore da server, con le dovute pressioni psicologiche non è proprio il mondo ideale in cui vorrei vivere. Parafrasando i latini si vis restorem, para backuppum. Messomi alla ricerca di una migliore soluzione sono incappato in questa wiki-guida che spiega come creare una piccola partizione da cui avviare il meccanismo di restore.

La parte più antipatica si è rivelata quella di configurare le opzioni via EasyBCD: sul mio PC ogni tentativo di usare la partizione giusta per la voce di boot si rivelava inutile. Nel BCD ci finiva una entry incompleta. Mi sono rassegnato ad aggiungere a mano via command prompt i due parametri mancanti (osdevice e device) ed alla fine sono arrivato al risultato voluto. Se a qualcuno interessa posso mettere in download lo script che si occupa di fare tutto in automatico senza dover scaricare software di terze parti.

Il test è andata in maniera più che ottima: ho scoperto che a differenza del boot da CD, il boot da partizione supporta l’AHCI. I motivi alla base del mistero non li conosco e non mi interessano. La seconda bella novità è che essendo la partizione abilitata in scrittura una volta lanciato il driver della scheda di rete da PenDrive viene automaticamente installato e al successivo riavvio il PenDrive diventa superfluo. Posso ritenermi completamente soddisfatto, fino alla prossima disavventura.

In tema di Backup/Restore segnalo la possibilità di registrarsi per ottenere gratuitamente Acronis True Image 10 Personal Edition molto utile per travasare partizioni di sistema da un disco all’altro. Ricordando ovviamente che versione vecchia fa buon brodo e a software donato non si guarda in bocca.

-enjoy

Pubblicato mercoledì 4 febbraio 2009 alle 8:50 PM - 10 commenti so far
Archiviato in: Link, Cazzate, Backup

Lambdas

Lo sapevo che prima o poi sarei diventato addicted:

        public delegate void AsyncVoidMethodHelper();
 
        static void RunAsync(int timeout, AsyncVoidMethodHelper method)
        {
            IAsyncResult result = method.BeginInvoke(null, null);
            result.AsyncWaitHandle.WaitOne(timeout);
        }
 
        static void Main(string[] args)
        {
            string result = String.Empty;
 
            RunAsync(50, delegate
            {
                Thread.Sleep(10);
                Console.WriteLine("you should see this");
                result = "a";
            });
 
            RunAsync(50, delegate
            {
                Thread.Sleep(100);
                Console.WriteLine("you should _NOT_ see this");
                result = "b";
            });
 
            Console.WriteLine("result should be 'a'. => '{0}'", result);
 
 
        }

Con solo 2 righe di codice si può eseguire qualsiasi blocco in maniera asincrona e con un timeout predefinito. Ma la fantasia può essere lasciata libera di correre come un cavallo. Fichissima la possibilità di giocare con lo scope delle variabili (assegnazione di result). Stilisticamente perfetto: sintetico per chi lo scrive, doloroso per chi lo deve mantenere.

-quack

Pubblicato lunedì 2 febbraio 2009 alle 6:40 AM - 52 commenti so far
Archiviato in: Codice