Google Chrome: Diferenzas entre revisións

* Un identificador (ID) único (''«clientID»'') Un identificador único (ID) ("clientID") para identificar ao usuario nos rexistros de acceso. Aínda que parece que nas próximas versións eliminaranoeliminaránno.<ref>{{Cita web|url=https://www.actualidadgadget.com/google-chrome-ya-no-tendra-id-unico/|título=Google Chrome xa non tendrá ID único|páxina-web=ActualidadGadget|data=13 de marzo de 2010|url-arquivo=https://web.archive.org/web/20170912235639/https://www.actualidadgadget.com/google-chrome-ya-no-tendra-id-unico/|data-arquivo=12 de septembro de 2017|data-acceso=2 de agosto de 2020|idioma=inglés}}</ref>

[[Arquivo:Chromium Browser.png|thumb|ImaxenImaxe dunha ''pestaña triste'' ao «colgarse» unha pestaña do navegador, baixo [[Ubuntu]].]]

O equipo de desarrollodesenvolvemento encargado de [[Google Gears|Gears]] estaba a estudar a posibilidade dun navegador [[multiproceso]] (hai que destacar que un problema coas implementacións actuais para [[Navegador web|navegadores web]] é que son inherentemente dun único proceso) e Chrome aplicou este concepto cunha arquitectura de [[multiprocesamento]] similar á usada por [[Internet Explorer 8]]. A cada tarefa (por exemplo, pestañas, plugins) asignallese un proceso separado. EstoIsto impide que as tarefas interfiran entre si, o que é bo para a seguridade e a estabilidade; cada pestaña en Chrome se [[aislamiento de procesos (informática)|aísla]] (do inglés ''sandbox'', textualmente ''caixa de arena'') para ''«evitar a instalación de [[malware|software malicioso]]»'' o ''«impedir que o que ocurre nunha pestaña podapoida afectar ao que sucede en outra»'', nun modelo de asignación de procesos complexo.<ref>{{Cita web|url=https://blog.marcchung.com/2008/09/chromes-process-model-explained.html|título=Modelo de proceso de Chrome explicado|páxina-web=Blog Marcchung|data=5 de septembro de 2008|data-acceso=4 de agosto de 2020|url-arquivo=https://web.archive.org/web/20100609171606/http://blog.marcchung.com/2008/09/05/chromes-process-model-explained.html|data-arquivo=9 de xuño de 2010}}</ref> Si por algún motivo unha mala programación dunha páxina web o un plugin determinado ocasionan un cuelgue, só a pestaña actual quedará danada deixando o resto intacto. Esta pestaña fallada converterase nunha «pestaña triste», concepto similar á pantalla de erro das versións anteriores do sistema operativo [[Mac OS]], a ''[[sad Mac]]''.

Seguindo o principio de mínimo privilegio, cada proceso quítase dos seus dereitos e, polo tanto, non pode escribir nin ler arquivos en zonas sensibles (por exemplo, documentos, escritorio). Este método é similar ao «modo protexido» empregado por [[Internet Explorer]] en [[Windows Vista]]. O equipo de desarrollodesenvolvemento encargado de «Sandbox» asegura que ''«converteron as súas fronteiras nos procesos nunha prisión»''. Por exemplo, un software malicioso que se executa nunha pestaña non pode robar números de tarxetas de crédito, interactuar co rato ou dicir ao sistema operativo que execute un programa no inicio do sistema e, ademais, este proceso desaparecerá cando a pestaña estea pechada. EstoIsto non é máis que a imposición dun simple modelo de seguridade informática segundo o cal hai dous niveis de seguridade multinivel: ''usuario'' e ''caixa de arena''. A ''caixa de arena'' só pode responder ás solicitudes de comunicación iniciadas polo ''usuario''.

Algúns [[Plugin|plugins]] como o [[Adobe Flash Player]] non siguen algúns estándares de seguridade e por isto non poden ser [[Aislamiento de procesos (informática)|aislados]] como as pestañas. EstosEstes a menudomiúdo necesitan ser executados ao mesmo ou superior nivel de seguridade do propio navegador. Para reducir a exposición a un ataque, os plugins funcionan en procesos separados que se comunican co motor de renderizado, que á súa vez funciona con «privilegios moi baixos» en procesos dedicados para cada pestaña. Estes complementos terán que ser modificados para funcionar dentro desta [[arquitectura de software]] e así seguir así os principios de mínimos privilegios.