Web Log di Raffaele Rialdi

Raf on Channel9

Raffaele Rialdi — Wed, 03 Feb 2010 10:38:53 GMT

Missione conclusa con successo. Ieri sera Pietro mi ha intervistato in un breve video in cui racconto la costruzione di un sensore per Windows 7 realizzato per il workshop UGIdotNET tenutosi nel pomeriggio nell'auditorium di Microsoft Italia. La registrazione del video è su Channel9.
Nel video c'è una rapida overview della costruzione del dispositivo, il firmware del microcontrollore, il device driver per Windows ed infine l'applicazione che lo utilizza.

Tutto parte da ieri durante la mia sessione "Windows 7: sensori e multitouch cambiano il modo di interagire con il PC" ho ri-mostrato il SurfRaf con nuove demo e con gli aggiornamenti di WPF 4.0 beta2.

Ma la novità era chiaramente il dispositivo USB che ho chiamato RafStorm:

Questo dispositivo è un anemometro molto casalingo che legge (vedi cavetto) i buchi in un piattello (preso da un vecchio hard disk) con 16 buchi. Una forcella costituita da un fototransistor e un led legge la presenza/assenza dei buchi. Calcolando il numero di buchi al secondo e sapendo che ci sono 16 buchi per giro, si ricava facilmente il numero di RPM (giri al minuto).

La reale novità di questo dispositivo è che viene visto come "Sensore" da Windows 7 e questo implica diversi vantaggi molto importanti:

Più processi contemporaneamente possono usare il dispositivo senza doversi contendere il canale di comunicazione
Le applicazioni possono usare i nuovi dispositivi della stessa categoria senza neppure dover essere ricompilati
Non è ncessario usare alcuna libreria del produttore. Nulla di nulla. Le Sensor API espongono i dati con un certo formato a seconda della categoria di cui il sensore fa parte. È il driver dei sensori costruito dal produttore del sensore a dover esporre i dati in modo coerente con la categoria.
Security! Dal pannello di controllo gli amministratori del PC possono permettere o negare agli utenti l'uso di ogni singolo sensore. Sempre dal pannello di controllo gli utenti possono scegliere se rendere disponibile o meno i sensori alle applicazioni.

Avevo scritto l'applicazione demo in C# che usa le il wrapper per API di Windows 7 (tra cui quelle dei sensori) già lo scorso anno. Quando ho finito di costruire il device ed il suo driver, l'applicazione ha visto il mio device automaticamente.

La chiave di svolta che consente di trasformare un "normale" dispositivo in un "Windows 7 Sensor" è il driver (in modalità User Mode e perciò aprova di bluescreen) che dialoga con il dispositivo ed espone i dati alle Sensor API.

La semplificazione del modello dei sensori significa poter utilizzare i sensori anche in applicazioni in cui la sensoristica non sia lo scopo primario. Pensate ad esempio al valore aggiunto di cambiare la skin da chiara a scura leggendo la luminosità della stanza. Oppure a leggere l'apertura e chiusura cassetto per un POS.

Domani SurfRaf e ...

Raffaele Rialdi — Mon, 01 Feb 2010 13:01:36 GMT

Corrado non te la prendere con me, tuttalpiù con il Presidente che per la seconda volta di seguito ci ha messo in track parallele ;-)

Oltre a tenere vivo lo spirito di SurfRaf nelle demo del MultiTouch, sono riuscito a terminare in tempo la costruzione di un nuovo hardware per la demo dei sensori. E se al workshop verranno i *veri* geek, l'hardware è irresistibile! :)

Prometto che non mi porto il saldatore dietro e che parlerò soprattutto di software (managed) :-p

See you tomorrow!

Workshop UGIdotNET in arrivo questo martedi

Raffaele Rialdi — Thu, 28 Jan 2010 20:24:33 GMT

Gli incontri delle community in Italia stanno aumentando e il fatto è assolutamente positivo. Però mi mancava un po' il classico Workshop UGIdotNET e la data è supervicina, cioè martedi prossimo 2 Febbraio.

Da parte mia cercherò di interpretare come stia cambiando il futuro dell'interazione con il PC. Windows 7 ci offre nativamente il supporto a nuovi dispositivi di input che possono certamente fare la differenza dal punto di vista dell'usabilità in qualsiasi applicazione.

Certamente bisognerà prenderci la mano, analizzare meglio i requisiti dell'utente senza dare per scontato che siano tastiera e mouse le periferiche di riferimento. Non mi riferisco solo al supporto MultiTouch (dove non potrò astenermi da ripresentare il celebre SurfRaf) ma anche il supporto ai sensori che possono fornire preziosi input alle nostre applicazioni.

Per la mia sessione ho scelto di gettare le basi e vedere architetturalmente da dove iniziare per usare questi nuovi dispositivi e per la parte dei sensori ho creato un device driver che ha visto la sua versione 1 a WPC ma che ho rielaborato per l'occasione.

Il resto dell'agenda è tostissima per cui non mi resta altro darci appuntamento a Martedi.

Buone notizie sui certificati root e trust list

Raffaele Rialdi — Sun, 17 Jan 2010 21:56:02 GMT

Le buone notizie devono avere pari opportunità di quelle brutte e quindi eccone qui due fresche fresche.

La prima buona nuova è che dopo il mio post Verisign ha modificato le pagine di download da http ad https per le certificate authorities di Verisign, Thawte e GeoTrust. Ringrazio perciò Allen Kelly per aver mantenuto la promessa.
Spero che le altre CA interessante dal problema seguano l’esempio di Verisign.

Nel mio post successivo Fabrizio ha lasciato un commento sollevando un dubbio riguardo al download delle Certificate Trust List eseguito periodicamente da Windows Update. Le CTL vengono usate per validare dei certificati (ad esempio quelli delle Certificate Authorities) per una specifica applicazione (nella fattispecie Windows Update).
Fabrizio ha osservato che il download delle trust list viene eseguito via http e quindi potenzialmente soggette ad un attacco di tipo Man In The Middle.

