Google Developers Italia: Chrome

Creare un Web più privato: un percorso per rendere obsoleti i cookie di terze parti

29 gennaio 2020

Ad agosto abbiamo annunciato una nuova iniziativa (nota come Privacy Sandbox) volta a sviluppare un set di standard aperti finalizzati a incrementare in modo significativo la privacy sul Web. Il nostro obiettivo per questa iniziativa open source è rendere il Web più privato e sicuro per gli utenti, senza tuttavia smettere di supportare i publisher. Oggi, desideriamo aggiornarti sui nostri piani e chiedere il tuo aiuto per aumentare la privacy dell'esplorazione del Web.
Dopo il dialogo iniziale con la community del Web, siamo fiduciosi che, grazie a iterazione e feedback costanti, i meccanismi di tutela della privacy e attuazione di standard aperti come Privacy Sandbox saranno in grado di sostenere un Web supportato dalle inserzioni che sia sicuro, in modo tale da rendere i cookie di terze parti obsoleti. Una volta che questi approcci saranno stati adattati alle esigenze di utenti, publisher e inserzionisti e che avremo sviluppato gli strumenti per mitigare eventuali espedienti, elimineremo gradualmente il supporto per i cookie di terze parti in Chrome. E siamo intenzionati a raggiungere questo obiettivo entro due anni. Tuttavia non possiamo farcela da soli, ecco perché abbiamo bisogno che l'intero ecosistema Web prenda parte alla realizzazione di queste proposte. Abbiamo in programma di iniziare le prime versioni di valutazione entro la fine di quest'anno, a partire dalla misurazione delle conversioni per poi proseguire con la personalizzazione.

Gli utenti chiedono maggiore privacy, trasparenza, possibilità di scelta e controllo sul modo in cui i loro dati vengono utilizzati, ed è chiaro che l'ecosistema Web debba evolversi per poter soddisfare queste richieste crescenti. Alcuni browser hanno reagito a queste preoccupazioni bloccando i cookie di terze parti, ma noi crediamo che un simile approccio implichi conseguenze inattese che potrebbero avere un impatto negativo sia sugli utenti che sull'ecosistema Web. Riteniamo infatti che approcci drastici ai cookie, minando il modello di business di molti siti web supportati dalle inserzioni, finiscano per incoraggiare il ricorso a tecniche invasive come l'uso di impronte per sostituire i cookie, le quali rischiano di compromettere la privacy e il controllo degli utenti. La nostra convinzione è che tutti insieme, come community, possiamo e dobbiamo fare meglio.

Fortunatamente, abbiamo ricevuto feedback positivi in forum come W3C in merito al fatto che i meccanismi alla base di Privacy Sandbox rappresentino casi d'uso fondamentali e vadano nella giusta direzione. Questi feedback, e le relative proposte avanzate da altri partecipanti agli standard, rafforzano la nostra convinzione che le soluzioni nate in questo spazio possano funzionare. Inoltre, la nostra esperienza con la community degli standard nella creazione di alternative e nell'eliminazione graduale del supporto a Flash e NPAPI è la dimostrazione che insieme possiamo affrontare e superare sfide difficili.

Intanto, continueremo a lavorare per rendere le tecnologie web attuali più sicure e private. Come abbiamo già annunciato, a partire da febbraio Chrome limiterà il monitoraggio intersito non sicuro trattando i cookie che non includono un'etichetta SameSite solo come prima parte; inoltre, richiederà che i cookie etichettati per l'uso di terze parti siano accessibili tramite HTTPS. Questo renderà i cookie di terze parti più sicuri e fornirà gli utenti controlli più precisi sui cookie del browser. Parallelamente, stiamo sviluppando tecniche volte a rilevare e mitigare sistemi di tracciamento nascosto e altri espedienti grazie a nuove misure anti-rilevamento dell'impronta per scoraggiare questo genere di tecniche ingannevoli e invasive, che puntiamo a lanciare entro quest'anno.

