Bug nel JavaScript di Firefox: dati sensibili a rischio

mi fa piacere che ti piaccia

sto lavorandoci su, voglio migliorarlo un poco soprattutto nei caricamenti delle pagine di firefox

L'ho usato per parecchio tempo: mai avuto i problemi di cui parli. Qualche schermata blu m'è capitata, ma molto raramente (poi io lo trattavo veramente il sistema, facendo esperimenti con gli hook di sistema).

Beh, sono passati 4 anni e 5 da Windows 2000 (che era già molto, ma molto meglio di Win98SE): dimmi tu se ALL'EPOCA di Windows 98 (o delle precedenti versioni) ci fossero delle soluzioni alternative ALMENO usabili e produttive.

Questo lo dici perché non hai idea cosa significa realizzare del software in generale, e cosa significhi sicurezza. Scrivere del codice "intrinsecamente sicuro" non è cosa facile, anche perché manca una definizione di codice "sicuro".

Sì, ma solamente a qualcuno.

No, non lavoro alla MS né ho potuto dare un'occhiata proprio ai sorgenti di IE che girano in rete, appartenenti a Windows 2000.
Ho però visto un sorgente di questo "pacchetto", debbo dire che il codice era scritto MOLTO BENE: perfino le macro, che in genere sono particolarmente criptiche, erano molto leggibili e ben documentate / commentate (come tutto il resto del codice).

Questo succede per qualunque software, come ho già detto e t'hanno spiegato. Se poi vai a dare un'occhiata anche ai bug che sono stati trovati per Mozilla, FireFox & co., ti accorgi che non sono affatto esenti da falle di sicurezza molto "gravi", che permettono di eseguire codice arbitrario.

Certo che è possibile farlo: non è certo colpa degli ActiveX, che sono delle "semplici" collezioni di componenti, ma dell'applicazione che li usa.

Vedi sopra: non è certo colpa loro. Tra l'altro col SP2 IE chiede il permesso prima, ma è IE a farlo, non gli ActiveX...

No. E infatti vedi sopra: FireFox & co. non usano gli ActiveX, ma sono state ugualmente trovate delle gravi falli di sicurezza.

Sì, gravi hacker, che puntano sul software più diffuso.

Hai un'idea errata sui formati proprietari: come t'ho già detto, sono SEMPRE ESISTITI. In qualche modo le informazioni si devono salvare, no?

Quando agli inizi degli anni '80 spuntò WordStar, che permetteva di scrivere file di testo strutturati, la società che lo sviluppava introdusse un SUO formato (proprietario, quindi), che permettava di conservare le informazioni che gli servivano. Avremmo dovuto trucidare i programmatori per quest'affronto alla libertà personale? Non credo proprio: era un normale esigenza, risolta come s'è sempre fatto.

MS, come ho già detto, è l'ultima arrivata, e ha rilasciato da parecchi anni le specifiche dei file prodotti con Office '97: con le versioni successive non ha fatto lo stesso, ma in ogni caso puoi:
- farne a meno e usare quelli vecchi;
- in qualsiasi momento puoi esportare i tuoi dati in parecchi formati.
Quindi, come vedi, il problema non si pone.

Tra l'altro erroneamente la gente considera come "liberi" formati come MP3, MPEG 1/2/4, ecc.: non è affatto vero! Diritti e licenze sono FORTEMENTE in mano alle varie società che li hanno sviluppati / ideati, o che ne hanno realizzato alcune parti.

Anche qui ci sarebbe da discutere: perché usare MP3 anziché OGG Vorbis? Semplicemente perché all'epoca non c'era nulla di simile, OV non esisteva. MP3, quindi, s'è diffuso, e la gente è convinta che si tratti di un prodotto "libero".
Per verificare questo, prova a vedere se con xmms, noatun, kaboodle, o altre applicazioni Linux, riesci ad ascoltare un file MP3: non ci riuscirai, e come minimo ti apparirà un avvertimento che si tratta di un formato proprietario e per problemi di licenza non hanno potuto integrare il relativo codec o plugin.

Non sono motivi sufficienti, a mio avviso: sei troppo prevenuto nei suoi confronti. MS è e si comporta come tante altre software house. Tutto il mondo è paese, come si suol dire...

Se il monopolio esiste, magari si potrebbe anche pensare di farlo. Ma mi fai vedere com'è possibile fare a meno dell'ENEL e della corrente elettrica?

