L'attivazione predefinita dell'API Idle Detection in Chrome 94 ha portato a una ondata di critiche con riferimenti alle obiezioni da parte degli sviluppatori di Firefox e WebKit\/Safari. <\/p>\n
L'API Idle Detection consente ai siti di determinare il tempo in cui l'utente non \u00e8 attivo, ossia non interagisce con la tastiera\/mouse o sta lavorando su un altro monitor. L'API consente anche di sapere se un salvaschermo \u00e8 attivo o meno. L'informativa sull'inattivit\u00e0 viene effettuata tramite l'invio di una notifica dopo aver raggiunto una soglia di inattivit\u00e0 impostata, il cui valore minimo \u00e8 fissato a 1 minuto. <\/p>\n
\u00c8 importante notare che l'applicazione dell'API Idle Detection richiede un esplicito consenso da parte dell'utente, ovvero se l'applicazione tenter\u00e0 per la prima volta di rilevare l'inattivit\u00e0, verr\u00e0 mostrata all'utente una finestra che propone di fornire il consenso o di bloccare l'operazione. Per disattivare completamente l'API Idle Detection, \u00e8 prevista un'opzione specifica nella sezione delle impostazioni \u00abPrivacy e sicurezza\u00bb (chrome:\/\/settings\/content\/idleDetection). <\/p>\n
Tra le aree di applicazione vengono citate le applicazioni di chat, social networking e comunicazione, che possono modificare lo stato dell'utente in base alla sua presenza al computer o rimandare la visualizzazione delle notifiche sui nuovi messaggi fino al ritorno dell'utente. L'API pu\u00f2 anche essere utilizzata nelle applicazioni chioschio per tornare alla schermata iniziale dopo un certo periodo di inattivit\u00e0 o per disattivare operazioni interattive ad alto consumo di risorse, come il ridisegno di diagrammi complessi continuamente aggiornati, quando l'utente non \u00e8 davanti al computer. <\/p>\n
La posizione degli oppositori all'inserimento dell'API Idle Detection si basa sul fatto che le informazioni riguardanti la presenza dell'utente al computer possano essere considerate riservate. Oltre ad usi utili, questa API pu\u00f2 anche essere utilizzata per scopi meno nobili, ad esempio per tentativi di sfruttare vulnerabilit\u00e0 durante l'assenza dell'utente o per nascondere attivit\u00e0 dannose evidenti, come il mining. Attraverso l'API in esame, \u00e8 possibile raccogliere informazioni sui modelli di comportamento dell'utente e sul ritmo della sua giornata lavorativa. Per esempio, \u00e8 possibile scoprire quando l'utente di solito va a pranzo o lascia il posto di lavoro. In un contesto in cui \u00e8 richiesto il consenso per il conferimento di poteri, queste preoccupazioni sono considerate da Google come insignificanti. <\/p>\n
Inoltre, si pu\u00f2 notare la nota degli sviluppatori di Chrome sullo sviluppo di nuove tecniche per garantire un uso sicuro della memoria. Secondo Google, il 70% dei problemi di sicurezza in Chrome \u00e8 causato da errori nella gestione della memoria, come l'accesso a un buffer dopo che la memoria associata \u00e8 stata liberata (use-after-free). Sono state identificate tre strategie principali per affrontare tali errori: il rafforzamento dei controlli in fase di compilazione, il blocco degli errori durante l'esecuzione e l'uso di un linguaggio che garantisca un uso sicuro della memoria. <\/p>\n
\u00c8 stato riferito l'inizio di esperimenti per l'aggiunta alla base di codice di Chromium della possibilit\u00e0 di sviluppare componenti nel linguaggio Rust. Il codice in Rust non \u00e8 ancora incluso nelle versioni destinate agli utenti e si concentra principalmente sul test della possibilit\u00e0 di sviluppare parti singole del browser in Rust e sulla loro integrazione con le altre parti scritte in C++. Parallelamente, per il codice in C++ continua a svilupparsi il progetto per l'uso del tipo MiraclePtr al posto dei puntatori raw per bloccare la possibilit\u00e0 di sfruttare vulnerabilit\u00e0 causate dall'accesso a blocchi di memoria gi\u00e0 liberati, e vengono proposti nuovi metodi per la rilevazione di errori in fase di compilazione. <\/p>\n