Discussione:Trusted computing


Ultimo commento: 18 anni fa, lasciato da Dbiagioli in merito all'argomento NPOV

Bella voce

e mi dispiace tirarmi le zappe sui piedi (aka andare contro il mio pov) ma

  • "lo sventolino" ...
  • critiche inserite direttamente nell'incipit, senza prima descrivere di cosa si tratti esattamente
  • una serie di controoindicazioni enorme
  • manca la descrizione dei vantaggi

insomma, se fossi un dipendente microsoft lo dichiareri nNPOV subito ;) --Riccardo 16:11, 14 giu 2006 (CEST)Rispondi

NPOV

Credo che questo articolo manchi molto di neutralità. Non apporto al momento modifiche perchè non saprei da dove cominciare. Non stiamo parlando del Partito Nazista, che fa parte della nostra storia, ma parliamo di qualcosa che non è ancora effettivamente tra noi. Non sappiamo effettivamente come sarà la vita con TPM nei nostri processori e già su Wiki vedo le tesi degli oppositori troneggiare come verità. Mi limito a segnalare alcune parti del testo dove la neutralità viene intaccata.

  • In altre parole, i dispositivi che implementeranno tale tecnologia non faranno funzionare applicazioni ritenute non affidabili (e quindi non permesse) dai produttori. Non è detto! O almeno non in senso assoluto. Se un'applicazione non sarà trusted, a limite non potrà beneficiare di funzionalità avanzate offerte da TPM, o girerà in modalità superprotetta a risorse limitate. Ma non lo sappiamo ancora...
  • Gli utenti non possono cambiare software,Gli utenti non hanno il controllo delle informazioni che ricevono,Gli utenti non hanno il controllo dei propri dati,Perdita dell'anonimato su Internet,Censura dei contenuti sono titoli a mio avviso fuorvianti. Non nego che ci sarà il supporto tecnologico per realizzare tutto ciò, ma modificherei i titolo usando il condizionale piuttosto che l'indicativo e comunque meno verbi possibile, e taglierei o uniformerei a NPOV molti stralci, tra cui quello di MSN e Internet Explorer, che ritengo realmente fuori luogo. Sul controllo dei propri dati, sull'esempio del giornale ecc. non so proprio cosa dire: sicuramente si mettono in testa ai lettori cose da olocausto, ma è pur vero che non va abbassata la guardia contro un reale pericolo.

Secondo me è fondamentale che qualcuno qui, anche oppositore del TC, si sforzi di tirar fuori un po' di obiettività e fare una lista delle indicazioni prima delle controindicazioni (nei farmaci le controindicazioni seguono sempre le indicazioni terapeutiche quindi imparzialità sull'ordine di rappresentazione). Sono comunque a disposizione per ulteriori discussioni sulle modifiche da apportare. --ΕΨΗΕΛΩΝ 16:19, 17 giu 2006 (CEST)Rispondi