Stiamo lavorando attivamente nell'ecosistema perché browser, publisher, sviluppatori e inserzionisti abbiano l'opportunità di sperimentare questi nuovi meccanismi, testarne l'efficacia in diverse situazioni e creare implementazioni di supporto come la selezione e la misurazione delle inserzioni, la prevenzione denial of service (DoS), misure anti-spam/frode e un'autenticazione federata.

Ci stiamo impegnando per dare vita a un Web più sicuro e sostenibile, insieme, e per riuscirci abbiamo bisogno del tuo impegno costante. Ti invitiamo a fornirci un feedback sulle proposte presentate dalla community di standard per il Web attraverso GitHub, assicurandoti che soddisfino le tue esigenze. In caso contrario, presenta un issue tramite GitHub o contatta via email il gruppo W3C. Se la tua attività si svolge sul Web, assicurati che i tuoi fornitori di tecnologia prendano parte a questo processo e condividi il tuo feedback con i gruppi commerciali che rappresentano i tuoi interessi.

Noi continueremo a tenervi aggiornati sui risultati del nostro lavoro volto ad accrescere la privacy dell'esplorazione del Web.

Pubblicato da Justin Schuh - Director, Chrome Engineering

Flutter e Chrome OS: insieme è meglio

29 maggio 2019

Pubblicato dai team Flutter e Chrome OS Flutter è un ottimo modo per creare app Chrome OSFlutterEsempio di Chrome OS Best Practices

Esempio di Chrome OS Best Practices in azione

queste linee guida

Le regole di linting di Flutter Chrome OS in azione

documenti di linting per Flutter Chrome OS Chrome OS è un'eccellente piattaforma per sviluppatori per la creazione di app FlutterLinux su Chrome OS

Gli strumenti di sviluppo di Flutter in esecuzione su Chrome OS

I clienti adorano Flutter su Chrome OSAppTree "La creazione di una versione Chrome OS della nostra app ha richiesto pochissimo sforzo. In 10 minuti abbiamo ottimizzato alcuni valori e ora i nostri utenti hanno accesso all’app su un'intera nuova classe di dispositivi. Si tratta di un'importante novità per i clienti aziendali che desiderano accedere all'app dai dispositivi desktop". — Matthew Smith, CTO, AppTree Software Prova Flutter su Chrome OS oggi stesso!installando l'ultima versione di Flutterseguire queste istruzioniesempio Developer Questprovare le regole di linting di Flutter Chrome OS

10 anni di Chrome DevTools

24 settembre 2018

code { background-color: transparent } * { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; } Chrome compie 10 anni! Grazie per aver reso la community di sviluppo Web così aperta, collaborativa e solidale. DevTools trae ispirazione da innumerevoli altri progetti. Ecco una panoramica su come è nato e come è cambiato nel corso degli anni.

In principio, c'era FirebugImmagina per un momento che i browser non facciano parte degli strumenti di sviluppo. Come eseguiresti il debug di JavaScript? Avresti fondamentalmente 3 opzioni:

Disseminare chiamate window.alert() su tutto il codice.

Commentare sezioni di codice.

Fissare a lungo il codice finché gli dei JavaScript non ti suggeriscano l'anelata soluzione.

Come gestiresti i problemi di layout? E gli errori di rete? Anche in questo caso non potresti far altro che condurre laboriosi esperimenti sul codice. Questa era la realtà dello sviluppo Web fino al 2006. Poi è arrivato un piccolo strumento chiamato Firebug che ha cambiato tutto.

Uno screenshot del pannello Net di Firebug, ottenuto da Saying Goodbye to Firebug (sorgente e licenza)

Firebug era un'estensione di Firefox che consentiva di eseguire il debug, modificare e monitorare le pagine in tempo reale. Come sviluppatore Web, sei passato all'improvviso dall'assenza di visibilità nelle tue pagine ad avere quelle che sono essenzialmente le caratteristiche principali dei moderni strumenti di sviluppo. Riuscire a capire esattamente perché Firefox si comportasse così ha dato vita a una grande ondata di creatività sul Web. Senza Firebug, l'era del Web 2.0 non sarebbe stata possibile.

