Link alla notizia: https://www.hwupgrade.it/news/web/chrome-https-sara-presto-il-protocollo-di-navigazione-predefinito-come-attivare-la-feature-gia-adesso_96493.html

Google ha annunciato che imposterà l'HTTPS come protocollo predefinito già dalla prossima versione di Chrome. Quali saranno i vantaggi, e come avere sin da subito l'opzione

Click sul link per visualizzare la notizia.

Google sta diventando come Microsoft
A ogni aggiornamento toglie qualche funzionalità e ti dice che è un miglioramento

E la sta imitando nel peggiore dei modi: sarebbe ora che inserire funzionalità corregga quelle presenti ovvero quella m.rda di system webview che non si aggiorna alla faccia di tutte le guide risolutive su internet (che non funzionano) e che probabilmente la versione non è compatibile con le applicazioni installate al 100% visto che crasha ancora, outlook app non aggiorna in contenuto e non si aggancia ad exchange...
:banned:

Ma deo gratias che c'è chi (forte della popolarità del suo browser, e non certo in modo disinteressato) cerca di dare una raddrizzata alle tante assurdità, tipo che nel 2021 esistano ancora servizi esposti in http...

Ma non solo, semmai non ve ne foste accorti i gruppi di sviluppo di Chrome e Firefox sono gli unici rimasti a vigilare sulle certification authorities che rilasciano certificati https, se non ci fosse il loro apporto ci ritroveremmo con CA che fanno le peggio porcate e nessuno verrebbe a saperlo se non a danno fatto...

