La lentezza della rete tricolore

Le connessioni italiane viaggiano a velocità decisamente più basse di quelle promosse dai singoli operatori, dice SosTariffe. Dal 2010, la velocità media è salita di soli 8 punti percentuali, trascinata dalle offerte 20 Mega

Roma – Dagli studi di SosTariffe, un’ analisi approfondita della velocità media delle connessioni Internet in Italia. Dai risultati di oltre 500mila test di velocità effettuati dagli stessi utenti dal 2010, le connessioni ADSL tricolore sono cresciute molto lentamente negli ultimi 3 anni, con una velocità media di 5,1 Megabit al secondo (solo +8 per cento rispetto ai rilevamenti di tre anni fa) .

Come spiegato dall’osservatorio di SosTariffe, “L’incremento di circa l’8 per cento dell’anno scorso è da attribuirsi, molto probabilmente, alla maggiore disponibilità di offerte a 20 mega da parte degli operatori e del relativo aumento di sottoscrizioni, che hanno fatto registrare questa crescita della velocità media”.

Pur partendo da una maggiore disponibilità sul territorio nazionale, le offerte a 20 mega restano comunque le più costose e, proprio per questo, le meno frequenti. Per quanto concerne le comuni connessioni ADSL, gli strumenti di comparazione offerti sul sito di SosTariffe hanno mostrato una vistosa discrepanza tra le velocità promesse dai singoli operatori e quelle effettivamente consumate dagli abbonati.

Ad esempio, le velocità a 7 Megabit raggiungono un valore medio reale di 4 Megabit . Quelle più costose a 20 Mega sono certamente più veloci, ma non di molto, appena 7,1 Mbps. “Le 20 mega sono in lenta, ma costante crescita dal 2010 a oggi – spiegano ancora i responsabili dell’osservatorio – e costituiscono ormai quasi il 40 per cento del totale delle offerte. Le ragioni sono da identificare in una maggiore copertura e in promozioni più aggressive dal lato degli operatori, e una maggiore richiesta di traffico da parte degli utenti”.

A livello locale , tra le regioni più veloci si trovano la Toscana (5,6 Mpbs in media), la Liguria (stesso valore) e la Campania (5,4 Mpbs) . “La Toscana si conferma la regione con le linee più veloci: è l’unica regione italiana dove le 20 Mega superano mediamente gli 8 Mbps, mentre lo stesso tipo di linea in Abruzzo si ferma a soli 5,7 Mbps. Per quanto riguarda le 7 Mega, le più veloci sono in Valle d’Aosta (4,5 Mbps di media), le più lente in Umbria, solo 3,2 Mbps”, spiega SosTariffe.

Secondo un altro recente studio dello stesso osservatorio, nel 2013 i risparmi ottenibili aderendo a nuove promozioni sono aumentati del 78 per cento, grazie a nuove offerte che prevedono periodi promozionali fino a 60 mesi o per sempre.