WebKit Web Inspector
Durante lo stesso periodo del lancio di Firebug, alcuni ingegneri di Google hanno iniziato a lavorare su un progetto che avrebbe poi portato a Chrome. Sin dall'inizio Chrome era un mashup di diverse librerie di codice. Nel caso del rendering, gli ingegneri di Chrome hanno optato per WebKit, ossia il progetto open source tuttora alla base di Safari. Un ulteriore vantaggio a favore di WebKit era l'avere in dotazione un pratico strumento chiamato Web Inspector.

Uno screenshot di Web Inspector, ottenuto da Web Inspector Redesign (sorgente e licenza)Proprio come nel caso del pannello Net di Firebug, probabilmente il Web Inspector originale ti risulterà familiare. Gran parte delle sue funzionalità è ancora disponibile nel pannello Elementi in Chrome DevTools. Web Inspector è stato lanciato pochi giorni dopo Firebug e Safari è stato il primo browser a raggruppare gli strumenti per sviluppatori direttamente nel browser.

L'era di Inspect Element
Chrome ha introdotto molte idee innovative nell'ecosistema dei browser, come la omnibox che combinava la ricerca e la barra degli indirizzi, e l'architettura multiprocesso che impediva a una scheda in sospeso di arrestare l'intero browser. Ma la nostra innovazione preferita era poter fornire agli sviluppatori strumenti di sviluppo in ogni build per ogni utente, grazie a un semplice clic del mouse.

Inspect Element in 2010
Prima di Chrome, gli strumenti per sviluppatori erano un'esperienza che richiedeva attivazione. Bisognava installare un'estensione, ad esempio Firebug, o abilitare alcuni flag, come avviene ancora oggi in Safari. Chrome è stato il primo browser a rendere accessibili gli strumenti per sviluppatori da tutte le istanze del browser. Vorremmo poter affermare di aver avuto la grande visione di creare un browser pensato per gli sviluppatori sin dall'inizio, ma la verità è che nelle sue prime fasi Chrome ha avuto molti problemi di compatibilità (il che ha senso poiché nessuno ne aveva pianificato la creazione) e dovevamo offrire agli sviluppatori Web una soluzione semplice che risolvesse questi problemi. Gli sviluppatori Web hanno confermato che era una funzionalità utile e quindi l'abbiamo tenuta.

L'era mobile

Per i primi anni del progetto DevTools, abbiamo essenzialmente aggiunto capitoli alle storie che Firebug e Web Inspector avevano creato. La svolta successiva nel nostro approccio a DevTools è avvenuta quando ci siamo resi conto che gli smartphone erano la nuova realtà.

La nostra prima missione in questo nuovo mondo era consentire agli sviluppatori di eseguire il debug di dispositivi mobili reali dai loro computer di sviluppo, ossia effettuare il debug remoto. Difatti DevTools era ben posizionato per gestire il debug remoto grazie a un'altra funzionalità dell'architettura multiprocesso di Chrome. Nelle prime fasi del progetto DevTools ci siamo resi conto che l'unica maniera in cui un debugger poteva accedere in modo affidabile al browser multiprocesso era attraverso un protocollo client-server, con il browser che fungeva da server e il debugger da client. Quando è arrivato Chrome mobile, era già dotato di protocollo, quindi abbiamo solo dovuto far comunicare i DevTools in esecuzione sul computer di sviluppo con Chrome in esecuzione sul dispositivo mobile tramite il protocollo. Questo protocollo costituisce ancora oggi la spina dorsale di DevTools, ed è ora conosciuto come il Chrome DevTools Protocol.

Debug remoto

Il debug remoto è stato un passo importante nella direzione giusta e fino a oggi è ancora lo strumento principale per garantire che i siti si comportino correttamente sui dispositivi mobili veri e propri. Nel corso del tempo, tuttavia, ci siamo resi conto che il debug remoto può rivelarsi laborioso. Durante le prime fasi di creazione di un sito o di una funzione, di solito bisogna ottenere solo un'approssimazione di primo ordine dell'esperienza mobile. Ciò ci ha spinto a creare un set di funzioni di simulazione mobile, quali ad esempio:

Emulazione precisa dell'area visibile mobile, simulando l'input basato sul tocco e sull'orientamento del dispositivo.

Limiti della connessione di rete, come nel caso di 3G e CPU, per simulare hardware per dispositivi mobili meno potenti.

Spoofing di user-agent, geolocalizzazione, dati dell'accelerometro e altro ancora.

Ci riferiamo collettivamente a queste funzioni chiamandole Modalità dispositivo.

Uno dei primi prototipi di Modalità dispositivo

Modalità dispositivo nel 2018

L'era della performance

Con l'avanzare dell'era mobile, le app di grandi dimensioni, come Gmail, oltrepassavano i limiti del Web. Bug in scala Gmail chiamati per gli strumenti in scala Gmail. Uno dei nostri principali contributi all'ecosistema degli strumenti è stato mostrare una scomposizione play-by-play di esattamente tutto ciò che Chrome doveva fare per visualizzare una pagina.

Il pannello Timeline originale, come annunciato in Do More with Chrome Developer Tools

Il Pannello performance in 2018

Questi strumenti sono stati un passo importante nella giusta direzione, ma per individuare le opportunità di ottimizzazione è stato necessario conoscere ogni singolo dettaglio su come i browser operano e setacciano grandi quantità di dati. Ultimamente abbiamo sfruttato questo principio per fornire informazioni guidate sulla performance. Il nuovo motore Lighthouse alimenta il pannello Audits ed è anche disponibile come modulo Node per l'integrazione con i sistemi CI.

Suggerimenti sulla performance nel pannello Audits

L'era di Node.js

Fino approssimativamente al 2014, abbiamo concepito DevTools soprattutto come uno strumento per la creazione di grandi esperienze su Chrome. Il successo di Node ci ha spinto a riconsiderare il nostro ruolo nell'ecosistema Web.
Nei primi anni di Node, gli sviluppatori coinvolti si sono trovati in una situazione simile a quella degli sviluppatori Web prima di Firebug o degli sviluppatori Gmail prima del pannello Timeline: la scala delle app Node superava la scala degli strumenti Node. Considerando che Node viene eseguito sul motore JavaScript di Chrome, V8, DevTools si è rivelato il candidato ideale per colmare questo divario. Il supporto per il debug di Node con DevTools è arrivato nel 2016 e includeva le consuete funzioni di DevTools, quali breakpoint, esecuzione di istruzioni del codice, blackboxing, mappe di origine per il codice transpiled e così via.

Node Connection Manager

L'ecosistema del protocollo DevTools

Il nome Chrome DevTools Protocol (CDP) suggerirebbe un'API che solo DevTools può utilizzare. In realtà ha un significato più ampio, è l'API che consente l'accesso programmatico a Chrome. Negli ultimi anni alcune librerie e applicazioni di terze parti hanno aderito all'ecosistema del protocollo:

chrome-remote-interface fornisce l'accesso JavaScript di basso livello al protocollo.

Puppeteer lo porta al livello successivo di astrazione e consente l'automazione del browser Headless Chrome, sempre valido, con l'attuale API JavaScript.

Lighthouse automatizza il processo di ricerca dei modi di migliorare le prestazioni e la qualità delle pagine.

Siamo contenti che migliaia di progetti dipendano da questi pacchetti che abilitano un'interazione completa con Chrome. Se lavori nel settore degli strumenti o dell'automazione, ti consigliamo di andare a vedere il protocollo per scoprire nuove opportunità nel tuo dominio. Ad esempio, i team VS Code e WebStorm lo utilizzano per abilitare il debug di JavaScript nei rispettivi IDE.

Novità in arrivo

La nostra missione principale è fornire strumenti che aiutino a creare esperienze straordinarie sul Web. Ci affidiamo enormemente al tuo feedback per decidere quali prodotti o funzionalità creare.