E qui viene la seconda buona notizia. Pur non avendo potuto provare ad eseguire uno sniffiing di persona di ciò che avviene, ho chiesto lumi e mi è stato risposto in modo soddisfacente. In sostanza esiste un ‘agent’ che scarica le Certificate Trust List via http ma anche un hash SHA1 via https per validare il download http. L’hash è protetto da https e funge da ‘firma’ per il cab che contiene le certificate trust list (CTL).
Questo significa che se il download http venisse compromesso, l’agent vedrebbe un hash differente da quello scaricato via https e di conseguenza invaliderebbe il download.

Se qualcuno non si fida o semplicemente ha tempo da dedicare per toccare con dito quanto ho scritto può eseguire un log di tutta la sessione e verificare che viene scaricato anche l’hash SHA1. In questo caso mi farebbe piacere che commentasse su questo post per dare notizia dei test eseguiti.

Garante all'italiana e la privacy diventa solo una faccenda di burocrazia

Raffaele Rialdi — Tue, 12 Jan 2010 16:51:42 GMT

Recentemente è divenuto effettivo un provvedimento che obbliga le aziende a nominare esplicitamente gli amministratori del proprio sistema informativo i quali devono provvedere a mantenere un registro di tutti gli accessi che eseguono a scopo amministrativo su tutte le macchine della rete.

Il provvedimento iniziale è questo: http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499

L'amico Edoardo Benussi ha risposto a molte domande sul newsgorup winserver a questo proposito. Per chi è interessato a eventuali soluzioni da adottare, non postate sul mio blog, non sarei d'aiuto, ma leggete i vecchi thread (e domandate se avete ancora dubbi).

La prima domanda che mi sono posto è: "qual'è lo scopo del provvedimento?". Posso intuire che sia quello di sorvegliare coloro che hanno il sommo potere di amministratore sui dati, potenzialmente sensibili, custoditi nel sistema informativo.
Ok, mi dico ancora, utile per redarguire l'amministratore che fa il curioso, ma che valore legale hanno queste informazioni? Assolutamente zero, il nulla assoluto, ed il motivo è prettamente tecnico.

Per essere chiari qualsiasi indagine giudiziaria non può e non deve mai basarsi su informazioni prelevate da un sistema in cui l'"accusato" abbia accesso amministrativo sul sistema stesso (cioè qualsiasi PC personale) o che ci sia stata la possibilità che vi sia stato installato del "malware" (e vammi a provare il contrario visto che gli antivirus non possono garantire un bel niente). Il resto sono baggianate all'italiana degne solo di gossip.

Ma cavoli, c'è ancora bisogno di ripetere che non c'è modo tecnologico per dare alcuna garanzia sull'integrità delle informazioni quando il sistema operativo è accesso da un account di amministratore? Se sono admin, sono parte del TCB (Trusted Computing Base) e questo significa:

Poter far girare software in kernel mode che non è soggetto, per definizione, a nessun controllo di sicurezza
Alterare qualsiasi informazioni senza che questa venga loggata in alcun modo
Fare tutto ciò di cui sopra in modo molto agevole semplicemente installando un rootkit che rende la cosa facile e realizzabile anche per mio figlio di 8 anni

Ovviamente questo non vale solo per Windows ma per tutti i sistemi operativi, e se il provvedimento fosse stato fatto interpellando un tecnico, la cosa sarebbe emersa nei primi 5 minuti di conversazione. Vergogna.
E attenzione che i log vanno tenuti per tutte le macchine dove c'è un implicazione di privacy, quindi i log degli accessi sui router, dei centralini voip, delle appliance, e se in sala mensa c'è una TV con il DLNA che tiene un log dei film che avete visto .... Ri-Vergogna!

Il risultato è tragicamente il solito modo per far perdere tempo e denaro alle aziende che dovrebbero invece preoccuparsi seriamente di gestire la materia della sicurezza in altro modo, eseguendo le update, gestendo correttamente i certificati, applicando le best practice di sicurezza per ITPro e Developer.
Ma quando il Garante comincerà a garantire il cittadino invece di mettergli i bastoni tra le ruote?

Certificati root: il problema è su vasta scala

Raffaele Rialdi — Wed, 23 Dec 2009 21:41:18 GMT

Nel post precedente ho bloggato su Verisign e a quanto sembra i rumors del mio blog, passando da Twitter, sono arrivati a destinazione. Grazie alla globalizzazione spero che presto avremo da Verisign solo pagine https. Aspetto fiducioso.

Il problema però non è un caso isolato. Nei commenti del post precedente, Fabrizio mi ha segnalato che sul sito di Ubuntu la faccenda è pure peggio! In quella pagina infatti viene indicato di scaricare le root come file di testo dal link: http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt appartenente al dominio mozilla.org.

In pratica viene detto che quella pagina http e quindi non protetta viene usata in modo automatico per installare 93 certificati root. Con un attacco Man In The Middle estremamente semplice (trattandosi di file di testo basta un filtro di ettercap di poche righe) si può installare una root dentro la macchina Linux che sarà perciò vulnerabile agli attacchi già citati nel mio post precedente. Mentre l’attacco a Verisign richiede un minimo di collaborazione dell’utente, qui l’attacco ha una percentuale di riuscita decisamente superiore.

Ma non è finita. La vetrina degli orrori vede queste Certificate Authories che forniscono le root sempre in http, quindi attaccabili in modo estremamente semplice:

Cacert: http://www.cacert.org/index.php?id=3
Geotrust: http://www.geotrust.com/resources/root-certificates/index.html

Non è ancora finita. Nelle stesse condizioni di Verisign, cioè pagina http con post in https e quindi vulnerabili, ci sono:

Thawte: http://www.thawte.com/roots/
Entrust: http://www.entrust.net/developer/index.cfm