Giusto con la release 90 sarà revocata la CA Camerfirma (società controllata da Infocert) che dal 2018 ha fatto una porcata dietro l'altra senza che nessuno intervenisse.
Quando verrà rilasciata quella release succederà un pandemonio (perchè saranno revocate CA - tra cui quella di Infocert - che hanno rilasciato certificati per un'infinità di servizi pubblici) ma almeno ci libereremo di un manipolo di cialtroni.

Ma deo gratias che c'è chi (forte della popolarità del suo browser, e non certo in modo disinteressato) cerca di dare una raddrizzata alle tante assurdità, tipo che nel 2021 esistano ancora servizi esposti in http...
Perché sarebbe un'assurdità? Per me vale l'esatto contrario: è un'assurdità pretendere di imporre HTTPS ovunque, anche quando non ce ne sia bisogno.

Esempio: se mi voglio vedere un video in streaming, che senso avrebbe passare da HTTPS? HTTP va benissimo per questi scopi: la crittografia di tutti quei dati è del tutto inutile, e anzi appesantisce la comunicazione perché richiede risorse extra sia lato server sia lato client per criptare e decriptare quei dati.

Perché sarebbe un'assurdità? Per me vale l'esatto contrario: è un'assurdità pretendere di imporre HTTPS ovunque, anche quando non ce ne sia bisogno.

Esempio: se mi voglio vedere un video in streaming, che senso avrebbe passare da HTTPS? HTTP va benissimo per questi scopi: la crittografia di tutti quei dati è del tutto inutile, e anzi appesantisce la comunicazione perché richiede risorse extra sia lato server sia lato client per criptare e decriptare quei dati.Dai sappiamo entrambi che questo sovraccarico computazionale alla fine dei conti è trascurabile per l'utente e di fatto anche per il provider dei contenuti.
Come sempre è un compromesso tra costi e benefici e i benefici di una connessione cifrata sono infinitamente superiori ai costi, non solo per la cifratura in se ma anche per la protezione intrinseca sulla compromissione del dato nella tratta tra client e server.

Oltre a questo sappiamo benissimo che se qualcuno non fa qualcosa per sanare questa situazione assurda (2 protocolli da gestire per ogni servizi esposto a web) continueranno a esistere servizi critici esposti in chiaro, dove non sarà il video in streaming (che cmq oggi porta con se tutta una serie di dati utili ai fini di identificare l'utente a scopo commerciale, quindi a ben vedere è diventato un oggetto sensibile meritevole di cifratura imho) ma le credenziali di un utente con accessi critici o dati sensibili.

Per me è una scelta obbligata, abbiamo già intrapreso questa strada, tenere il piede in due scarpe ora come ora è già di per se un costo infinitamente superiore a qualsiasi sovraccarico computazionale, già solo gestire due protocolli diversi per ottenere lo stesso risultato è assurdo.

Sarà che tendo a ragionare in termini retrotecnologici, ma non si considera mai il fattore obsolescenza involontaria che automaticamente pero' si viene a creare. Ci sono dispositivi che potrebbero ancora oggi renderizzare sebbene in parte, sebbene non completamente, sebbene non perfettamente, pagine HTTP normali con browser vecchi e invece grazie alle logiche dei certificati a scadenza non possono piu'. Un esempio per dire e' provare ad usare un browser fatto per Windows 9x/2000/XP che a prescindere da video o pubblicità varie, almeno il contenuto principale (testo) di una pagina potrebbero comporlo piu' o meno in modo leggibile.
Uno potrebbe anche solo necessitare di leggere le news in formato testuale con un dispositivo di due decadi fa e l'hardware ce la farebbe se non fosse per queste logiche.
Senza poi scomodare i discorsi su cose come l'assenza di istruzione come SSE2 che praticamente archivia una marea di hardware che potrebbero ancora farcela a lavorare nell' epoca del green e del non spreco. Certo hardware ormai obsoleto ma percheè dovrebbe esserlo "a priori"? Tempo fa avevo provato che un Athlon XP se non fosse per l' SSE2 mancante grazie a SSD e GPU "moderne" potrebbe ancora essere usato come macchina home/office.

Esattamente. L'imposizione di HTTPS a tutto e tutti non tiene conto delle diverse esigenze, e dell'impatto che si ha in tutti gli scenari.

Ovviamente se hai hardware potente non ci farai nemmeno caso, ma non vale per tutti, per l'appunto.

Ecco perché continuo a pensare che sarebbe meglio separare gli asset fra HTTP e HTTPS.

Esattamente. L'imposizione di HTTPS a tutto e tutti non tiene conto delle diverse esigenze, e dell'impatto che si ha in tutti gli scenari.

Ovviamente se hai hardware potente non ci farai nemmeno caso, ma non vale per tutti, per l'appunto.

Ecco perché continuo a pensare che sarebbe meglio separare gli asset fra HTTP e HTTPS.Beh sappiamo tutti che non è possibile garantire una retrocompatibilità infinita, non si più continuare a usare cypher suites obsolete o far passare il traffico in chiaro perchè qualcuno (che rappresenta una % insignificante del mercato) si ostina a usare IE6 o un Pentium III.
Seguendo questa logica non andrebbero mantenuti in chiaro solo i servizi dove fai una innocua get (che poi tanto innocua non è perchè se uno nella tratta fa injection di qualche script il browser non potrà mai saperlo) ma anche gli altri dove in post mandi magari informazioni critiche.

Personalmente ritengo che il sovraccarico per il client sia trascurabile, quello che imho però spesso non si considera è anche quanto lavoro e quanto spreco di risorse (hh uomo e moneta sonante) si celi dietro la gestione di due protocolli per pubblicare lo stesso servizio.
Mi tornano in mente le tante quotazioni assurde fatte da società senza scrupoli che solo per il fatto che il tal servizio vada pubblicato in http (con riscrittura in https) e https espongono il doppio delle giornate.
Doppio protocollo = doppie policy sui fw (e quindi doppia attività fatturata), doppiio vip sul balancer di turno (e quindi doppia attività fatturata), doppio virtualhost sul backend del balancer, ma soprattutto problem solving più lungo e laborioso.

Per carità, sono il primo a dire che si tratta di cretinate e che tutto questo ricarico è totalmente ingiustificato (quantomeno dal pdv economico), però questo è quello che vedo passare, e ho perso il conto delle volte che ho visto una verifica andare lunghissima perchè qualcuno ha aveva sbagliato vip andando su quello in http anzichè https, o servizi di backend incazzati esposto in http sul webserver e sul balancer di frontend in https etc etc...
Insomma imho la vita di molti sistemisti sarebbe molto più semplice (e quindi la solidità dei servizi ne guadagnerebbe) se ci liberassimo di un protocollo che di fatto è ridondante.

Sì, immaginavo che dietro ci fossero problemi di gestione di non poco conto.

Probabilmente lato browser / navigazione non avrebbe più senso avere due protocolli da gestire, visto che anche il più scarso degli smartphone ormai ha enorme potenza di calcolo e sicuramente accelerazione hardware della crittografia.

Mi chiedevo se in ambito embedded/IoT non fosse ancora un problema invece, viste le scarse capacità hardware.

Sarà che tendo a ragionare in termini retrotecnologici, ma non si considera mai il fattore obsolescenza involontaria che automaticamente pero' si viene a creare. Ci sono dispositivi che potrebbero ancora oggi renderizzare sebbene in parte, sebbene non completamente, sebbene non perfettamente, pagine HTTP normali con browser vecchi e invece grazie alle logiche dei certificati a scadenza non possono piu'. Un esempio per dire e' provare ad usare un browser fatto per Windows 9x/2000/XP che a prescindere da video o pubblicità varie, almeno il contenuto principale (testo) di una pagina potrebbero comporlo piu' o meno in modo leggibile.
Uno potrebbe anche solo necessitare di leggere le news in formato testuale con un dispositivo di due decadi fa e l'hardware ce la farebbe se non fosse per queste logiche.
Senza poi scomodare i discorsi su cose come l'assenza di istruzione come SSE2 che praticamente archivia una marea di hardware che potrebbero ancora farcela a lavorare nell' epoca del green e del non spreco. Certo hardware ormai obsoleto ma percheè dovrebbe esserlo "a priori"? Tempo fa avevo provato che un Athlon XP se non fosse per l' SSE2 mancante grazie a SSD e GPU "moderne" potrebbe ancora essere usato come macchina home/office.

Stiamo parlando della nicchia della nicchia della nicchia, suvvia. Sono un gran sostenitore della retrocompatibilità, ma ci deve essere un limite. Fare tutto retrovomatibile con tutto, implicherebbe uno sforzo enorme dal punto di vista progettuale e una complessità allucinante dei software/sistemi. E' necessario un limite, e a tal proposito, direi che Windows 9x/2000/XP, Athlon XP e loro contemporanei, possono tranquillamente andare in pensione perchè chiaramente obsoleti (senza aggettivi. Semplicemente obsoleti).

Stiamo parlando della nicchia della nicchia della nicchia, suvvia. Sono un gran sostenitore della retrocompatibilità, ma ci deve essere un limite. ...

Comprendo ma imho non e' tanto il problema di "dove" porre quella "linea" di demarcazione. Il mercato non deve certo preservare il 0,0001% dell' utenza che magari ipoteticamente usa Pentium III/Win 98SE e probabilmente molto di quell' hardware e' gia' al tramonto del loro ciclo vitale dove condensatori non di qualità ne rendono per la maggior parte materiale da isola ecologica comunque (riparabilità a parte).
Rifletto su due piani: il piano di dove sia la reale necessità nella moderna logica dell' essere sempre aggiornati. E' per la sicurezza? Beh si e' dimostrato che il problema sicurezza andrebbe ben oltre se andiamo a scomodare tutti i "potenziali" (magari solo teorici) bug che ancora prima di scomodare il lato software "consiglierebbero teoricamente" di cambiare praticamente ogni biennio tutto. Se uno vede la lista di bug presenti su un'architettura Socket 775 (solo per esempio) si potrebbe allora per quei motivi di "sicurezza" presupporre che ormai anche quelli anni luce dal P-III sarebbero da isola ecologica quando invece eccellenti architetture ancora oggi sul lato prestazionale (basti pensare agli ultimi su 45mn). Il trend che si vede in ambito mobile non e' certo un esempio di longevità dove hardware nuovo e' praticamente concettualmente gia' vecchio alla nascita con kernel e moduli driver che non verranno aggiornati per piu' di un paio di volte e un sovrastrato sw di vari layers da aggiornare mensilmente ammesso che l'aggiornamento verrà. Dopodichè .. si cambia tutto .. nell'epoca appunto del green andando a riempire containers di tecnologia ancora funzionante anche solo per la batteria non sostituibile.

Altro piano e' appunto il software consumer stesso e le stesse pagine web che ormai sono software a loro volta invece di come pareva avrebbero dovuto essere, simili ai "quotidiani di carta". Negli anni 90/2000 piu' o meno era cosi', tanto testo, poche immagini, poca pubblicità, tecnicamente un Pentium II poteva tranquillamente svolgere quella funzione e la svolgeva quando il modem 56K V90 era la tecnologia comune, la latenza bassissima e il carico del lavoro sul browser a livello percezione era quasi piu' immediato rispetto a oggigiorno con tutte le pagine web che sembrano dover compilare un mare di codice ad alto livello con decine e decine di connessioni attive, continue, per fare quello che quel Pentium II faceva vent'anni fa. Per esempio uno potrebbe leggere il testo di un articolo qualsiasi e avere la cpu occupata al 50% sul processo attivo del browser. Trovo umilmente incredibile che ancora venga utilizzato nel web moderno il simbolo "X" simil-Windows 3.x/GUI come se quella "X" fosse ancora un "bottone vero" di chiusura della finestra quando immagino quanto codice gira per quella "X".

Imho quindi non e' solo un problema di protocollo HTTPS a scadenza quanto realizzare (lato utente) come sia il software stesso che le tecnologie web siano cambiate proprio "concettualmente" beneficiando di potenze enormi degli hardware moderni per compensare nuovi strati su strati di complessità anche laddove un browser testuale persino basterebbe. Se avere due pagine aggiornate HTTP e HTTPS costa troppo a livello gestionale, magari tornare ad avere una versione semplificata minimale (stile le versioni WAP mobile antiche) con solo testo ad esempio per le parti essenziali delle homepage sarebbe gia' qualcosa.

Comprendo ma imho non e' tanto il problema di "dove" porre quella "linea" di demarcazione. Il mercato non deve certo preservare il 0,0001% dell' utenza che magari ipoteticamente usa Pentium III/Win 98SE e probabilmente molto di quell' hardware e' gia' al tramonto del loro ciclo vitale dove condensatori non di qualità ne rendono per la maggior parte materiale da isola ecologica comunque (riparabilità a parte).
Rifletto su due piani: il piano di dove sia la reale necessità nella moderna logica dell' essere sempre aggiornati.
SNIPAspetti molto interessanti che varrebbe la pena discutere in un contesto molto più ampio, solo su questi ci si potrebbe imbastire una conferenza :)

Il tema aggiornamenti/sicurezza molto spesso imho è mal posto, ma del resto come è stato mal posto per decenni il tema di antivirus, suite di sicurezza etc etc...
Sappiamo tutti che la sicurezza assoluta non esiste, è un obbiettivo a cui tendere cercando di trovare il miglior rapporto costi/benefici e intervenendo non solo laddove si può ma laddove è più facile che possa arrivare una minaccia.
Mi tornano in mente tante discussioni (anche recenti) da clienti che si preoccupavano per la vulnerabilità di sudo recentemente fixata (ma che esiste ed è conosciuta da anni e anni) su sistemi in produzione su cui girava RedHat Enteprise AS 3.0, Tomcat arcaico su JDK 1.4 e php 4.4; in quel caso è più probabile che un malintenzionato provi a sfruttare uno dei millemila bug di quella versione di php o java oppure quello di sudo?
Eh bella domanda... cms custom completamente sviluppato da zero a mano, architettura a dir poco complessa, paranoie applicative tendenti all'inverosimile.

Questo per dire quanto siano infinite le variabili lato sw, quanto più conosciute o facilmente sfruttabili, al confronto i bug nell'hw sono pochi e generalmente più complessi da sfruttare, per cui imho ci sta che la paranoia dell'update sia più concentrata sul sw.

Teniamo presente poi che gli aggiornamenti (soprattutto nel caso dei browser, la cui centralità è diventata un pilastro dell'IT, ci ritorniamo a breve) spesso vengono usati non solo per fixare bug, ma anche per raddrizzare cose che col sw non hanno nulla a che fare e che invece derivano da comportamenti assurdi di società/gruppi, insomma di persone.
Prendi il caso di Chrome 90, il prossimo update previsto per il 14/4/2021 probabilmente scatenerà un caos totale per la revoca dei certificati ad una CA controllata da Infocert che negli anni ha fatto porcate assurde, e vedrai che si genereranno molti più problemi di quanti possa causarne un bug sw.
Perchè? Perchè chi gestisce quella CA è un somaro e andrebbe cacciato, insomma il fattore umano incide direttamente anche su questo.

Sul web e il ruolo dei browser capisco perfettamente la tua obiezione e in parte la condivido, però dobbiamo accettare che http è diventato un protocollo universale, non più il veicolo di ipertesti ma qualcosa di ben più grande, ed è interessante notare questa evoluzione perchè se guardiamo bene non è una cosa che è nata per capriccio di Google o di Mozilla, ma è qualcosa che si è evoluto nel tempo a partire dall'avvento dei web services.
Nel momento in cui si è cominciato a usare http come veicolo di trasmissione dati in generale (soppiantando millemila standard più o meno proprietari) è diventato ancora più critico incapsulare quei dati all'interno di un protocollo cifrato, poi si è cominciato a ragionare sull'uso del browser come client universale, a lavorare su modalità di elaborazione asincrone, a progettare e usare framework sempre più complessi e flassibili per l'elaborazione lato client etc etc etc... fino ad arrivare ad oggi, dove il browser è il centro del mondo applicativo, dove sviluppare qualcosa che non abbia un'interfaccia web based è semplicemente eresia.

Per carità, come tutte le soluzioni ci sono pro e contro, come sempre è un compromesso su cui io stesso mi trovo spesso in difficoltà; riconosco che ci sono dei principi sensati dietro questa tendenza, consolidamento vs frammentazione.
Pensa a quanti client proprietari avevamo prima, uno fatto in C, l'altro in Java, uno in Flash, l'altro in .NET, ciascuno in 2 versioni, una x86 e una x64 (e deo gratias che il mondo arm non era ancora esploso a livello consumer, perchè se fosse oggi dovresti aggiungere arm a 32bit e arm a 64 bit); i nostri pc erano pieni di plugin per ciascuna di queste cose, il framework .NET, la JRE, Flash, librerie varie da aggiornare etc etc, tutte cose da manutenere, da aggiornare, con i loro bug, i loro problemi.

Guarda ora, quando installi il sistema operativo non ti devi più preoccupare di tutte queste cose, giusto giusto la JRE se proprio vuoi stare a fare il puntiglioso e ovviamente il browser.
Pensa poi a cosa voleva dire dal punto di vista dello sviluppo mantenere tutto questo castello di carte; ok i framework javascript nascono e muoiono con una facilità assurda, ma la base, il "campo" su cui si gioca la partita è sempre quello, cambiano un po' le regole qua e la a seconda delle versioni, ma la sostanza è quella (poi magari io semplifico un po' troppo, del resto non faccio lo sviluppatore di lavoro :) )