Mi spiace, ma m'è bastata già l'introduzione di "Codice Libero": ci tengo alla salute (mi si ritorce il fegato quando leggo alcune cose: per questo mi sono fermato all'introduzione di quel libro), e soprattutto debbo pensare a far campare la mia famiglia col mio lavoro di programmatore...

Fino a Windows 3.1 lo erano: poi no. IMHO, chiaramente.

Comunque, AI TEMPI, anche Windows 3.1 non era da buttar via...

Il codice si evolve: anzi, è normale che lo faccia, perché nascono sempre nuove esigenze.

Dal 1998 a oggi siamo passati da Windows 98 a Windows XP SP2, e XP / 64 è dietro le porte (per non parlare di LongHorn, che il prossimo anno porterà un'altra, grande, rivoluzione).

A parte questo, basta passare da Java al C++ o un altro linguaggio orientato agli oggetti senza un garbage collector, per ritrovarsi come minimo con un degli enormi problemi di memory leak.

Purtroppo ormai anche all'università si comincia a programmare in Java e, anzi, quasi sempre è l'unico linguaggio utilizzato e studiato per quanto riguarda la programmazione in generale, e a oggetti in particolare.

Francamente preferirei il Pascal a oggetti, che è fortemente tipizzato (quindi obbliga a capire bene con quali strutture / tipi di dati si ha a che fare, e COME gestirli), e che richiede l'uso di costruttori E distruttori quando si comincia a lavorare con gli oggetti.

Lo so: sono troppo di parte...

Mumble... Devo dargli una ripassata prima o poi...

Sulla sicurezza ho miei dubbi.

D'altra parte, da EONI è possibile attivare, ad esempio, il controllo sugli indici degli array, o addirittura sull'overflow delle operazioni, ma chi l'ha mai fatto? Si va sempre di fretta, e poi se ne pagano le conseguenze...

Però io uso Opera...

Scusatemi per gli orrori grammaticali: sono troppi da correggere e il tempo che ho è poco...

Mi inserisco in questa vostra discussione perche' e' interessantissima.

Riporto una frase di Don Box che riguarda proprio questo argomento, dove, piu' o meno, dice: "Ogni volta che un nuovo linguaggio o un nuovo paradigma alza il livello di astrazioni, c'e' qualcuno che si lamenta perche' non ha piu' il controllo che aveva prima. E' successo con con il passaggio dall'Assembly al C/C++ ed ora succede col passaggio da codice unmanaged a codice managed. I vantaggi derivati dall'aumento del livello di astrazione hanno sempre superato gli svantaggi dovuto al minore controllo".

Don Box si riferisce al codice gestito (managed) dal framework .NET, ma il discorso e' identico per il codice gestito dalla JVM di Java.
Entrambi gli ambienti innalzano il livello di astrazione, ad esempio eliminando il concetto di memoria, introducendo un raccoglitore di rifiuti che si occupi di liberare gli oggetti non piu' usati, astraggono dai concetti quali il Thread introducendo concetti quali l'esecuzione asincrona.

Tutti questi cambiamenti limitano il programmatore come hai detto tu, gli danno un ambiente di lavoro piu' "controllato", "gestito" che limitano la possibilita' di commettere errori, rendono le applicazioni anche piu' sicure. Ma come hai aggiunto limitano anche l'espressivita' del programmatore nell'esprimere concetti richiesti da certi tipi di applicazioni. E non solo.

Il punto e' che ogni aumento del livello di astrazione e l'aumento di produttivita' che ne deriva portano ad inefficienze nell'esecuzione del codice.

La mia opinione e' che nel 99% dei casi l'aumento di produttivita' giustifichi ampiamente le inefficienze.

Poi esistono applicazioni particolari quali il Kernel di un sistemi operativo, posso anche aggiungere il render loop di un motore 3d, dove gestire i puntatori in maniera nativa, oppure il ciclo di vita di un oggetto, o avere il massimo controllo possibile sull'ambiente sono fondamentali, ma queste sono eccezioni, non la norma. E non credo che le eccezioni dovrebbero penalizzare la produttivita' e la sicurezza nella maggior parte delle applicazioni.

In sintesi sono totalmente a favore degli ambienti gestiti come Java e .NET. Credo sia solo una questione di strumenti ed usare gli strumenti adatti a risolvere un dato problema: devo scrivere il kernel di un sistema operativo, posso farlo in Java o C#? No, perche' non ho gli strumenti espressivi per esprimere determinati concetti. Devo scrivere un'architettura di streaming video peer to peer (), ha senso farlo in C/C++? Si', ma in C# posso esprimere tutti i concetti che mi servono e riesco a farlo in un terzo del tempo, quindi scelgo questo strumento.

D'accordo, e infatti ormai da mesi uso quasi esclusivamente Python come linguaggio / ambiente per lo sviluppo delle applicazioni dove lavoro, che offre un notevole livello di astrazione e permette di concentrare le energie sul problema da risolvere, piuttosto che perdere tempo in dettagli implementativi come l'allocazione o la liberazione della memoria...

I problemi sorgono per chi da questi linguaggi / ambienti "comodi" passa poi ad altri, che non offrono gli stessi meccanismi...