Il problema è più che serio. La sicurezza di un sistema dipende da tutti gli attori del sistema. Anche se gli algoritmi alla base di SSL sono sicuri, questo genere di problemi possono causare il fallimento totale. Voglio ricordare che tra gli attori del sistema c’è anche l’utente finale che deve controllare di essere su una pagina sicura con un certificato valido.

Certificati Root e Verisign. Giocare con il fuoco è nulla in confronto

Raffaele Rialdi — Tue, 22 Dec 2009 13:34:00 GMT

Verisign ha sul proprio sito il Graal degli Hacker: il download dei certificati root delle più importanti Certificate Authority.

Quale Black-Hat non vorrebbe installare il proprio certificato root sulle macchine degli utenti da attaccare? Avere sulla macchina della vittima un certificato root significa poter generare certificati validi emessi per ebay, paypal, banca di qui, banca di là, etc. etc. Poi hostare un clone di quel sito sul proprio pc, corredato del certificato "autentico" e infine dirottare con un "dns poisoning" l'utente sul proprio pc.

Cosa può accadere se l'hacker possiede una root Certificate Authority che è installata sul nostro PC?
Può accadere che utente navighi sulla propria banca, ma grazie ad un dns poisoning viene dirottato sul sito dell'hacker. Quello che vede è un perfetto clone del sito della banca con tanto di certificato valido e una connessione https assolutamente impeccabile. Non è un attacco "delizioso"?

Torniamo all'inizio. Il punto di partenza è che l'utente deve in qualche modo essere convinto a scaricarsi le root aggiornate di Verisign e l'hacker deve intercettare il download. Come e quando importa poco, si va da un banale attacco di social-engineering ad una reale esigenza di aggiornare i certificati.

Dove sbaglia Verisign? La pagina di download delle root è in http .... fantastico tenendo conto che a Verisign i certificati non costano neppure 1 cent .

L'utente accorto vedrà subito che il post è verso un sito https ma qui casca l'asino:

L'hacker esegue l'attacco sulla pagina http e sostituisce il post da https ad http, quindi questo link non sarà mai in https
Se si usa SSLStrip, quell'https per "magia" torna ad essere http, come ho fatto vedere ai recenti TechDays/WPC.

L'attacco Man in The Middle consiste nell'usare un tool come Ettercap (ma ce ne sono molti altri) per intercettare l'attività tra i client e i server. Per cui anche se non si è fisicamente in mezzo, è possibile intercettare il traffico di rete tra due pc. È comunque necessario essere su una tratta di rete che permetta di porre l'attacco. Non so se la grande lan di Fastweb sia soggetta all'arp poisoning che ho mostrato nella mia sessione, ma certamente sono più le reti che possono accusare il colpo di quelle protette da questo tipo di attacchi.

Una volta intercettato il download l'utente riceve uno zip in cui uno o più certificati sono stati creati dalla Certificate Authority dell'hacker.

Lo zip contiene ben 41 certificati Root!

Installare una root sul pc della vittima significa che quel pc validerà in modo positivo qualsiasi certificato emesso da quella root. I risultati sono devastanti.

Una raccomandazione finale. Come dico sempre, fate le prove attaccando delle macchine ma solo in reti di test o in azienda solo dopo aver avvisato amministratori e utenti. Non ci sono deroghe a queste regole.

Failure by design, e al cliente va bene così

Raffaele Rialdi — Tue, 22 Dec 2009 10:03:21 GMT

Neve e ghiaccio sono la condizione meteo di parecchie città di questa mattina. Il buon cittadino si tiene informato seguendo i siti web dove può vedere con i propri occhi la situazione reale.

Così apro il sito www.autostrade.it per capire cosa sta succedendo. Il sito non è raggiungibile per (presunti) troppi hit dei buoni cittadini che vogliono informarsi.

Uhm, qui c'è qualcosa che non torna. Una azienda, le autostrade spa, offre un servizio ai suoi clienti, il sito web e le webcam. L'utilità del sito è proprio nei momenti difficili: situazioni limite del meteo, picchi di traffico, lavori in corso, etc. Se il sito fallisce nel dare le informazioni in questi casi limite, è inutile.
Il paragone è il sito di un eCommerce nel periodo di Natale. Se per i troppi collegamenti il sito non funziona, perdo i clienti.

Fino a qui posso già immaginare i commenti a questo post in cui viene sottolineato che autostrade non danno importanza al cliente in quanto monopolisti e con un'eredità di mentalità "pubblica".
Sono però convinto che l'apparente (?) boriosa mentalità monopolista non basti a giustificare le cattive scelte. Un sito (servizio) che funziona giova anche al monopolista, perlomeno per lucidare un po' l'immagine aziendale.

Guardiamola quindi dal punto di vista di chi ha realizzato il sito:

l'architettura del sistema è pensata per essere scalabile? No
è stato previsto il fallback ad una pagina alternativa, come dice Alessandro, con le sole informazioni essenziali? No
la pagina client è sufficientemente leggera da reggere carichi improvvisi? No
...

Il fallimento è quindi il matrimonio tra committente, team di sviluppo e servizio di hosting.

E ancora peggio è l'utente del sito che considera normale, causa maltempo, che ci sia un disservizio su un sito che serve proprio in caso di maltempo.

Persistenza e database

Raffaele Rialdi — Mon, 21 Dec 2009 17:48:45 GMT

Un progetto la cui architettura sta emergendo in questi giorni, ha evidenziato una problematica ricorrente che riguarda la necessità o meno di strutturare i dati in modo relazionale nel database.
Per evitare di farla troppo lunga, partiamo da un esempio. Diciamo quindi di avere un modulo di una applicazione che deve eseguire del logging sulle attività svolte da un utente all'interno di un sito.

L'attività da loggare è ha un inizio, i dati da loggare cambiano a seconda di come opera l'utente nell'applicazione, termina quando l'utente ha completato un determinato task, il log deve essere cancellato dopo un certo tempo perché lo storico non sia eccessivo e per rispettare la privacy.

