{"id":101387,"date":"2021-09-23T22:22:45","date_gmt":"2021-09-23T20:22:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kritika-vklyucheniya-api-idle-detection-v-chrome-94-eksperimenty-s-rust-v-chrome"},"modified":"2021-09-23T22:22:45","modified_gmt":"2021-09-23T20:22:45","slug":"kritika-vklyucheniya-api-idle-detection-v-chrome-94-eksperimenty-s-rust-v-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/kritika-vklyucheniya-api-idle-detection-v-chrome-94-eksperimenty-s-rust-v-chrome","title":{"rendered":"Critiche sull'inclusione dell'API Idle Detection in Chrome 94. Esperimenti con Rust in Chrome","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
L'attivazione predefinita dell'API Idle Detection in Chrome 94 ha suscitato una serie 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 quando l'utente \u00e8 inattivo, ovvero quando non interagisce con la tastiera\/mouse o svolge attivit\u00e0 su un altro monitor. L'API consente anche di verificare se un salvaschermo \u00e8 attivo nel sistema. La segnalazione di inattivit\u00e0 avviene mediante l'invio di una notifica dopo aver raggiunto una soglia di inattivit\u00e0 prestabilita, il cui valore minimo \u00e8 fissato a 1 minuto. <\/p>\n
\u00c8 importante notare che l'uso dell'API Idle Detection richiede esplicito consenso da parte dell'utente, ovvero se l'applicazione tenta di determinare per la prima volta l'assenza di attivit\u00e0, verr\u00e0 mostrata all'utente una finestra che offre la possibilit\u00e0 di concedere i permessi o bloccare l'operazione. Per disattivare completamente l'API Idle Detection, \u00e8 disponibile un'opzione specifica nella sezione delle impostazioni \"Privacy e sicurezza\" (\"chrome:\/\/settings\/content\/idleDetection\"). <\/p>\n
Tra le aree di applicazione ci sono le applicazioni per la chat, i social media e le comunicazioni, che possono modificare lo stato dell'utente in base alla sua presenza davanti al computer o ritardare la visualizzazione delle notifiche per nuovi messaggi fino all'arrivo dell'utente. L'API pu\u00f2 essere anche utilizzata in applicazioni chiosco per tornare alla schermata principale dopo un certo periodo di inattivit\u00e0 o per disattivare operazioni interattive che richiedono molte risorse, come la ridisegnazione di complesse diagrammi in aggiornamento continuo, quando l'utente non \u00e8 davanti al computer. <\/p>\n
La posizione dei contrari all'inclusione dell'API Idle Detection \u00e8 che le informazioni su se un utente sia davanti al computer o meno possano essere considerate riservate. Oltre agli utilizzi utili, questo API pu\u00f2 essere sfruttato anche per scopi non positivi, come tentativi di sfruttare vulnerabilit\u00e0 durante l'assenza dell'utente o per mascherare attivit\u00e0 dannose evidenti, come il mining. Con questo API \u00e8 possibile raccogliere anche dati sui modelli di comportamento dell'utente e sul suo ritmo lavorativo quotidiano. Per esempio, si pu\u00f2 scoprire quando l'utente di solito va in pausa pranzo o lascia il posto di lavoro. In un contesto in cui \u00e8 richiesta l'autorizzazione per l'assegnazione dei permessi, queste preoccupazioni sono considerate da Google non significative. <\/p>\n
Inoltre, si pu\u00f2 notare la nota degli sviluppatori di Chrome riguardo alla promozione 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 la liberazione della memoria associata (use-after-free). Sono identificate tre principali strategie per affrontare tali errori: il potenziamento dei controlli durante la fase di compilazione, il blocco degli errori durante l'esecuzione e l'uso di un linguaggio che garantisca la sicurezza nella gestione della memoria. <\/p>\n
Si segnala l'avvio di esperimenti per l'aggiunta alla base di codice di Chromium della possibilit\u00e0 di sviluppare componenti in linguaggio Rust. Il codice Rust non \u00e8 attualmente incluso nelle versioni distribuite agli utenti e si concentra principalmente sulla prova della possibilit\u00e0 di sviluppare parti del browser in Rust e sulla loro integrazione con le altre parti scritte in C++. Parallelamente, per il codice in C++, continua lo sviluppo di un progetto per l'uso del tipo MiraclePtr al posto dei puntatori raw, affinch\u00e9 si blocchi la possibilit\u00e0 di sfruttare vulnerabilit\u00e0 causate dall'accesso a blocchi di memoria gi\u00e0 liberati, e vengono proposti nuovi metodi per l'individuazione di errori in fase di compilazione. <\/p>\n
Inoltre, Google inizia un esperimento per testare possibili interruzioni del funzionamento dei siti web dopo che il browser ha raggiunto una versione composta da tre cifre invece di due. In particolare, nelle versioni di prova di Chrome 96 \u00e8 stata introdotta l'impostazione \"chrome:\/\/flags#force-major-version-to-100\", che, se attivata, fornisce la versione 100 nell'intestazione User-Agent (Chrome\/100.0.4650.4). In agosto, un esperimento simile \u00e8 stato condotto in Firefox, che ha rivelato problemi di gestione delle versioni a tre cifre su alcuni siti. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"