Ray Ozzie, memo d'addio

L'ex-Chief Software Architect di Redmond torna sulla questione Microsoft e nuvole. Tirando le somme di cinque anni di lavoro. E mettendo a confronto i progressi di BigM e della concorrenza

Roma – Ray Ozzie ha oramai abbandonato il suo ruolo di Chief Software Architet presso Microsoft, ma a quanto pare lo sviluppatore di Lotus Notes ha ancora qualcosa da dire riguardo il lavoro sin qui svolto in quel di Redmond. E soprattutto su quello non svolto, gli obiettivi raggiunti parzialmente o comunque non al livello di integrazione che il manager sperava.

Dov’è finita la svolta epocale di cui parlava Bill Gates cinque anni fa anticipando l’entrata in gioco di Ozzie in uno dei ruoli operativi più prestigiosi in quel di Redmond? Ozzie concede a Microsoft il merito di aver fatto notevoli progressi in merito all’integrazione tra i suoi modelli di business tradizionali e il cloud computing, ma dal memo Dawn of a New Day traspare anche il malcontento per quello che si sarebbe potuto fare e non si è fatto.

Nel futuro “inevitabile” descritto da Ozzie, le esperienze di computing sono necessariamente “transmediali e intra-dispositivo”, incentrate sui network sociali o aziendali dell’utente e con la possibilità di sincronizzare ogni genere di dispositivo con la “nuvola” di dati disponibile sui server remoti dell’organizzazione/servizio di riferimento.

Dove si colloca Microsoft in tutto ciò? “Nonostante il nostro enorme progresso”, dice Ozzie, “alcune delle opportunità che indicai nel mio memo cinque anni fa restano ancora da realizzare”. Ozzie aveva una visione “chiara” di come andava eseguito il balzo evolutivo del modello di business di Redmond, eppure i concorrenti hanno superato Microsoft “nelle proprie esperienze mobile, nell’integrazione senza soluzione di continuità tra hardware e software e i servizi, e nel social networking e in una miriade di nuove forme di interazioni sociali Internet-centirche”.

Ufficialmente Ozzie continua a supervisionare i business Microsoft – Xbox e Windows Phone 7 in particolare – ma a giudicare da quel che traspare dal suo nuovo memoriale pare evidente che il manager si sia messo in rotta di collisione con una visione manageriale avversa , che gli ha lasciato meno libertà di quanta lui avrebbe voluta per operare al meglio.