Il database è lo strumento ideale per mantenere questi dati? Se consideriamo il modo "classico" di gestione del database la mia risposta è no.

Facciamo un passo indietro e domandiamoci perché si sceglie il database. I motivi in cima alla lista sono: gestione "gratis" della concorrenza nell'accesso ai dati, ottime performance nella ricerca dei dati, capacità di relazionare set di dati eterogenei, etc.
Ma nel nostro esempio cosa ci serve di tutto ciò? Più che altro ci serve la gestione della concorrenza per cui sarebbe da pazzi eseguire la persistenza su un file xml.

Quale altra tecnologia ci permette di rispondere a quelle domande per lo specifico problema in esempio? Workflow Foundation non solo risponde a questi requisiti ma semplifica di parecchio lo sviluppo della soluzione:

Alla crezione del nuovo log, viene creato una nuova istanza di workflow
Dalla versione 4.0 possiamo gestire la logica del nostro esempio di logging (e i relativi dati) secondo una Flowchart, cosa particolarmente familiare a qualsiasi developer, quindi meno prona ad errori.
I workflow possono essere "long-running" e sarà l'engine a gestirne la persistenza sul "media" che il developer ha stabilito. La persistenza può anche finire in un blob così come su un db relazionale. Il tutto è "nascosto" all'applicazione e come ogni disaccoppiamento questo è un grosso beneficio.
L'avanzamento dell'attività dell'utente si ottiene dall'object model di Workflow, anche da una applicazione esterna di amministrazione. A partire dalla versione 4.0 ci sono anche gli strumenti già pronti come la dashboard di "Dublin".
Il workflow può avere come ultimo stadio una "Sleep" di 2 mesi e poi decidere di cancellare la persistenza. Quei due mesi non sono altro che un blob posteggiato da qualche parte. In memoria non c'è nulla ma il runtime sa che, tascorso quel tempo, deve riattivare quell'istanza e farla proseguire. Il suo ultimo stadio è quello della cancellazione dello storico.

In sostanza basta disegnare graficamente il workflow, oops flowchart, (magari dopo aver sviluppato delle adeguate custom activity) e dirgli che ci serve il servizio di persistenza, e il gioco è fatto.

Magari abbiamo configurato la persistenza di WF su un db relazionale, o magari abbiamo usato Table o Blob di Windows Azure, ma quel che più importa è che non abbiamo disegnato un db, non abbiamo scritto query o sp, non abbiamo un datalayer per questa specifica parte dell'applicazione.

Ovviamente il concetto è trasportabile anche a molti altri esempi ma non è generalizzabile anche se ritengo che l'abitudine ad usare il db per tutta la persistenza nasconda soluzioni più brillanti.

Windows Identity Foundation è in RTM ma attenzione alla documentazione

Raffaele Rialdi — Wed, 02 Dec 2009 13:42:59 GMT

Windows Identity Foundation (WIF) [pronunciato "dab ai ef"] è in RTM. Stiamo parlando del progetto che aveva in alfa il nome "Zermatt" e successivamente in beta 1 e 2 "Geneva".

Per chi non conoscesse queste tecnologie WIF è:

il nuovo modello di sicurezza di WCF che rimpiazza totalmente il modello ed i claim della versione 3.0 e 3.5. In questo nuovo modello si può conservare il mapping claim <--> ruoli in modo da rendere facile la migrazione del codice esistente
un set di tecnologie basate su Claim e sui protocolli standard WS-Trust e WS-Federation, e di conseguenza interoperabile con altre tecnologie di altri sistemi operativi
un modo per togliere il processo di autenticazione/autorizzazione dalle applicazioni ed esternalizzarle. Questo porta ad una serie di vantaggi tra cui la scalabilità dei servizi che hanno massicci carichi di autenticazione e controllo dei ruoli
C'è molto altro ma per dirla in parole povere, come sviluppatori, project manager o architetti .... ci tocca :)

Chi inizia oggi non deve preoccuparsi di nulla. Go and use it.

Una piccola nota per chi come il sottoscritto ha prodotto un bel po' di codice.
Le modifiche durante tutto il corso delle alfa e beta sono state tante e significative, ma questo è più che ovvio. Fino alla beta 2 le modifiche erano anche ben documentate.
Poi viene annunciata a PDC 2009 la RTM (o RTW come la chiamano ora) e il team blogga i vari documenti. Tra questi un pdf che dovrebbe colmare il gap tra la beta2 e la RTM. Peccato che la documentazione sia totalmente insufficiente e le differenze sono molte di più e non documentate. Prontamente ho aperto un bug di documentazione su connect se qualcuno fosse interessato a votarlo.

Per ricapitolare, WIF è un'iniziativa in cui sono coinvolti questi attori:

Il pacchetto di redist che va solo sul server. Viene fornito come .msu (update) per Windows Vista/2008 e Windows 7/2008R2. Il lato client funziona senza dover installare nulla perché WCF è già "federation aware" e non ha bisogno di altri assembly per lavorare con WIF.
Con gli assembly lato server si possono sviluppare le "Relaying Party" (web app, servizi, etc.) ma anche STS (Secure Token Service) sia di tipo "Identity Provider" che di tipo "Trasformatori di Claim".
Il pacchetto SDK (che non contiene quello di redist) destinato agli sviluppatori con help ed esempi.
Cardspace 2. Tutt'ora in beta 2 non usa il Framework come la versione 1 di Cardspace in modo da rendere super-snello il suo deploy.
ADFS2. È ancora in beta 2 e si chiamava Geneva Server. In pratica è un add-on per Active Directory per far si che AD sia anche un STS per le tecnologie WIF.

Developer Center:
http://msdn.microsoft.com/en-us/security/aa570351.aspx

Redist:
http://www.microsoft.com/downloads/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76&displaylang=en

