Qualche dettaglio tecnico
Il motore di Chrome è WebKit, un renderer HTML piuttosto leggero sviluppato da Apple con parti del progetto KDE, quindi componenti open source KHTML. WebKit riesce di fatto a mettere in equilibrio performance, rispetto degli standard e affidabilità. Nel tempo poi si è dimostrata buona anche la sua portabilità, scalabilità e potenzialità di embedding.
In qualità di renderer lo troviamo infatti sul browser Apple Safari (sia mobile che desktop), ed è stato adottato da Adobe AIR runtime, Trolltech Qt toolkit, dal browser della piattaforma Nokia S60, e dal browser di Google Android.
Sebbene Chrome sfrutti WebKit, gli sviluppatori hanno deciso di evitare l'ultima implementazione JavaScript runtime di Google, SquirrelFish. V8 è stato preferito perché è una virtual machine, sviluppata in Danimarca, che fin dall'inizio è stata pensata per applicazioni online in grande scala che fanno ampio uso di JavaScript. Caratterizzante anche la presenza di un compiler JIT integrato che genera un codice nativo in tempo reale.
Da non dimenticare inoltre il sistema multi-processo: dove ogni TAB e plugin avvia un processo indipendente, in modo da migliorare la stabilità e prevenire un'eccessiva frammentazione della memoria. Quando un bug nel rendering causa un crash in una pagina, il TAB correlato salta ma il resto del browser procede tranquillamente.
Google Chrome ci è piaciuto molto, soprattutto per le prestazioni. Bisogna un po' abituarsi al rinnovato utilizzo delle schede (se provenite da Explorer), ma la sensazione è che il tutto sia piuttosto funzionale. È vero che ogni minuto con il mouse cercavamo l'icona della pagina iniziale, ma qui si tratta di affidarsi un po' di più alla stringa degli indirizzi. Da lì in poi la tendina speciale risolve ogni problema. In verità alla fine abbiamo scoperto che sufficiente andare su Opzioni per far comparire il pulsante Home.
Nelle ultime ore è stato rilevato il primo bug: una vulnerabilità che potrebbe consentire un carpet bombing. Insomma, un malintenzionato potrebbe associare la vulnerabilità del WebKit e un bug Java già noto: il tutto per mettere l'utente in condizione di aprire, a sua insaputa, file eseguibili via browser.