Insomma imho c'è del razionale dietro a quello a cui assistiamo oggi, non è tutto comandato da Google o da Mozilla o da qualche misteriosa entità che vuole fregare il consumatore; anzi a ben vedere spesso i big sono spesso gli unici "guardiani" che cercano di indirizzare in modo un po' più razionale e ordinato il caos che si crea online, pensa ad es a quella CA che citavo prima, se non fosse stato per le ripetute "tirate d'orecchia" fatte dal team di sviluppo di Chrome e Firefox oggi non sapremmo nemmeno di quegli sciamannati che gestiscono quella CA e delle porcate che facevano.
Anzi da questo punto di vista ci sarebbe molto di cui discutere, a partire dall'assenza di qualche organismo sovranazionale che vigili sugli aspetti più critici (ad es la gestione delle certification authorities).

Aspetti molto interessanti che varrebbe la pena discutere in un contesto molto più ampio, solo su questi ci si potrebbe imbastire una conferenza :)

Il tema aggiornamenti/sicurezza molto spesso imho è mal posto, ma del resto come è stato mal posto per decenni il tema di antivirus, suite di sicurezza etc etc...
Sappiamo tutti che la sicurezza assoluta non esiste, è un obbiettivo a cui tendere cercando di trovare il miglior rapporto costi/benefici e intervenendo non solo laddove si può ma laddove è più facile che possa arrivare una minaccia.
Mi tornano in mente tante discussioni (anche recenti) da clienti che si preoccupavano per la vulnerabilità di sudo recentemente fixata (ma che esiste ed è conosciuta da anni e anni) su sistemi in produzione su cui girava RedHat Enteprise AS 3.0, Tomcat arcaico su JDK 1.4 e php 4.4; in quel caso è più probabile che un malintenzionato provi a sfruttare uno dei millemila bug ...