SDK:
http://www.microsoft.com/downloads/details.aspx?familyid=C148B2DF-C7AF-46BB-9162-2C9422208504&displaylang=en

TechDays/WPC 2009 conclusa

Raffaele Rialdi — Fri, 27 Nov 2009 10:02:41 GMT

Il mio recente silenzio sul blog è dipeso anche dal tempo necessario alla preparazione a questo magnifico evento che si è svolto come sempre a Milano Assago.

Voglio ringraziare i tantissimi presenti per il calorosissimo feedback che ho ricevuto di persona nei corridoi. La hacking session è stata una sfacchinata, ci sono voluti 45 minuti per preparare le macchine sul palco prima della sessione ma la fatica è stata ripagata dalla presenza e dai complimenti dei partecipanti.
Le mie 4 sessioni erano queste:

Le novità di C# 4.0. Tutte novità improntate all'interoperabilità. Sono partito dagli optional e named parameters, passando da co/contravarianza per arrivare al tema centrale: il DLR. La keyword dynamic non apre solo a scenari di interoperabilità più facile per i linguaggi di scripting e per COM ma si presta a molto altro. Prima di tutto per migliorare le performance del codice che oggi usa reflection ma anche per generare dei proxy in modo molto semplice. La demo su ExpandoObject credo che abbia reso l'idea. Ho concluso su noPIA, cioè il type embedding che pur essendo una caratteristica nata per il mondo COM rivoluziona il versioning nel CLR. Ho promesso che avrei bloggato sul type embedding e lo farò a breve.
Hacking Session. La LAN è sconfitta, entrarci è molto più semplice di quanto si creda comunemente e spero che le demo di attacchi pratici abbiano reso l'idea e messo sull'allerta tutti. In particolare mi rivolgo ai developer che credono, sbagliando di grosso, che le applicazioni in deploy sulla LAN non abbiano bisogno di essere messe in sicurezza: è un errore super-clamoroso.
Windows 7 e Windows 2008 API. Ho mostrato i Windows Web Services usati da VB6 per facilitare la migrazione dal vecchio al nuovo mondo. Poi sono passato alle API dei sensori ed in particolare un device driver che ho sviluppato per interfacciare un dispositivo che parla sulla seriale (che sono decisamente i dispositivi più comuni). Così facendo la seriale è gestita dal device driver (in user mode) e perciò un numero arbitrario di applicazioni possono usare contemporaneamente il sensore. Poi sono passato al SurfRaf e c'è stato modo anche di parlare del MicroFramework 4.0.
Creazione di documenti xlsx e docx con OpenXML SDK 2.0. Generare documenti con questo sdk diventa estremamente semplice visto un tool, DocumentReflector, che permette in un minuto di fare tutto: creo il documento con Office, mi faccio generare il codice C# equivalente dal tool, eseguo "incolla" in Visual Studio e il gioco è fatto. Certamente non ci siamo fermati qui e ho mostrato come generare documenti usando l'object model del nuovo sdk che ha determinate peculiarità. Oggi la generazione di documenti tramite interoperabilità con Office non è certamente più conveniente per motivi di prestazioni e di dipendenze da Office, task da evitare soprattutto sul lato server.

Grazie anche a tutto lo staff di Overnet per l'impeccabile organizzazione.

MicroFramework 4.0 fa il botto

Raffaele Rialdi — Tue, 17 Nov 2009 23:29:30 GMT

Oggi è iniziata la PDC e con rammarico non sono laggiù a godermi le novità.

Nella keynote si è parlato tantissimo di Azure ma ci sono molte altre cose interessanti da guardare con molta attenzione. Tra queste l'annuncio dell'uscita del MicroFramework 4.0.

È lo stesso Colin Miller, il boss, ad annunciare le novità di questa versione:

Rilasciati la quasi totalità dei sorgenti in licenza Apache 2.0
Supporto ad Http e SSL anche dentro l'emulatore
Gestione del multitouch
Supporto al versioning
Una formula chiamata "Community Development Model" che ha lo scopo di fungere da arbitro su ciò che verrà implementato nella versione mainstream in modo da evitare che la diffusione dei sorgenti moltiplichi versioni parallele con conseguente impossibilità della sua gestione.
Molto altro ancora per quanto riguarda performance e gestione.

Applausi al team. Io sto usando da tempo la versione 3 e già questa è da spettacolo.

Windows 7 e le API dei sensori

Raffaele Rialdi — Wed, 11 Nov 2009 08:56:02 GMT

L'hardware ha fascino, non c'è dubbio. Chi ha la passione per il software come il sottoscritto, sente un sapore particolare nel programmare un microcontrollore e toccare con mano il proprio operato sul "metallo".

La porta seriale ha sempre svolto il mestiere di jolly per interfacciare qualsiasi tipo di periferica e anche i programmatori hanno avuto vita piuttosto semplice nell'usare la seriale.

Poi è arrivata la USB. Bella, veloce e pratica ma decisamente ostile per un developer. Il perché è semplice. Le categorie di device (e quindi di driver) dipendono dalla funzione svolta. Perciò se il device è un mouse o una tastiera, Windows sa già cosa fare e quindi basta il device generico "HID" (Human Interface Device). Al di fuori di questo è necessario un device driver specifico dal produttore.

A parte il fatto che con lo scempio di driver che ci sono in giro, tremo tutte le volte che ne devo installare uno, ma qui vado offtopic, il problema è che il device driver non basta ma:

ho bisogno di documentazione per sapere come comunicare con il device
in alcuni casi ho bisogno di un sdk
la periferica spesso è in uso esclusivo per una sola applicazione

A semplificare un pochino le cose molti device fanno finta di essere madrelingua USB e si limitano a usare un dispositivo USB to Serial che usa la USB come protocollo fisico ma viene visto come seriale da Windows. Ma questo non risolve tutto in particolare il problema dell'uso esclusivo.

L'uso esclusivo è un problema grosso, pensiamo ad esempio ad un GPS, tradizionalmente un device seriale (over bluetooth di solito) di cui più applicazioni possono avere bisogno.