Mauro Vecchio

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

  • just to fill the blank scrive:
    pseudopseudorandom
    Senza dire che l'indebolimento del random pool per la generazione delle chiavi è sempre stata la tecnica favorita e ai come oggi pare essere la generazione dell'entropia e l'inizializzazione dei vettori rnd l'anello debole su cui si sta puntando.Numerosi casi si possono contare che hanno riguardato sia il mondo closed, che quello open, dai computer ai device.Alcuni algoritmi risentono meno di un deficit nella generazione random come RSA altri molto di più come il key exchange basato su DH o la generazione di chiavi Elgamal e DSS per quanto la cifratura assimmetrica e nella maggiorparte di quella simmetrica.Il fatto che il NIST prema per l'adozione delle implementazioni ECC dei rispettivi DH e DSS è un dato oggettivo e sospetto visto il caso Dual_EC_DRBG che a detta NSA era NIST SP 800-90 compilant and highly recommended.La necessità di avere un generazione di numeri casuali non prevedibile nella produzione di chiavi ECC-DH ECC-DS (già disponibili nella beta di gpg2), e della maggior parte degli algoritmi per la cifratura simmetrica di dispositivi e connessioni è fondamentale.Torvalds ha bollato con il suo inconfondibile stile la petizione contro l'adozione delle istruzioni RDRAND (che interfacciano i TRNG on chip) di Intel nel kernel linux, adducendo che sono solo uno dei tanti metodi per l'acquisizione dell'entropia necessaria, il che è indubbiamente vero, ma il fatto che Intel offra un hardware apposito nei suo prodotti danno certo uno spunto di riflessione."I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction" celebre frase pubblicata dallo sviluppatore del kernel Theodore Ts'o ha dato da pensare a molti.Personalmente continuerò ad usare RSA 4096 finchè mi sentirò sicuro, disabiliterò RDRANDR quando ne avrò la possibilità non farò affidamento all'harware di Intel per la generazione dell'entropia, lascierò che sia ancora la mia scheda audio a farlo, e per la cifratura dei blocchi mi affiderò ancora a serpent-xts-512 e userò Whirpool per l'hashing, e Camellia per le connessioni ssl-tls quando dovrò implementarla.
    • Jinta Yadomi scrive:
      Re: pseudopseudorandom
      - Scritto da: just to fill the blank
      Personalmente continuerò ad usare RSA 4096 finchè
      mi sentirò sicuro,Questa è un'ottima scelta. RSA 1024 bit IMO va oggi considerato craccato.Tuttavia vorrei farti notare che i tizi dell'NSA parlavano di un "importante svolta". Dubito che parlassero di qualche sabotaggio di standard o della possibilità di rompere una determinata lunghezza di chiave di RSA... è più probabile abbiano scoperto qualche proprietà importante in qualche algoritmo a chiave pubblica (RSA? Curve Elittiche? DiffieHellman?) che gli permette di decifrare con sforzo accettabile qualsiasi lunghezza di chiave. Purtroppo non ci è dato di sapere di che parlassero.Tuttavia, d'altro canto, da altre rivelazioni sembra invece che abbiano acXXXXX a qualche CA e quindi possano crearsi i propri certificati a piacere per impersonare qualsiasi sito WEB... questo però sembra contraddire l'interpretazione di "importante svolta" che ho dato sopra.Perciò al momento stiamo girando ancora a vuoto.
      disabiliterò RDRANDR quando ne
      avrò la possibilità non farò affidamento
      all'harware di Intel per la generazione
      dell'entropia, lascierò che sia ancora la mia
      scheda audio a farlo, e per la cifratura dei
      blocchi mi affiderò ancora a serpent-xts-512 e
      userò Whirpool per l'hashing, e Camellia per le
      connessioni ssl-tls quando dovrò
      implementarla.RDRAND non può influire nella generazione dei numeri casuali in Linux, per farlo dovrebbe essere stato sviluppato di proposito per far fallire l'algoritmo usato da Linux (quindi non funzionerebbe su Windows né su altri sistemi operativi, né funzionerebbe se l'algoritmo usato da Linux cambiasse) e avrebbe bisogno di riuscire a prevedere i dati ricevuti da altre fonti (per esempio leggendo la cache della CPU e riuscendo a distinguere tali dati) per poterle "annullare" nella XOR con cui quei dati vengono miscelati a quelli ricevuti da RdRand. Sarebbe un lavoro piuttosto complesso che influenzerebbe molte altre parti del proXXXXXre, con pochissime garanzie e facilmente annullabile cambiando algoritmo.Non c'è alcuna ragione di sospettare che tale istruzione fornisca sequenze prevedibili ma, anche se fosse, ugualmente non avrebbe alcuna influenza in Linux (per le ragioni esposte sopra). Disabilitarlo IMO sarebbe un errore. Non solo perché ti rallenta la generazione dei numeri casuali, ma anche perché ti toglie una fonte di entropia.Snowden non ha mai parlato di Intel. Perché te la prendi con RdRand ma non con il generatore hardware di VIA ad esempio? O quelli della Quantis? O quelli nelle smartcard? O quelle dei vari token disponibili? Perché proprio quello di Intel? Ti stupisce il fatto che finalmente i microproXXXXXri stiano supportando la generazione in hardware dei numeri casuali? Perché mai dato che sono sempre più usati (sia lato server, che client, che smartphone, che tablet, ecc)? È perfettamente normale che Intel cominci ad interessarsi, avrebbe dovuto farlo da lungo tempo.Supponiamo che lo standard per la generazione dei numeri pseudocasuali in software sia davvero fallato, che abbia davvero delle debolezze... disabilitando un generatore hardware non faresti altro che il gioco dell'NSA rendendo di fatto prevedibili i tuoi numeri pseudocasuali. In altre parole finiresti per spararti da solo sui piedi.Nello spezzone che citi di Theodore Ts'o dovresti, per completezza, anche citare le risposte di David Johnston (il tizio che ha fisicamente realizzato RdRand nei proXXXXXri Intel) che garantisce di:1) aver realizzato l'istruzione al meglio delle sue conoscenze/capacità2) di non aver mai ricevuto alcuna pressione da chicchessia durante lo sviluppo dell'istruzione stessa né alcun ordine segreto da parte di nessuno3) di aver verificato il funzionamento di RdRand con microscopio elettronico e microprobes una volta realizzato fisicamenteoltre alle risposte di un altro ex-ingegnere Intel che assicura che qualsiasi modifica allo schema del Chip avrebbe fatto scattare allarmi impossibili da ignorare e che una modifica post-progettazione è molto complessa e difficilmente passerebbe non vista (grazie ad almeno un centinaio di persone esperte [e di svariate nazionalità] che ci lavorano e ai sistemi automatici di verifica lungo tutta la linea di produzione).Fra l'altro... perché te la prendi con RdRand quando è l'intera CPU che potrebbe interferire con la generazione dei numeri pseudocasuali? Magari è l'istruzione XOR che attiva un comportamento "fallato" quando la CPU identifica determinate sequenze di istruzioni... che facciamo... disabilitiamo anche XOR?In altre parole a me sembra che qui ci si stia facendo prendere dalla paranoia e che questa paranoia stia spingendo più di qualcuno a fare scelte a dir poco premature se non addirittura contro-producente.
      • just to fill the blank scrive:
        Re: pseudopseudorandom

        RDRAND non può influire nella generazione dei numeri casuali in Linuxè esattamente quello che fa e ad un ritmo direi impressionante rngtest: input channel speed: (min=998.814; avg=2191.053; max=41392.283)Kibits/srngtest: FIPS tests speed: (min=34.935; avg=124.483; max=160.321)Mibits/sIl fatto che si siano fatte pressioni perchè fosse l'unica sorgente di entropia per /dev/random, per me è abbsatanza, non ho problemi di entropia sul pc come potrebbe averne un server con milioni di connessioni da gestire.Non è di per se del generatore che mi preoccupo, anzi benvenga un TRNG, è buona cosa, che comunque essendo standardizzato e inserito nella cpu può essere tranquillamente sfruttato in condizioni fault based in modo sistematico alterandone le condizioni di esercizio agendo per esempio sui voltaggi in modo preciso, ricostruendo quelle condizioni che per esempio hanno portato alla recente violazione di RSA1024 agendo sull'alimentatore di un pc. Perchè Via non ha mai fatto pressioni sugli sviluppatori kernel, perchè il metodo di generazione dipende da componenti fisiche che non vengono rilevate, i primi TRNG di Via sui C3 del 2003 già implementava 4 e dico 4 freerunning oscillators a cascata ciascuno, i generatori sono 2, esterni alla cpu, in posizione e orientamento diverso e infine i bit vengono mischiati, e non hanno implementato delle istruzioni proprietarie di cui non si conoscono i dettagli ma sono disponibili nell'hardware come /dev/tpm.Di tutti gli altri sistemi non faccio uso non ho device di sorta tranne un vecchio gsm, ma ho avuto due Epia una con C7 e una con Nano, e ci sono molte differenze tra quello che offre Via e quello che offre Intel.Il TRNG di intel soprattutto nella parte entropy source mi piace, il debiasing un po' meno, la sua collocazione non mi piace per niente.Quello di cui mi preoccupo è proprio RDRAND poichè non ho acXXXXX a /dev/tpm0 l'hardware che sta generando l'entropia ma devo affidarmi alle istruzioni Intel che sta fornendo l'entropia in un operazione vitale per l'efficacia dell chiavi crittografiche che vengono prodotte e che mai come oggi può compromettrene completamente la sicurezza.Gli pseudorandom non c'entrano, qui si sta parlando della qualità del seed per /dev/random, che personalmente continuerò ad affidare a sensori analogici. Appoggiare a pseudorandom la generazione delle chiavi è da suicidi.Bannerò i driver.
        • Jinta Yadomi scrive:
          Re: pseudopseudorandom

          Il fatto che si siano fatte pressioni perchè
          fosse l'unica sorgente di entropia per
          /dev/random, per me è abbsatanza, non ho problemi
          di entropia sul pc come potrebbe averne un server
          con milioni di connessioni da
          gestire.Secondo me il Ts'o sta esagerando quando dice "si sono fatte pressioni".Semplicemente l'ingegnere che ha progettato il generatore random è così sicuro del suo lavoro che vorrebbe fosse adottato "as is" a prescindere dalle altre sorgenti. Si tratta semplicemente di over-confidence nel proprio lavoro e nelle proprie capacità che in questo caso è sfociata in un suggerimento poco sensato. Se leggi la discussione su Google+ fra Ts'o e David Johnston probabilmente capirai meglio di che parlo... il tizio è semplicemente così orgoglioso del suo lavoro che prende quasi come un insulto personale il fatto che qualcuno non si fidi di lui. È un po' come quando ti criticano tuo figlio... anche se le osservazioni che fanno sono legittime tu le vedi come insulti a lui e a te.
          Non è di per se del generatore che mi preoccupo,
          anzi benvenga un TRNG, è buona cosa, che comunque
          essendo standardizzato e inserito nella cpu può
          essere tranquillamente sfruttato in condizioni
          fault based in modo sistematico alterandone le
          condizioni di esercizio agendo per esempio sui
          voltaggi in modo preciso, ricostruendo quelle
          condizioni che per esempio hanno portato alla
          recente violazione di RSA1024 agendo
          sull'alimentatore di un pc.Se quelli dell'NSA hanno acXXXXX all'alimentatore del tuo PC sono sicuro che la generazione dei numeri casuali sono l'ultimo dei tuoi problemi.IMO è una cosa buona che i generatori di numeri random siano creati direttamente in hardware nelle CPU. Questo permette di avere una sorgente di dati casuali ad alte prestazioni che aiutano gli algoritmi in software pseudocasuali a generare sequenze molto migliori. Alla fine questo tenderà ad aumentare la sicurezza dei sistemi correntemente in uso che magari oggigiorno si basano solo su algoritmi in software e pochi bit casuali recuperati da altre fonti (pensa ad esempio ad un server che non ha alcun input fisico con il mondo reale come tastiere, mouse, ecc). Non puoi per esempio pretendere che il server su cui fai girare la tua pagina PHP sia dotato di una scheda RNG in hardware (anche perché sono tendenzialmente costose)... ma se tale RNG è implementato nella CPU lo ottieni "gratis". Così i flussi di dati crittati fra te e quel server saranno più sicuri.Se ci si fa prendere dal "panico" irrazionalmente si finisce appunto per fare scelte sbagliate e preferire tecnologie qualitativamente inferiori per meri sospetti. Ripeto, non ci sono oggettivamente prove di alcun tipo a sostegno della tesi che l'istruzione RDRAND delle CPU Intel delle nuove generazioni sia in qualche modo compromessa. Ts'o non voleva accusare Intel di aver voluto sabotare l'algoritmo di generazione di numeri casuali di Linux, ha semplicemente detto che dopo le rivelazioni dell'NSA è contento di non aver fatto come alcuni ingegneri Intel suggerivano ovvero di affidarsi unicamente al loro generatore hardware quando disponibile (e le ragioni per cui l'hanno fatto l'ho spiegato sopra, almeno per come la vedo io). Questa non è la stessa cosa di dire "l'RDRAND di Intel è stato sabotato".
          Perchè Via non ha mai fatto pressioni sugli
          sviluppatori kernel, perchè il metodo di
          generazione dipende da componenti fisiche che non
          vengono
          rilevate, i primi TRNG di Via sui C3 del 2003
          già implementava 4 e dico 4 freerunning
          oscillators a cascata ciascuno, i generatori sono
          2, esterni alla cpu, in posizione e orientamento
          diverso e infine i bit vengono mischiati, e non
          hanno implementato delle istruzioni proprietarie
          di cui non si conoscono i dettagli ma sono
          disponibili nell'hardware come
          /dev/tpm.Ciò non toglie che possano essere sabotati. La CPU VIA potrebbe per esempio sostituire i bit ricevuti dal generatore hardware e sostituirli con bit farlocchi (magari quando riconosce determinati pattern nel codice o quando riceve un segnale esterno particolare, tieni conto che qualsiasi software tu lanci in esecuzione alla fine è sempre e solo la CPU che svolge le azioni richieste... e non hai modo di sapere se le sta svolgendo correttamente o se si sta comportando in modo "bizzarro")... il fatto che la CPU/chipset VIA è una black-box né più né meno di quella Intel. Puoi solo fidarti delle loro descrizioni... a meno che tu non sia in possesso delle conoscenze necessarie e di un microscopio elettronico...Ma IMO ci stiamo preoccupando troppo di queste cose. Fare "carognate" del genere è costoso, con poche garanzie, e moltissimi rischi per le aziende che si prestano a questi giochetti. Se un giorno dovesse venire fuori che Intel (o VIA) ha sabotato i suoi proXXXXXri per favorire l'NSA sarebbe un disastro economico (forse mortale) per lei perché nessuno si fiderebbe più dei suoi prodotti.È enormemente più semplice installare da remoto un Trojan nel tuo PC (vedi recente caso FreeHosting e la facilità con cui l'hanno fatto) e bypassare così qualsiasi software di cifratura tu usi che impelagarsi in improbabili attacchi che richiedono la corruzione di centinaia di professionisti (ognuno dei quali potrebbe parlare e presentare prove, anche via TOR per proteggere la propria incolumità). È enormemente più semplice inserire un proprio "agente in borghese" ad alti livelli dentro Microsoft, o Google, o Apple e poter inserire backdoor qui o lì o inserire "spie" in grado di vedere quello che fai _dopo_ che la cifratura ha fatto il suo lavoro (ovvero ha trasportato i dati in modo sicuro da casa tua al loro datacenter). O anche inserire backdoor in hardware o software nel tuo router e poter accedere alla tua rete locale a piacere dall'esterno.Siamo circondati dalla tecnologia, e purtroppo noi europei siamo stati stupidi a sufficienza da "delegare" la fabbricazione dei nostri chip ad aziende in nazioni estere poco affidabili (USA, Cina, ...). E ora ci troviamo in una posizione di debolezza che ci sta lasciando con le braghe calate. Abbiamo persino permesso che Microsoft si comprasse Nokia...Quello che dobbiamo fare ora è mettere su le NOSTRE aziende di chip, le NOSTRE aziende di software e sistemi operativi e dire agli USA "grazie ma no grazie, facciamo da noi, non ci fidiamo più dei vostri prodotti, ringraziate l'NSA". Paradossalmente l'NSA potrebbe aver fatto proprio quello che cercava di evitare... ovvero con le loro azioni hanno di fatto danneggiato gli USA più di quello che poteva fare qualsiasi beduino afgano.
        • Jinta Yadomi scrive:
          Re: pseudopseudorandom
          - Scritto da: just to fill the blank

          RDRAND non può influire nella generazione dei
          numeri casuali in
          Linux
          è esattamente quello che fa e ad un ritmo direi
          impressionante

          rngtest: input channel speed: (min=998.814;
          avg=2191.053;
          max=41392.283)Kibits/s
          rngtest: FIPS tests speed: (min=34.935;
          avg=124.483;
          max=160.321)Mibits/s

          Il fatto che si siano fatte pressioni perchè
          fosse l'unica sorgente di entropia per
          /dev/random, per me è abbsatanzaNon ne sono sicuro, ma credo che Ts'o si riferisca a questo thread:https://lkml.org/lkml/2013/9/5/212Se si tratta di questo thread dire che "ha ricevuto pressioni" IMO è decisamente un'esagerazione. Semplicemente un tizio (che pare lavorare per RadHat) ha inviato una patch che permettesse all'utente di usare l'RNG in hardware di cui si fidasse direttamente tramite un'opzione (fra l'altro l'opzione mi pare non fosse nemmeno specifica per RDRNG).Io sono sempre stato un forte sostenitore delle "opzioni". Trovo per esempio molto sensato quello che Linus diceva di Gnome quando sosteneva che "se create un DE per stupidi solo gli stupidi useranno il vostro DE".IMO la facoltà di scegliere è fondamentale, preferisco sempre un software che mi da la possibilità di personalizzare il più possibile piuttosto che uno che invece ragiona stile Gnome ovvero "quest'opzione confonderebbe i nostri utenti quindi non la mettiamo".Se si tratta di questo thread ritengo la reazione di Ts'o ampiamente esagerata anche perché non puntava nemmeno a modificare il comportamento "di default" di Linux e del suo RNG.-----------------------------------------------------------Modificato dall' autore il 16 settembre 2013 17.15-----------------------------------------------------------
      • just to fill the blank scrive:
        Re: pseudopseudorandom

        In altre parole a me sembra che qui ci si stia
        facendo prendere dalla paranoia e che questa
        paranoia stia spingendo più di qualcuno a fare
        scelte a dir poco premature se non addirittura
        contro-producente.http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdfNon mi piace:We did not have access to Ivy Bridge parts, so Intel provided us with testing data from pre - production chips. These chips allow access to the raw ES output, a capability which is disabled in production chips. As a result,some runs (in particular, the spikenear the right side of the plot) show artifactswhere the testing machine began reading beforethe ES turned on. After discussing these artifacts with Intel, we believe that they cannot happen during operation.--off course--If the frequency ratio varies slightly, or the ES is only mostly stuck at 1, then the part may pass the health checks despite having little entropy.In our experiments, many samples pass the health checks even if the ES is96% stuck at 1. Such a failure would go undetected, and would bring the system outside its design margins. Since production parts cannot examine the ESs raw output, software would not be able to detect this failure either.In addition, developers should be aware that the RNG instructioncan be virtualized, and could be intercepted to deliver nonrandom data to applications.Dato che l'Entropy Source non è accessibile, e il TRNG non è un hardware accessibile, ha tutte le caratteristiche di una black-box.
        • just to fill the blank scrive:
          Re: pseudopseudorandom
          woops!http://punto-informatico.it/3956334/PI/News/freebsd-non-si-fida-dei-numeri-intel-via.aspx
  • Mario Rossi scrive:
    beata ignoranza
    ehmmm.. sucubi .. menomale tutto attaccato.. senò .. comprendo da come scrivi il livello culturale delle tue affermazioni.. :-)
    • Carlo scrive:
      Re: beata ignoranza
      - Scritto da: Mario Rossi
      ehmmm.. sucubi .. menomale tutto attaccato.. senò
      .. comprendo da come scrivi il livello culturale
      delle tue affermazioni..
      :-)Ed io comprendo dalla tua deduzione logica la profondità del tuo pensiero...Meglio sbagliare le doppie.
  • Dario Decimo scrive:
    Suditanza psicologica U.S.A.
    Israele
    Se gli U.S.A. hanno questo rapporto con israele è la dimostrazione dell'opinione che gli U.S.A. non hanno una propria identità culturale (e sono sucubi dei libri sacri Ebraici di 5.000 anni fa)... menomale che l'Europa ha impedito il libero scambio dei film tra U.S.A. ed Europa (senò ci ritrovavamo, tra qualche anno, una serie di plagi da far paura!)... comunque, non penso che la Gran Bretagna sia messa meglio degli U.S.A.
    • Gingle scrive:
      Re: Suditanza psicologica U.S.A.
      Israele
      E ti pareva che non poteva mancare la frecciatina antisemita? (o antisionista o contro un governo israeliano di turno -è lo stesso-) "Gli ebrei di quà, gli ebrei di là...". E' singolare (ma prevedibile) che lei dimostri che "il rapporto degli U.S.A. con Israele [esiste] perché non hanno una propria identità culturale (e sono suc(c)ubi dei libri sacri Ebraici di 5.000 anni fa)", rapporto sul semplice fatto che Israele è un Paese civile, democratico, diga dei diritti umani e di civiltà in mezzo ad un oceano di paesi islamici violenti e teocratici.Insomma, dalle sue esternazioni, si evince che la presenza di lacune in un Paese Occidentale, è da "imputarsi" alla presenza di Israele (e dunque degli ebrei).
      • Jinta Yadomi scrive:
        Re: Suditanza psicologica U.S.A.
        Israele
        - Scritto da: Gingle
        E ti pareva che non poteva mancare la frecciatina
        antisemita? E ti pareva che non poteva mancare il difensore a spada tratta degli israeliani (che con i palestinesi [che hanno derubato dei loro stessi territori] si stanno comportando né più né meno dei nazisti nei confronti degli ebrei).http://www.youtube.com/watch?v=T1QwnbnGQUU
  • tucumcari scrive:
    in passato
    in passato, dicono le indiscrezioni, gli agenti dell'FBI avrebbero chiesto a Microsoft di inserire backdoor funzionanti all'interno del software di cifratura BitLoker, ennesimo tentativo di compromissione delle tecnologie crittografiche a cui gli inegneri al tempo impiegati presso Redmond si sono apparentemente opposti.In passato naturalmente per la parte "In presente" e "In futuro" potete stare tranquilli... Quando Microsoft fa queste cose le fa sempre "In passato"... :D
    • scan scrive:
      Re: in passato
      Ciao Leguleio! ;-)
    • bubba scrive:
      Re: in passato
      - Scritto da: tucumcari
      in passato, dicono le indiscrezioni, gli agenti
      dell'FBI avrebbero chiesto a Microsoft di
      inserire backdoor funzionanti all'interno del
      software di cifratura BitLoker, ennesimo
      tentativo di compromissione delle tecnologie
      crittografiche a cui gli inegneri al tempo
      impiegati presso Redmond si sono apparentemente
      opposti.

      In passato naturalmente per la parte "In
      presente" e "In futuro" potete stare
      tranquilli...

      Quando Microsoft fa queste cose le fa sempre "In
      passato"...
      :Deheheh... "peccato" pero' che quello che si oppose fieramente all'illazione ,e a testa del progetto, era Niels Ferguson .. l'amicone dell'"idolo degli anti-nsa" Schenier... allora anche Schenier e' parte del Gomblotto?
      • bubba scrive:
        Re: in passato
        Schneier ... (non so piu scrivere)
      • tucumcari scrive:
        Re: in passato
        - Scritto da: bubba
        - Scritto da: tucumcari

        in passato, dicono le indiscrezioni, gli agenti

        dell'FBI avrebbero chiesto a Microsoft di

        inserire backdoor funzionanti all'interno del

        software di cifratura BitLoker, ennesimo

        tentativo di compromissione delle tecnologie

        crittografiche a cui gli inegneri al tempo

        impiegati presso Redmond si sono apparentemente

        opposti.



        In passato naturalmente per la parte "In

        presente" e "In futuro" potete stare

        tranquilli...



        Quando Microsoft fa queste cose le fa sempre "In

        passato"...

        :D
        eheheh... "peccato" pero' che quello che si
        oppose fieramente all'illazione ,e a testa del
        progetto, era Niels Ferguson .. l'amicone
        dell'"idolo degli anti-nsa" Schenier... allora
        anche Schenier e' parte del
        Gomblotto?se si volesse stilare una classifica anti-NSA il primo posto sarebbe del più famoso tra gli ex -NSA whitfield diffie ;)
Chiudi i commenti