Rimani aggiornato sulle nuove funzionalità con i nostri post What's New

Proponici nuove funzionalità nella mailing list

Segnalaci i bug nel Chromium Bug Tracker

Seguici su Twitter per scoprire nuove funzionalità e i flussi di lavoro di dimensioni ridotte

Pubblica le tue domande su Stack Overflow per ricevere assistenza su come usare DevTools

Prendi in mano la questione e contribuisci a DevTools

Grazie per aver creato una community così vibrante. Continuiamo a creare il Web insieme per altri 10 anni!

Pubblicato dal team Chrome DevTools

Il canale Canary per Chrome su Android

24 ottobre 2016

code { background-color: transparent }canali di releasedisponibile anche per Androidsegnalandolo Pubblicato da Alex Mineer, APK Administrator e Bug Basher

Trasferimento di app Android su Chromebook

25 luglio 2016

personalelavorativodidatticoqui

Le app Android possono essere visualizzate in finestre di 3 diverse dimensioni per consentire un’esperienza ottimale

Gli utenti possono svolgere più attività con più app Android in finestre spostabili insieme a un browser desktop completo, il tutto nell’ambito dell’abituale interfaccia di Chrome OS

Tastiera, mouse e tocco input funzioneranno insieme senza difficoltà

Gli utenti potranno ricevere le notifiche Android sui propri Chromebook

Le app Android potranno sfruttare la connettività WiFi o Bluetooth impostata dall’utente o dall’amministratore

L’app Files consentirà di semplificare la condivisione tra Chrome e le app Android

Le performance di app impegnative come giochi o app di progettazione sono ottime

Dal momento del lancio effettivo e nelle fasi successive continueremo ad aggiungere il supporto per il seguente elenco di dispositivi. Consulta istruzioni particolareggiate su come iniziare a testare le tue app.

Chrome 51 Beta: API Credential Management e riduzione dei consumi per il rendering offscreen

11 maggio 2016

Salvo diversa indicazione, le modifiche descritte di seguito riguardano la versione più recente disponibile tramite il canale Beta di Chrome per Android, Chrome OS, Linux, Mac e Windows.
API Credential Management
Molti siti consentono ai propri utenti di effettuare l’accesso per ricevere contenuti personalizzati. Oggi questo significa ricordare e digitare le credenziali, riducendo di conseguenza la sicurezza dell’account quando gli utenti riutilizzano le password su più siti. I browser odierni dispongono di strumenti di gestione delle credenziali che ricordano e compilano automaticamente le password salvate, ma tali strumenti non sono in grado di tener conto dei flussi di accesso personalizzati o di ricordare le preferenze di identità federativa.
L’ultima versione di Chrome ora supporta le API Credential Management, consentendo ai siti di interagire con lo strumento di gestione credenziali del browser per migliorare l’esperienza di accesso per gli utenti. L’API consente agli utenti di effettuare l’accesso con un tocco e di accedere di nuovo automaticamente al rientro nel sito. Screen Shot 2016-04-28 at 13.56.55.png

Accesso con un tocco usando le API Credential Management
Riduzione dei consumi per il rendering offscreen

I siti Web moderni generalmente integrano contenuti multiorigine come video, widget social e annunci pubblicitari. Incorporando queste risorse i siti possono offrire esperienze convincenti a livello dei contenuti, ma creare anche un sovraccarico tale da riempire la pagina di elementi superflui in modi non controllabili dal sito che inserisce tali risorse. La versione più recente di Chrome non esegue più la pipeline di rendering né i callback requestAnimationFrame() per i frame multiorigine che sono offscreen. In questo modo si elimina lavoro inutile e si riducono i consumi fino al 30% su vari siti mobili molto seguiti senza ripercussioni sull’esperienza utente.

Altre funzionalità in questa versione