Poi arriva Windows 7 e un nuovo layer di API specifiche per i sensori e la storia cambia radicalmente.

Il device ed il suo driver non devono cambiare nulla rispetto a prima. Se il device ha bisogno di un driver questo continua ad esistere. Se invece usa la seriale, continuerà a non dover fare nulla.

Le Sensor API hanno però bisogno di un altro driver, molto più semplice, parliamo di un oggetto COM multithreading in usermode sviluppato con il device driver kit "UMDF" (User Mode Driver Framework). Le funzioni di questo driver sono:

normalizzare il dialogo tra Windows e il device in modo 'standard'. In questo driver vengono affogata la flowchart di comunicazione con il device: il protocollo di comunicazione.
normalizzare il contenitore dei dati affiancando un timestamp che indichi quando sono stati campionati
gestire la "ownership" del device. Quindi il nuove driver funge da proprietario e fa da gateway per tutte le applicazioni che vogliono usare quel device
garantire la continuità della comunicazione da un altro processo, quello del driver. Se quindi freezo la mia applicazione e poi riprendo dopo qualche secondo, i dati mi arrivano tutti perché il driver sa dove ero arrivato.

Chi realizza il driver? Si spera che il produttore veda un business in questo ma chiunque sappia comunicare con il device al vecchio modo può realizzare questo driver "wrapper". Naturalmente C++ e COM sono necessari ma il codice da scrivere è proprio poco.

Poi arriviamo noi che sviluppiamo applicazioni. Scarichiamo il CodePack, e con poche righe di C# (o vb.net, o F#, ...) si accede ai dati del sensore. Poi avviamo due, tre, quattro istanze dell'applicazione e tutte possono accedere a questi dati ... cool!

L'architettura delle Sensor API prevede la categorizzazione dei sensori: accelerometri, sensori di luce, GPS (fisici o virtuali basati su WiFi), ma anche di creare nuove categorie.

A TechDays/WPC farò vedere anche i sensori (compresi i device driver UMDF) nella mia sessione sulle novità delle API in Windows 7/2008 R2.

[OT] SMAU e SPAM

Raffaele Rialdi — Wed, 28 Oct 2009 08:03:46 GMT

Ho avuto a che fare con l'ente SMAU (come espositore) dal lontano 1991. Sono un muro di gomma.

Ricordo le file di espositori alle 8:50 davanti all'ingresso di Porta Carlo Magno sotto l'acqua dirotta e naturalmente senza sufficiente spazio per tutti sotto le pensiline. Risultato: una settimana di doccia tutti i giorni perché anche l'ombrello serviva a poco e niente.

Ricordo le discussioni accese al desk degli organizzatori al palazzo del CISI quando lamentavamo tutti che l'ingresso selvaggio al pubblico avrebbe fatto morire la manifestazione. Puntualmente l'anno dopo c'erano Radio105, e allo stand arrivava gente che acchiappava i nostri mouse e porta mouse come se fossero dei gadget *dovuti*.

Ricordo i prezzi per metro quadro di uno stand, le code chilometriche ai bar senza corsia preferenziale per gli espositori, e molto altri "bei" ricordi. L'amico SDP con cui ho condiviso quel periodo certamente ne potrebbe aggiungere molte altre a questa lista.

Da 5 anni a questa parte spediscono SPAM selvaggia a chiunque gli fornisca un'email, il sistema di de-subscribing ovviamente è finto e non funziona, le telefonate finiscono nel cestino, le minacce di passare all'amico avvocato funzionano un pochino di più.

Quest'anno Microsoft ha fatto l'errore (IMHO) di effettuare la registrazione affidandola a questi spammer di professione, gente che il rapporto con il "cliente" ha dimostrato da un paio di decenni di non sapere neppure cosa sia. E questo è il motivo per cui non mi sono iscritto alla bellissima festa di lancio di Windows 7 che si è tenuta alla fiera di Milano. Ovviamente me ne sono stato zitto fin'ora per non fare il guastafeste, ma mi è dispiaciuto perché incontrare i soliti ignoti mi avrebbe fatto immenso piacere.

Si, avrei potuto fare una regola di posta, usare il plugin di disintegrazione in Outlook, passare la loro email sulle liste di distribuzione dei BOT che massacrano il server che le spedisce e molto altro ancora, ma una volta tanto l'ho fatto per principio.

Office OpenXML SDK 2.0 (beta)

Raffaele Rialdi — Thu, 22 Oct 2009 10:34:48 GMT

Era da un po' che volevo scrivere sull'argomento e la preparazione della sessione che presenterò a TechDays/WPC tra un mese è stato il trigger di questo post.

Più di due anni fa ho iniziato a sviluppare delle librerie (oggi felicemente in funzione) per creare file conformi allo standard ECMA-376 che, in quanto membro della commissione ISO JTC1/SC34, spero di upgradare presto alla versione ISO DIS29500 recentemente approvata (ma ancora non utilizzata da alcuna applicazione sul mercato).

La beta della versione 2.0 dell'SDK fa un passo significativo in avanti rispetto alla 1.0. Mentre la 1.0 semplificava di fatto la gestione del package OPC dentro cui sono custoditi i file XML che descrivono i dati, la 2.0 aggiunge un aiuto stra-prezioso nella creazione dei dati stessi:

un elaborato object model per generare il contenuto (non è quindi necessario scrivere XML)
la validazione degli schemi
il tool DocumentReflector che esegue legge un documento esistente e genera al volo il codice C# che produce quel documento. 10 e lode a chi ha creato questo tool.
un tool di comparazione di due documenti ooxml

Il tool DocumentReflector è risolutivo nella gran parte di piccole applicazioni, soprattutto per la generazione di documenti destinati a Word. Si crea un documento con Word con formattazione, immagini e quant'altro, si carica il documento con questo tool, copia incolla del codice C# in un progetto, si inseriscono le variabili per personalizzare il documento e il gioco è fatto. A questo punto facendo un loop su una anagrafica si creano tutti i docx personalizzati.

