martedì 16 marzo 2010
Sembra una ricetta di cucina dagli ingrendienti improbabili e invece è il risultato del terremoto accaduto a Redmond nel team dei device.
Ricordo tempo fa di avere letto una frase di Bill Gates che indicava la mancata innovazione come il nemico numero uno di qualsiasi azienda. Nonostante Microsoft sia l'azienda del settore informatico che investa di più nella ricerca, a volte manca la capacità di innovare. L'insuccesso del mondo dei mobile è dedicato a tutti coloro che lamentano l'eccesso di velocità di questo settore. Spiacente, restare fermi è un insuccesso garantito.
Così ecco un colpo di reni e presentare la nuova generazione di smartphone al Mix 2010 di Las Vegas dove ancora stasera la diretta dovrebbe regalarci altre novità.
Sono un techy, se preferite un geek, e perciò lascio ad altri il piacere di decantare le piacevolezze grafiche del nuovo sistema operativo mobile. Dal punto di vista estetico è piacevole, ma non sono neppure in grado di fare paragoni con la concorrenza di Apple e Google. Perciò complimenti per gli effetti speciali anche se secondo me se ne è parlato troppo senza lasciare spazio alle "feature" più phone-oriented.
Come ho scritto su Twitter durante la diretta, la connessione 3G della mia zona (pienamente coperta) offre 0.35 MB/s con picchi di 0.8MB/s. Perciò spiacente ma le sfavillanti demo di streaming in HD che ho visto nella keynote rimarranno in Italia solo una demo e basta.
L'argomento principe che è mancato è la gestione della telefonata e comunicazione (Windows Phone è un telefono, vero?). Nel mio prossimo telefono vorrei avere:
- gestire la telefonata via SIP in modo trasparente e integrato non con una applicazione alternativa.
- eseguire il best routing delle telefonate in uscita (su più SIM se disponibili, via SIP, via Gateway se in roaming, ...)
- Per Gateway intendo gateway sip raggiungibili via telefono come VoipStunt che evitano costosissimi roaming all'estero
- ricerca dei contatti sulla base della locazione geografica
- possibilità di disabilitare il roaming dati (non solo nel push-email)
- gestione del piano tariffario (dati, sms e voce) indicando i massimali vs quote attuali
Ok, lascio da parte i miei sogni e torno alla realtà.
Lo sviluppo per WP7 è il meglio di quanto gli sviluppatori potessero chiedere. Potranno creare due tipi di applicazioni: Silverlight e XNA. A quanto si è visto non c'è cambio di modello di programmazione o limiti degni di nota ed anche i tool sono gli stessi che si usano per il fratellone Windows. Nelle demo si è vista la versione Express di Visual Studio 2010 RC, Expression Blend for Windows Phone e i relativi tool di sviluppo. Infine è in arrivo anche un libro del grande Charles Petzold di cui è disponibile una preview. Sui tool sono realmente entusiasta perché già oggi VS2010 è a dire poco fantastico. Su WP7, tanto per fare un esempio, l'emulatore può sfruttare il multitouch di Windows 7 per simulare il touch del device, ottimo lavoro.
Nonostante questo al Mix 2010 non si è ancora parlato di device non-phone, cioè i vecchi Windows Mobile 6.x basati su Compact Framework. Dai Microsoft bloggers scopro che il Compact Framework è anche su Windows Phone: http://blogs.msdn.com/abhinaba/archive/2010/03/13/windows-phone-7-series-programming-model.aspx .
Il Compact Framework indubbiamente cambierà, anche a giudicare dalla rivoluzione nel team:
| Compact Framework team 2006 | Compact Framework team 2010 |
 |  |