Considerazioni altrettanto interessanti. :) Anche io generalizzo non lavorando oggigiorno come sviluppatore ma comprendo e anzi e' proprio un argomento che spesso mi trovo discutere di come sia profondamente e concettualmente cambiata non solo la tecnologia ma tutto quanto l' essente attorno ad essa sw e hw rispetto ad un passato che non ho mai pensato fosse "solo" roseo come spesso il comune sentire vorrebbe declinare, ma semmai fosse una realtà "altra" con logiche tecnologiche limitanti, altre negative ma anche altre positive. Il ruolo dello "user" come utente sembra oggigiorno definibile piu' come utile e proprio con la ricerca della comodità imho la tecnologia ha preso una strada che, almeno lato consumer talvolta alcune innovazioni sembrano quasi precedute dalla necessità di creare il bisogno di quella innovazione che fino a poco prima nessuno necessitava.
Si puo' pensare che sia sempre stato cosi', forse e' vero, ma piu' si va avanti e piu' noto come si faccia sempre piu' sfumata la linea tra a chi serve chi. Se la tecnologia serve l' utente o l'utente serve la tecnologia.
E c'e' imho anche la tendenza a credere che usare la tecnologia sia sinonimo di essere esperti di essa quando invece (me come tanti) si e' appunto utenti. IMHO concettualmente si potrebbe riflettere che un programmatore senior "da solo" resta pur solo esso stesso un utente se non e' inserito in una catena di lavoro ormai talmente complesso che forse l'esperto non puo' esistere per assurdo nell' epoca della semplificazione. Semplificazione e comodità al pari della "pasta in bianco surgelata" e non saperla piu' preparare.