Ovviamente non è adatto a tutti gli scenari e infatti di questo parlerò nella mia sessione.

Ben diverso è uno spreadsheet che ha molta più variabilità e qui si toccano di più gli aspetti negativi dell'SDK.
Per esempio nei file XML è necessario sia presente l'attributo Count pari al numero di elementi child:

        1: <x:fonts count="2" xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

       2:   <x:font>

       3:     <x:sz val="11" />

       4:     <x:color auto="1" />

       5:     <x:name val="Calibri" />

       6:     <x:family val="2" />

       7:     <x:scheme val="minor" />

       8:   </x:font>

       9:   <x:font>

      10:     <x:sz val="14" />

      11:     <x:color rgb="FF0000" />

      12:     <x:name val="Calibri" />

      13:     <x:family val="0" />

      14:     <x:scheme val="minor" />

      15:   </x:font>

      16: </x:fonts>

Grazie a C# 3.0 e all'sdk, è possibile creare l'equivalente di quell'XML in questo modo:

       1: new Fonts(

       2:     new Font(

       3:         new FontSize(){ Val = 11D },

       4:         new Color(){ Auto = true },

       5:         new FontName(){ Val = "Calibri" },

       6:         new FontFamilyNumbering(){ Val = 2 },

       7:         new FontScheme(){ Val = FontSchemeValues.Minor }),

       8:     new Font(

       9:         new FontSize(){ Val = 14D },

      10:         new Color(){ Rgb = "FF0000" },

      11:         new FontName(){ Val = "Calibri" },

      12:         new FontFamilyNumbering(){ Val = 0 },

      13:         new FontScheme(){ Val = FontSchemeValues.Minor })

      14: ){ Count = (UInt32Value)2U },

Da notare la proprietà Count e l'attributo count nei due riquadri sopra.

La classe Fonts si comporta come una collection ma:

la sua proprietà Count è finta, cioè deve essere valorizzata altrimenti vale null (non zero ma proprio null perché è una classe di OOXML SDK).
l'omissione di qualsiasi dato mandatario comporta la creazione di un documento non valido (fortunatamente ci vengono in aiuto le classi di validazione)

Il vero difetto è che la libreria è data-oriented, cioè nata per specchiare i dati e quindi l'object model è poco potente e prono all'errore.

Nella mia libreria sono partito dal punto di vista opposto, cioè l'usabilità per lo sviluppatore e l'estremo strong-typing in modo da evitare "by design" errori che possano invalidare il file xml.

La creazione di uno di quegli elementi font nella mia libreria si scrive così:

       1: XlsFontBase f = new XlsFont("Courier New", 12,

       2:     XlsFontFamilyType.NotApplicable, true, true,

       3:     false, XlsFontSchemeType.minor);

Inoltre non devo creare esplicitamente la sezione stili ma questa viene calcolata automaticamente dopo aver formattato lo spreadsheet. Perciò io mi limito a formattare le celle, poi la libreria estrapola il numero minimo di formattazioni necessarie, e quindi scrive lo stile di conseguenza.

Se ancora servisse, questo testimonia ancora una volta che sviluppare a partire dai dati può portare ad una complessità con cui bisogna fare i conti. Gli object model pensati fin dall'inizio secondo i paradigmi oop portano ad una semplificazione di tutta la logica e ad una maggiore usabilità (quindi meno bug!).

L'ultima considerazione sull'SDK 2.0 è che al momento non è chiaro come entrerà in gioco il neonato standard ISO e come verrà supportata la transizione tra i due standard. Tutto questo considerato che, dal punto di vista dello sviluppatore, lo standar de-facto è quello che conta, perciò dovremo vedere come avverrà la transizione ECMA -> ISO in Office 2010.
Per chi non conoscesse i dettagli, le differenze tra i due standard ci sono per motivi ovvi. ECMA ha presentato ad ISO il proprio standard e ISO ha chiesto delle (giuste e motivate) modifiche. Le differenze non sono qualitativamente rivoluzionarie ma sono pur sempre delle differenze che implicano un cambio di formato.

Nuovi sample/snippet su IAmRaf

Raffaele Rialdi — Thu, 22 Oct 2009 09:43:13 GMT

Negli ultimi giorni ho pubblicato su http://www.iamraf.net alcune cose che avevo in coda da tempo.

Enjoy!

MVP Award, anno settimo!

Raffaele Rialdi — Thu, 01 Oct 2009 15:24:37 GMT

Ho appena saputo via email di aver ricevuto l'Award MVP. Nonostante questo sia il settimo award di seguito che ricevo, credo che il termine "rinnovato" non sia appropriato per questo premio. Ogni anno Microsoft valuta ex-novo tutte le attività svolte dai candidati al premio e decide di conseguenza. Probabilmente è proprio questo che rende così importante, almeno ai miei occhi, questo riconoscimento.

Ancora una volta sarò della partita cercando di mantenere strettissimi i già ottimi rapporti con i team di Redmond, partecipando ai numerosi incontri virtuali e a quattrocchi, e possibilmente all'annuale MVP Summit del prossimo anno.

Un grosso grazie a tutto lo staff MVP, e naturalmente ad Alessandro e Tomas.

L'augurio di quest'anno è: ancora più spirito di community!

Codice managed e nativo: documentazione, usabilità e obfuscation

Raffaele Rialdi — Fri, 25 Sep 2009 14:42:25 GMT

Ecco un titolo che frulla insieme argomenti da riempire un paio di libri.

Periodicamente mi trovo a rimettere le mani su codice C++. È normale perché ogni linguaggio+runtime (anche C++ necessita di un runtime) ha un suo campo di applicazione che dipende dai requisiti del progetto... nulla di nuovo.