La versione è diventata la 3.7 e aggiunge naturalmente nuove API e hosting per soddisfare le necessità di Silverlight. Se questa versione (più Silverlight) sarà resa disponibile su Windows Mobile 6.x è ancora tutto da scoprire.
Una cosa mi sembra certa, il fatto che lo sviluppo per Windows Mobile sia stato eliminato da Visual Studio 2010 (bisogna quindi usare Visual Studio 2008) lascia intendere che quei device e quel kit di sviluppo è defunto. È probabile che ci voglia ancora parecchio tempo per creare il sistema operativo gemello per device industriali e ancora più tempo per i produttori per l'integrazione. Spero di essere smentito stasera alla seconda keynote.
sabato 27 febbraio 2010
Dal mio punto di vista probabilmente il miglior Summit da quando viaggio in quel di Seattle / Redmond. Il nostro gruppo Developer Security ha visto (thank you Mark!) due giorni di intense discussioni su vari topic che girano intorno alla Security. A causa del nostro NDA non posso essere più specifico ma è stato estremamente produttivo anche perché essendo un gruppo molto piccolo (eravamo circa 5 MVP sui 21 al mondo) abbiamo avuto modo di discutere a fondo i topic.
Io e Alessandro Del Sole abbiamo viaggiato insieme per più di 30 ore a causa di un problema non meglio specificato all’aeroporto di Genova. Il risultato è stato un zig-zag veramente stanchevole: Genova-Roma-Parigi-Atlanta-Seattle. Siamo così arrivati il Giovedi a notte fonda.
Venerdi e il successivo Lunedi sono stati caratterizzati per me da una sequenza di meeting nel campus al di fuori del contesto del Summit.
Nel weekend abbiamo approfittato per affittare una macchina e, oltre al tradizionale shopping con tappa fissa da Fry’s, domenica Roberto si è unito a noi e abbiamo fatto una magnifica gita. Prima tappa ad Olympia, capitale dello stato di Washington, città molto piccola ma estremamente gradevole. Ci sono alcuni palazzi del governo e una bella baia.
Poi siamo tornati verso Tacoma passando per il famoso ponte di Tacoma narrow bridge, noto per il suo crollo nel 1940 dove gli ingegneri civili hanno per la prima volta capito il fenomeno della risonanza sui ponti.
Siamo risaliti sulla penisola con panorami decisamente bellissimi per poi entrare da nord nella famosa isola di BainBridge che si affaccia davanti a Seattle downtown. Qui abbiamo preso il ferry boat che ci ha portato al porto dei Seattle con una magnifica vista (anche se con un tempaccio da lupi) della skyline di Seattle. Gita da ripetere senza pensarci due volte, un po’ come quella di qualche anno fa ad Orcas.
Martedi comincia il Summit. Quest’anno le sessioni plenarie si sono svolte a Bellevue, una città molto piacevole e piccola, sebbene abbia un centro con grattacieli da fare invidia alle nostre metropoli.
Poi Mercoledi e Giovedi intensissimi al campus. Nella serata di Mercoledi una cena alla caffetteria del campus.
Nella foto al centro compare il “folto” gruppo di MVP Developer Security (solo 4) insieme a diversi personaggi del mondo security tra cui Andrew Dai del CLR (thanks Andrew, great talk!), e l’ormai celeberrimo Vittorio Bertocci, ormai naturalizzato Redmondiano.
A destra invece gli MVP di Moonlight :) ok ok, di Silverlight! Just joking.
Nella caffetteria anche gli MVP di Asp.net e di IIS. A sinistra Alessandro, Simone ed Ugo. In centro Barry (ex Devsec MVP, appena trasferito in quel di Redmond), il sottoscritto e Mark (a cui vanno i ringraziamenti per le fantastiche giornate al campus). Infine a destra non c’è bisogno di dire che è sempre un onore incontrare Scottgu.
Giovedi sera la sorpresa, già raccontata nel post precedente, della cena con Soma Somasegar e poi la festa al “The Garage” di Seattle, un bel locale in cui reincontro il frizzante Stephen Rose del programma STEP di Windows di cui faccio parte.
Infine Venerdi le closing session in Bellevue, dove appaiono a (mia) sorpresa Andrea, Davide e Ugo.
La sera si cena da Daniel’s in cima ad uno dei grattacieli di Bellevue e poi il giorno dopo il rientro, questa volta fortunatamente senza extra-tappe.
Personalmente sono entusiasta delle novità in Visual Studio 2010 che ormai tutti hanno già potuto almeno assaggiare. Altre cose molto interessanti arriveranno e personalmente spero che le varie incubazioni che si discutono durante il Summit vedano la luce nelle prossime release dei prodotti/tecnologie perché sono decisamente promettenti.
See you soon!
venerdì 19 febbraio 2010
Ieri sera ho avuto l’onore di essere parte di un ristretto gruppo di MVP invitati ad una cena informale con Soma Somasegar, Senior Vice President della Developer Division di Microsoft Corporation.
Devo dire che il clima è stato realmente molto informale e piacevole. Hanno partecipato alla cena diversi personaggi di spicco del mondo dello sviluppo come Don Box, Scott Hanselman, Nikhil Kothari, Brian Harry, Shawn Wildermuth, oltre naturalmente a diverse persone di rilievo di Visual Studio e del programma MVP.
Dopo la cena la cosa è stata ancora più interessante perché sono rimasto da solo al tavolo con Soma che mi ha fatto molte domande per capire la mia prospettiva di sviluppatore su come si sta muovendo Microsoft. Da una parte ci ho tenuto a fargli i complimenti per lo splendido lavoro che la Developer Division sta facendo con Visual Studio, dall’altra non ho potuto che sottolineare quanto l’architettura dei forum abbia letteralmente fallito la sua missione per lentezza e inadeguatezza.
Non ho finito di parlare dei forum che ha fatto intervenire Scott Hanselman nella discussione con a cui ho espresso un riassunto dei miei tre anni di lamentele rispetto a quella piattaforma.
Con questo spero e credo di aver rappresentato le community del mio paese. Vedo, leggo e sento tantissimi sviluppatori contenti di Visual Studio e quando ci sono le buone cose vanno dette con la stessa enfasi di quelle meno buone come appunto la faccenda che gira intorno ai forum.
mercoledì 10 febbraio 2010
Domattina io e Alessandro partiamo alla volta di Seattle per l'evento più atteso dagli MVP di tutto il mondo. Il Summit non è una classica conferenza stile PDC o TechEd ma un particolare modo di fare networking tra MVP e i tanti team nel campus di Redmond.
Grazie al networking degli anni passati sia io che Alessandro abbiamo numerosi meeting che ci attendono. Personalmente sarò nel campus sia Venerdi che Lunedi per queste riunioni fuori programma e poi Martedi il Summit prenderà il via ufficialmente con diverse giornate full-immersion, ognuno con i team inerenti alla propria competenza di 'award mvp'.
È anche il modo per incontrare e salutare divesi amici come Giorgio che si è gentilmente offerto di venirci a prendere all'areoporto, il sempre gentilissimo e disponibile Paperino, il neo-papà Ale Contenti :), e tantissimi altri italiani e non.
martedì 9 febbraio 2010
Oggi ho disinstallato VS2010 beta 2 e installato la Release Candidate. L'unico accorgimento che ho adottato è di disinstallare tutti i pacchetti che avevano come data di installazione quella del giorno della beta 2 ... fortunatamente quel giorno non avevo installato altro :)
Oggi ho anche scaricato i file di help localmente tramite l'applicazione "Manage Help Settings", cosa che avevo già fatto all'epoca della beta2.
Dopo tutto questo ho notato che dentro la cartella "ProgramData\Microsoft" c'erano due cartelle: Help3 e HelpLibrary (ciascuna di circa 2GB) e mi sono chiesto se Help3 fosse da cancellare o meno.
Ho espresso il mio dubbio su Twitter e prontamente il team di Help mi ha risposto:
Yes, please remove the old Help3 (%ALLUSERPROFILE%\Help3) folder. the new folder is %ALLUSERSPROFILE%\Microsoft\HelpLibrary
Da notare che la cartella è %ALLUSERSPROFILE%\Microsoft\Help3.
Se non trovate la ProgramData probabilmente non avete abilitato la visualizzazione dei file nascosti da Explorer oppure non state usando Vista o Windows 7. In quest'ultimo caso basta aprire una command prompt e digitare il comando:
echo %ALLUSERSPROFILE%
che mostrerà il nome della cartella.
Io ho cancellato la cartella Help3 e l'help system della RC è ancora vivo :)
mercoledì 3 febbraio 2010
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.
lunedì 1 febbraio 2010
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!
giovedì 28 gennaio 2010
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.
domenica 17 gennaio 2010
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.
martedì 12 gennaio 2010
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?
mercoledì 23 dicembre 2009
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:
Non è ancora finita. Nelle stesse condizioni di Verisign, cioè pagina http con post in https e quindi vulnerabili, ci sono:
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.
martedì 22 dicembre 2009
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.
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.
lunedì 21 dicembre 2009
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.
mercoledì 2 dicembre 2009
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
venerdì 27 novembre 2009
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.
mercoledì 18 novembre 2009
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.
mercoledì 11 novembre 2009
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.
mercoledì 28 ottobre 2009
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.
giovedì 22 ottobre 2009
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.