il problema e' proprio questo  : quali sono le indicazioni ? moduli come l'enforcer o "trusted gentoo" , che sono implementazioni libere e gia ' funzionanti nonche gratis del software stack necessario per usare un TPM , non li usa praticamente nessuno .. a questo punto uno si chiede a cosa serva il TC se non a far funzionae PVP-OPM e PVP-UAB e PUMA (tecnologie DRM in windows vista) che richiedono il memory curtaining . comunque se trovi degli usi utili del TC sei libero di illustrarli . Dbiagioli 22:16, 17 giu 2006 (CEST)DBiagioliRispondi
Premetto che non ho il tempo materiale per mettermi a fare tutte le modifiche necessarie. Cerchiamo di mantenerci oggettivi. Il DRM è, sfortunatamente o più che altro paradossalmente, la prima indicazione del TC. Tutti noi siamo praticamente contro i sistemi DRM, però dobbiamo accettare, nella nostra obiettività, che un sistema in grado di frenare il dilagare della pirateria è un'innovazione, un qualcosa di positivo. Tutelare la proprietà intellettuale del software contro la decompilazione è purtroppo qualcosa che va fatto. Ma già con lo stesso memory curtaining io posso difendere un kernel da attacchi di vario tipo da parte di virus, spyware ecc. Se pensiamo ai vari Blaster e Sasser ci rendiamo conto come un TPM avrebbe potuto proteggere i sistemi vitali del nostro Windows. Chiunque potrebbe contestarmi ma è Windows che aveva il bug, e io rispondo che spesso e volentieri su kernerl.org si vedono corretti dei bug, magari anche abbastanza seri. Tanto per fare un esempio in recente Yast Update del mio Linux c'era una falla di sicurezza in non-mi-ricordo quale componente vitale del sistema che avrebbe permesso accesso root da locale ad un utente non privilegiato. Ma questa, comunque, è discussione per altri.
Quello che io ho voluto sottolineare nel mio commento è stato il fatto che l'articolo, per come è impostato in generale, si sofferma troppo sugli aspetti negativi potenziali del TC. Non abbiamo ancora software che realmente usa TC e non sappiamo che effetto avrà.
Come ipotizziamo che TC limiterà la nostra libertà, io ipotizzo, guardando il bicchiere mezzo pieno, che con TC ci sarà la fine del phishing perchè, anche se qualcuno bucasse il DNS, ci potremmo accorgere, da casa, mediante la Remote Attestation sul server della banca, che qualcosa non va... Lo stesso server bancario potrebbe controllare se abbiamo installato un qualche software spyware noto. Ma per apportare le correzioni non vanno solo aggiunte le tesi dei sostenitori del TC e le mie osservazioni ottimistiche. Vanno soprattutto riviste le sezioni. E non voglio farlo da solo.--ΕΨΗΕΛΩΝ 16:49, 18 giu 2006 (CEST)Rispondi
http://trousers.sourceforge.net/ http://trustedjava.sourceforge.net/ http://enforcer.sourceforge.net/ questo e' software che gia' oggi implementa l'accesso alle funzionalità del TPM . il fatto che nessuno sappia che esistano mi sembra abbastanza indicativo della reale utilita del TPM . una smartcard e' IMHO piu' utile per la sicurezza dei dati, anche se non permette il memory curtaining ... . quella cosa sul DNS e' teoricamente corretta , ma in pratica di attacchi tramite DNS spoofing mi sembra ce ne siano pochi in giro . comunque se vuoi mettila pure nell'articolo . fossi in te per le sezioni 'troppo critiche' lascerei intatto il contenuto cambiando il tono .. e mi spiace, dovrai farlo da solo . Dbiagioli 20:55, 18 giu 2006 (CEST)DBiagioliRispondi
Adesso vedo di fare alcune modifiche e aggiungere alcune cose che a mio avviso mancano...--ΕΨΗΕΛΩΝ 22:24, 18 giu 2006 (CEST)Rispondi
Ho fatto delle modifiche per rendere l'articolo più NPOV, tuttavia osservo nelle controindicazioni una certa surrealità. Se leggete attentamente il testo delel controindicazioni vi rendete conto che ci troviamo di fronte a cose da capogiro. Non le ho rimosse perchè sono fanno comunque parte delle tesi dei contestatori del TC. Però mi piacerebbe tornassimo coi piedi per terra.--ΕΨΗΕΛΩΝ 22:48, 21 giu 2006 (CEST)Rispondi
potresti essere piu' preciso ? tra parentesi , tra la SONY ha distribuito un rootkit come parte integrante di un sistema DRM , ed e' stata penalmente condannata per questo , quindi fossi in te io considererei anche eventi futuri che oggi sembrano improbabili... Dbiagioli 10:46, 22 giu 2006 (CEST)DBiagioliRispondi
Non mi riferivo a DRM, ma a censura, forzatura all'uso del programma X ecc. Il DRM è pura realtà, e sono stato costretto a porlo tra le indicazioni. Il problema della privacy non è di per sè TC ma i rootkit. Cioè se qualcuno usa TC per un super rootkit non è colpa di TC ma di chi ha fatto il rootkit. Vorrei che le controindicazioni si limitassero al TC di per sè, visto che comunque anche senza si fanno molte cose. La Remote Attestation è fattibile anche con un client closed source fatto come si deve. TC impedisce solo di crackarlo.--ΕΨΗΕΛΩΝ 13:12, 22 giu 2006 (CEST)Rispondi
beh ,in realta di per se ,il TC di controindicazioni non ne ha .. ma le aziende che lo propongono non hanno una storia di "paladini della privacy e difensori dei diritti dei consumatori" .. quindi IMHO alcune preoccupazioni sono piu' che giustificate ... e' un po come dare un'arma in mano a un pregiudicato che dichiara di avere le migliori intenzioni di questo mondo . comunque sareebe interessante sentira anche il parere di altri wikipediani . Dbiagioli 17:15, 22 giu 2006 (CEST)DBiagioliRispondi

Endorsement Key

Vorrei segnalare che, in base alle specifiche TCG, l'Endorsement Key non è la chiave che identifica univocamente un PC in rete. Al contrario, è una chiave che garantisce solo che il TPM è conforme alle specifiche, impedendo agli emulatori di avviare transazioni sicure.
Purtroppo la cosa è stata oggetto di incomprensioni un po' ovunque in Rete. Dall'Endorsement Key, come descritto da me, si passa poi all'AIK che certifica l'identità della macchina...
--ΕΨΗΕΛΩΝ 22:42, 18 giu 2006 (CEST)Rispondi

Ritorna alla pagina "Trusted computing".