L’ API Intersection Observer consente ai siti di rilevare intersezioni di elementi come un evento asincrono, eliminando la necessità di un costoso monitoraggio dei documenti.
La versione più recente di Chrome supporta listener di eventi passivi, che consentono ai siti di eseguire JavaScript in risposta all’input tramite tocco e rotella del mouse senza bloccare lo scorrimento.
I blob vengono ora creati e trasferiti al browser in modo asincrono, consentendo lo spostamento dei file di dati di grandi dimensioni senza ingombrare inutilmente la pagina.
L’attributo del cookie SameSite consente ai siti di limitare i cookie a richieste provenienti dallo stesso dominio.
Il supporto per la crittografia AES_256_GCM su TLS migliora la sicurezza sui server che scelgono la crittografia per dimensioni chiave, laddove veniva usata la crittografia di legacy a 256 bit rispetto a codici più sicuri ma più piccoli.
Array.prototype.values() agevola l’iterazione sugli elementi di un array.
La proprietà name della funzione adesso è in grado di dedurre nomi utili per le proprietà e i metodi con nomi di proprietà calcolati, facilitando le operazioni di debug con etichette e messaggi di errore più chiari.
Gli iteratori che fanno parte di un loop for-of che termina in anticipo adesso possono chiamare un metodo close() fornito dallo sviluppatore, agevolando la risposta al termine di un’iterazione.
Symbol.species rende la creazione di sottoclassi di classi incorporate come Array e RegExp più potente consentendo ai costruttori personalizzati di essere chiamati per gli oggetti derivati.
Le sottoclassi RegExp possono sovrascrivere il metodo exec() per modificare l’algoritmo di corrispondenza, agevolando la scrittura di sottoclassi personalizzate.
I siti adesso possono implementare il proprio metodo Symbol.hasInstance() per personalizzare il comportamento dell’operatore instanceof.
I siti possono ora recuperare un oggetto Client di service worker usando Clients.get(id).
ServiceWorker.postMessage() adesso attiva un ExtendableMessageEvent su ServiceWorkerGlobalScope, consentendo al messaggio di prolungare la durata del service worker e di fornire origini dei messaggi più precise.
L’attributo referrerpolicy HTML permette ai siti di controllare quali informazioni vengono inviate nelle intestazioni dei riferimenti degli elementi <a>, <area>, <img> e <iframe>.
L’attributo UIEvents KeyboardEvent |key| consente ai siti di determinare in modo affidabile il significato del tasto che viene premuto.
I siti adesso possono rilevare la durata dei contesti audio offline in batch tramite l’attributo OfflineAudioContext.length.

Altre modifiche

La possibilità di personalizzare il messaggio mostrato nella finestra di dialogo onbeforeunload è stata eliminata per proteggere gli utenti da siti Web dannosi e allinearsi con il comportamento di altri browser.
Chrome su Android ora utilizza la stessa pipeline multimediale come desktop Chrome, migliorando il supporto WebAudio e consentendo ai siti di interagire con la velocità di riproduzione sui tag <audio> e <video>.
L’ultima versione di Chrome migliora l’interoperabilità delle animazioni Web supportando elenchi di valori e rimuovendo i nomi con trattino nei fotogrammi chiave.
Chrome ora richiede uno stile bordo per colorare le immagini dei bordi, migliorando la conformità alle specifiche e l’interoperabilità.
Adesso è possibile utilizzare le percentuali per le dimensioni dei flex item secondari.
La crittografia basata su DHE è stata resa obsoleta e sarà rimossa in Chrome 52 a favore della crittografia ECDHE per migliorare la sicurezza TLS.

Transizione da SPDY ad HTTP/2

30 marzo 2016

annunciatoHTTP/2serverWebbrowserHTTP/2 RFCNPNALPNeseguendo l’aggiornamento della loro libreria SSL

Le schede personalizzate di Chrome semplificano la transizione fra app e Web

16 ottobre 2015

schede personalizzate

Confronto fra schede personalizzate di Chrome con precaricamento e Chrome e WebView

libreria di assistenzaFeedlyThe GuardianMediumPlayer.fmSkyscannerStack OverflowTumblrTwitterguida per gli sviluppatori Pubblicato da Yusuf Ozuysal, Chief Tab Customizer