Alfonso Maruccia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Antonino scrive:
    contromisure per firesheep
    Un rimedio (palliativo) per firesheep è Fireshepherd, un add-on che invia pacchetti "a randa" e fa andare in crash lo sniffer... provare x credere!Ciao a tutti
  • Stefano scrive:
    Panda Rosso?
    Una volta installato sul browser del "panda rosso"...
  • Primiano Tucci scrive:
    Alcune note a riguardo
    In realtà alcuni "ovvi" dettagli sono stati omessi, sia nell'articolo di PI che nella pagina di FireSheep (ma ben discussi nei commenti sottostanti).Intanto, il funzionamento di FireSheep si basa sull'utilizzo di reti WiFi non crittografate (o di alcune particolari reti Ethernet cablate). Da notare che il termine "Non crittografate" non necessariamente corrisponde a "Non pubbliche".Il problema, quindi, non si pone affatto sulle reti WiFi private (protette da WPA/WPA2) ma neanche sulla maggior parte delle reti WiFi pubbliche (in cui tipicamente si adopera WPA/TKIP con chiave fornita automaticamente dall'Access Point).In secondo luogo, il plug-in può funzionare solo ammettendo di disporre di una scheda WiFi capace di funzionare in "Monitor Mode" (ovvero capace di catturare il traffico WiFi delle altre stazioni over-the-air). Non tutte le schede (e non tutti i driver) supportano tale modalità. (http://en.wikipedia.org/wiki/Monitor_mode)In ogni caso, si tratta di problemi assolutamente noti ed affrontati da decenni, per i quali sono sempre esistiti tool a riguardo (Cain per Windows, o Ettercap per Linux sono solo alcune delle soluzioni disponibili da diversi lustri).Tuttavia, mi sembra di capire che fomentare di tanto in tanto isterismi collettivi rappresenti, al giorno d'oggi, il metodo migliore per ricevere l'attenzione.Primiano Tucci,http://www.primianotucci.com
  • Alberto Cordeddu scrive:
    Firesheep
    Se firesheep ruba le credenziali all'interno di una rete significa che l'utente "malandrino" sia già connesso con quella rete e che possa essere già a conoscenza di username e password. Di sicuro se andassi in giro con il notebook non potrò comunque accedere alle reti wifi protette. Certo, se poi voglio rubare le credenziali della rete di un amico o conoscente che mi lascia connettere alla sua wireless be'...Se il mio ragionamento non è errato, credo quindi che firesheep non sia così malvagio. O posso accedere alle credenziali di altre reti alle quali non sono connesso? In questo caso, il problema non è marginale.Grazie.
    • utontopassa nte scrive:
      Re: Firesheep
      Ma infatti credo che il problema sia prettamente estero (grazie al decreto pisanu che vieta il wifi libero in italia) quando ti connetti a reti condivise da "tutti" od open negli aeroporti, certi alberghi ecc. se uno fa entrare nella sua rete privata una persona dovrebbe perlomeno fidarsi o conoscerla o cambiare le credenziali subito dopo (non si sa mai nemmeno tra gli amici ) sulle lan cablate credo sia più facile (ma potrei sbagliarmi non sono molto ferrato) adottare contromisure.Scusate ma sono utonto volevo domandare a solo titolo informativo e di difesa come funzionano i cookie, ma i cokkie di per se con controllo hashmd5 e scadenza, non si rinnovano continuamente? nel senso un eventuale malintenzionato non potrebbe entrare nell'account xy solo per poco tempo? (a meno che non cambi la password una volta loggato al sito ovvio) se il ladro di biscotti ruba il cookie mentre l'utente è collegato e lo usa subito i siti non si accorgono di doppio login da due sistemi diversi o fanno caso solo all'ip di rete? e se l'utente si disconnette prima del malintenzionato non invalida il cookie?Magari ho fatto domande sceme ma è per capire.
  • ullala scrive:
    veramente...
    Io la uso come una "feature"...No non è una battuta!Hai da vedere come si incrokkiano i siti di advertising quando in due o tre si scambiano qualche cookie.L'importante è non fidarsi delle password in "chiaro"...Del resto di cosa stiamo parlando?Da quando non è possibile sniffare le connessioni in chiaro (e quindi anche lo scambio dei cookies)?Avete presente wireshark e il suo predeXXXXXre ethereal?Non c'è difesa da questo!Salvo criptare tutto!Mah... mi pare che il tutto lascia il tempo che trova!
  • BoboMilano scrive:
    GMAIL usa sempre SSL
    se non sbaglio da qualche tempo GMAIL usa forzatamente http.forse non lo usa al momento del login, dovrei controllare
  • djechelon scrive:
    Io non ci sono mai cascato
    Quando ho scritto software finora ho SEMPRE vincolato il cookie all'indirizzo IP della macchina. L'ideale compromesso tra sicurezza e necessità di riloggarsi sarebbe alla sottorete /24, se ognuno si fida della propria LAN, ma se i siti web più popolari sono realizzati da sprovveduti, beh, non ci possiamo fare niente.Inoltre se siamo nattati siamo doppiamente fregati, il trucco di Firesheep funziona alla stragrande...Una volta ebbi un cookie amministrativo di dooyoo.it su un mio pannello web, non vi dico..... :) (anni e anni e anni fa)-----------------------------------------------------------Modificato dall' autore il 26 ottobre 2010 21.33-----------------------------------------------------------
    • eee rrr scrive:
      Re: Io non ci sono mai cascato
      - Scritto da: djechelon
      Quando ho scritto software finora ho SEMPRE
      vincolato il cookie all'indirizzo IP della
      macchina. L'ideale compromesso tra sicurezza e
      necessità di riloggarsi sarebbe alla sottorete
      /24, se ognuno si fida della propria LAN, ma se i
      siti web più popolari sono realizzati da
      sprovveduti, beh, non ci possiamo fare
      niente.
      Inoltre se siamo nattati siamo doppiamente
      fregati, il trucco di Firesheep funziona alla
      stragrande...ci spiegi come fai, da un'appliXXXXXone web, a gestire i'ip interno alla lan (192.168.x.x)? o ricorri a java che legge e manda poi al web server o ti attacchi.L'unica è utilizzare https per tutta la sessione, non solo al login.
    • bbo scrive:
      Re: Io non ci sono mai cascato
      - Scritto da: djechelon
      Quando ho scritto software finora ho SEMPRE
      vincolato il cookie all'indirizzo IP della
      macchina. L'ideale compromesso tra sicurezza ebeh in una azienda molto probabilmente tutti i pc escono con lo stesso identico IP, per cui non ha molto senso vincolare l'IP alla macchina, non ci vedo alcun valore aggiunto...
  • eee rrr scrive:
    Leggete bene
    ... c'è bisogno, in background, del tool "Winpcap" per l'effettivo sniffing dei pacchetti in transito.Dal sito: "Note: Windows users need to install Winpcap first!"e grazie al c4zz0...
  • Ubunto scrive:
    Vabé... non si può avere tutto dalla vit
    Vabé... non si può avere tutto dalla vita...http://arewefastyet.com/ 8) 8) 8) 8) 8) 8)
    • Dave vee scrive:
      Re: Vabé... non si può avere tutto dalla vit
      Scusa... ma che c'entra il tuo commento?
      • Ubunto scrive:
        Re: Vabé... non si può avere tutto dalla vit
        - Scritto da: Dave vee
        Scusa... ma che c'entra il tuo commento?A volte sono benaltrista. Questa è una di quelle.Spero tu capisca il motivo guardando quel grafico.
        • Valeren scrive:
          Re: Vabé... non si può avere tutto dalla vit
          Mi associo al "non capisco".Velocità nei benchmark vs thread sul rubare i cookies ( ai bambini? :) ), proprio non riesco a metterli insieme.
          • Ubunto scrive:
            Re: Vabé... non si può avere tutto dalla vit
            - Scritto da: Valeren
            Mi associo al "non capisco".
            Velocità nei benchmark vs thread sul rubare i
            cookies ( ai bambini? :) ), proprio non riesco a
            metterli
            insieme.Ok, ammetto le mie colpe, dopo le delusioni delle prime beta sono ansioso di flammare sull'argomento performances javascript di firefox 4 ora superiori a chrome e safari in sunspider e appena inferiori a chrome in v8.L'ansia da prestazione mi ha portato a questo EPIC FAIL. :$
  • FridayChild scrive:
    No, un momento...
    Questo exploit funziona solo su una rete wifi non protetta... o sbaglio?Su una LAN cablata concettualmente potrebbe anche funzionare, ma non così facilmente, richiederebbe altre tecniche "malevole" come ARP spoofing e compagnia briscola...
    • Homo Artisticus scrive:
      Re: No, un momento...
      Da quello che leggo, basta essere sulla stessa LAN...- Scritto da: FridayChild
      Questo exploit funziona solo su una rete wifi non
      protetta... o
      sbaglio?
      Su una LAN cablata concettualmente potrebbe anche
      funzionare, ma non così facilmente, richiederebbe
      altre tecniche "malevole" come ARP spoofing e
      compagnia
      briscola...
    • Pippo scrive:
      Re: No, un momento...
      Insomma sto stizio che si è inventato un semplice wireshark su firefox?
      • bubba scrive:
        Re: No, un momento...
        - Scritto da: Pippo
        Insomma sto stizio che si è inventato un semplice
        wireshark su
        firefox?sto tizio ha inventato un tool x scimmie ritardate che fa tanto hype (appunto per quello) ,ma le tecniche sono poi sempre le stesse : sniffing su reti wifi aperte (o -fatto in separata sede- ARP poisoning su wired lan) , collecting dei cookie e spararli verso il sito "target", per 'rubarne' l'identita.Naturalmente essendo il collecting & co dei cookie molto specifico per il singolo sito bersaglio (ci sono i digest, md5, ecc.. deve replicare nel giusto modo) e' chiaro che funzionera' bene nei primi tempi, e poi i "target" in lista, cambieranno qualcosa, e se nessuno aggiorna il tool, non fungera' piu'. ANCHE se la tecnica in se continuera' ad andare sinche' tutto non sara' criptato end-to-end, o il sistema usera' qualcosa di molto clever [es: pgp/aes/smime in javascript] ... (ma comunque riduplicabile ,visto che si puo sniffare).
        • H5N1 scrive:
          Re: No, un momento...
          - Scritto da: bubba
          sto tizio ha inventato un tool x scimmie
          ritardate che fa tanto hype (appunto per quello)
          ,ma le tecniche sono poi sempre le stesse :
          sniffing su reti wifi aperte (o -fatto in
          separata sede- ARP poisoning su wired lan) ,
          collecting dei cookie e spararli verso il sito
          "target", per 'rubarne'
          l'identita.

          Naturalmente essendo il collecting & co dei
          cookie molto specifico per il singolo sito
          bersaglio (ci sono i digest, md5, ecc.. deve
          replicare nel giusto modo) e' chiaro che
          funzionera' bene nei primi tempi, e poi i
          "target" in lista, cambieranno qualcosa, e se
          nessuno aggiorna il tool, non fungera' piu'.
          ANCHE se la tecnica in se continuera' ad andare
          sinche' tutto non sara' criptato end-to-end, o il
          sistema usera' qualcosa di molto clever [es:
          pgp/aes/smime in javascript] ... (ma comunque
          riduplicabile ,visto che si puo
          sniffare).Non credo.L'unico modo per evitare lo sniffing è usare SSL (https).E' un difetto by design .Il cookie-stealing non necessita di particolari accorgimenti: in pratica adotta la stessa tecnica del salvataggio delle sessioni dei vari browser.Solo che le sessioni non sono le tue :)Il tutto è gestito da un handler (uno per ogni dominio previsto) presenti in "handlers" tramite back-end che è un vero e proprio "spoofer" (un eseguibile in Windows e Mac OSX): firesheep-backend.L'uovo di colombo.
Chiudi i commenti