E infatti C++ nativo (non CLI) è tutt'ora lo strumento preferibile per l'estendibilità della shell, IE, WMI, DirectX, mmc e molto altro ancora.

Cari programmatori managed, una documentazione come quella che avete a disposizione oggi sarebbe stata il paradiso terrestre per chi ha lavorato / lavora con ATL, MFC, Win32, C++ e tutto quello che ci sta intorno. Questi sono strumenti potenti, estremamente efficaci, collaudati e robusti ma anche semplici da abusare e perciò tramutare un progetto in un disastro.

Se guardo alla complessità dei sistemi che ho realizzato in 9 anni di programmazione managed, sono assolutamente certo che con linguaggi+runtime nativi non avrei potuto costruire sistemi altrettanto complessi dal punto di vista architetturale.

C'è invece un enorme, gigantesco, pantagruelico gap tra i tecnicismi del mondo managed e quelli del mondo nativo: nel mondo nativo tutto si giocava sulla comprensione e l'applicazione del tecnicismo, sull'hack, sull'algoritmo che eseguiva dei tweak nei meccanismi standard; nel mondo managed il tecnicismo è quasi sempre poca cosa, l'architettura è regina, il numero di layer cresce a dismisura (entro certi limiti è buona cosa), le ambiguità su una tecnologia sono estremamente più basse.

Ed è qui che si gioca la partita dell'obfuscation, cioè della protezione del software.
Nell'era nativa la protezione degli hack e dei tweak erano il maggior valore del software. Ricordo ancora che debuggando i primi viewer di immagini per SuperVGA sotto DOS ho capito come superavano il limite dei 64K per caricare su più banchi le immagini ad alta risoluzione. (Non si scandalizzino i più giovani, ma nell'era pre-80386 la memoria era segmentata e la memoria grafica era "solo" 64K, quindi come caricare immagini più grosse?)

Nell'era managed, guardi come funziona un software e l'architettura è "in chiaro" non perché puoi usare reflector ma perché è evidente come funziona già da come vengono installati gli assembly o guardando una traccia di rete. Buona parte del codice managed che scriviamo "traspare" ad un utente esperto o al power user equipaggiato di ProcMon e vari altri tool. Se poi si passa a Reflector tutto è più chiaro ma non sono daccordo che sia solo il sorgente a rendere tutto così palese.

La complessità del codice managed ha come side effect il fatto di essere tanto e di doverlo conoscere bene per poter essere usato. Se ti do un milione di righe di sorgente è come non averlo. Il tempo che ci metto a capirlo forse non vale neppure il gioco. E questo è il motivo per cui spesso dico che il sorgente non è il valore del progetto.

È chiaro che non si può generalizzare e se scrivo una applicazione di calcolo ingegneristico che in mille righe risolve problemi mai visti prima, ecco che la sua protezione diventa strategica. Ma chi pensa che il codice C++ sia protetto by design si sbaglia di grosso. Ho letto e debuggato kilometri di codice assembler, i compilatori sono abbastanza "stupidi" da scrivere codice assembler con dei pattern, che una volta riconosciuti permettono di capire molto di più di quanto si creda (Esempio: ECX è il registro usato per il this di una classe C++). Ci sono poi applicazioni come DASM (un disassemblatore), il famoso debugger IDA pro che fa veri miracoli, o ancora gli analizzatori di codice PE (il formato di exe e dll) che permette di fare un guessing della marca e della versione del compilatore usato.

La transizione dai tecnicismi di C++ alla complessità "verticale" delle applicazioni managed spiega anche il calo di interesse nel proteggere il codice compilato. L'obfuscation del codice può essere una necessità ma non ritengo che sia più largamente sentita come un tempo.

Materiale sessione Windows 7 disponibile

Raffaele Rialdi — Wed, 23 Sep 2009 07:27:24 GMT

Ho pubblicato il materiale che ho usato nella sessione "Windows 7 for developers" al workshop UGIdotNET di Predappio (tanto per intenderci quello di SurfRaf).

Nella sezione Samples del mio sito, trovate sia le slides che gli esempi usati nelle demo. Per quanto riguarda le demo, nel frattempo è uscita la versione RTM del CodePack quindi date una letta alle note pubblicate insieme ai file per non perdere tempo.

Specchio delle mie brame, qual'è la UI più brutta del reame?

Raffaele Rialdi — Mon, 14 Sep 2009 19:08:37 GMT

Ne abbiamo parlato tante volte, con WPF si abbattono i muri delle UI tradizionali e possiamo finalmente realizzare bottoni di qualsiasi forma, rappresentare il sistema solare con una banale Listbox, ma anche creare autentici mostri con batterie di controlli o abusare delle maledette grid (che sono un po' come il prezzemolo dello sviluppatore).

Agli albori del computing, IBM aveva stabilito le regole di design di una UI (devo ancora avere il librone da qualche parte). Nell'epoca Windows la stessa Microsoft aveva pubblicato le design guidelines fornendo indicazioni importanti agli sviluppatori.

Tanto per intenderci la violazione di queste regole è estremamente negativa perché impedisce all'utente di usare una nuova applicazione senza dover studiare. Ci sono brutte violazioni di applicazioni famose come Orcad e Eagle (per par condicio entrambi cad di elettronica) che farebbero diventare matto qualsiasi utente, ma anche il celeberrimo CorelDraw nell'uso dei tasti ctrl e shift.

Nell'epoca WPF il timore di tutti è quello di creare mostri e non c'è dubbio che i designer siano parte integrante del gioco per rendere più appetibile la nostra applicazione.

E così ecco apparire le nuove Windows User Experience Interaction Guidelines (fresche del 31 Agosto) con le nuove guidelines.

Attenzione, non è un papiro per adeguare la propria applicazione a quelle Microsoft. È un papiro con indicazioni studiate da parte di esperti che ci dicono cosa fare e non fare per i nostri utenti. Parliamo di usabilità ed ergonomia, non di noccioline o regole decise per follia di qualcuno.