Rimozioni e ritiri in Chrome 81

Joe Medley
Mario Bianchi

Ritiro e rimozione del gestore dei pagamenti per l'assistenza "basic-card"

Questa versione di Chrome rimuove il polyfill della scheda di base per l'API Payment Request in Chrome per iOS. Di conseguenza, l'API Payment Request è temporaneamente disattivata in Chrome per iOS. Per informazioni dettagliate, consulta l'articolo Ripensare la richiesta di pagamento per iOS.

Intent di rimozione | Stato della piattaforma Chrome | Bug di Chromium

Rimuovi il campo SupportType da BasicCardRequest

Se specifichi il parametro "supportedTypes":[type] per il metodo di pagamento "basic-card", vengono mostrate solo le carte del tipo richiesto, ovvero "credito", "debit" o "prepaid".

Il parametro del tipo di scheda è stato rimosso dalle specifiche e da Chrome, a causa della difficoltà di determinare in modo preciso il tipo di scheda. Oggi i commercianti devono verificare il tipo di carta con il proprio PSP, perché non possono considerare attendibile il filtro per tipo di carta nel browser:

  • Solo le banche emittenti conoscono con certezza il tipo di carta e i database scaricabili dei tipi di carte hanno una scarsa precisione, pertanto è impossibile conoscere con precisione il tipo di carte memorizzato localmente nel browser.
  • Il metodo di pagamento "di base" in Chrome non mostra più le carte di Google Pay, che potrebbero avere collegamenti con le banche emittenti.

Intent di rimozione | Stato della piattaforma Chrome | Bug di Chromium

Rimuovi l'elemento .

Chrome 81 rimuove l'elemento <discard>. È implementato solo in Chromium, pertanto non è possibile utilizzarlo in modo interoperabile. Nella maggior parte dei casi d'uso, può essere sostituita con una combinazione di animazione della proprietà display e di un callback/gestore di eventi di rimozione (JavaScript).

Intent di rimozione | Stato della piattaforma Chrome | Bug di Chromium

Rimuovere TLS 1.0 e TLS 1.1

TLS (Transport Layer Security) è il protocollo che protegge il protocollo HTTPS. Ha una lunga storia che risale a quasi vent'anni fa, TLS 1.0 e al suo predecessore ancora meno recente, SSL. Sia TLS 1.0 che 1.1 presentano una serie di punti deboli.

  • TLS 1.0 e 1.1 utilizzano MD5 e SHA-1, entrambi hash deboli, nell'hash di trascrizione per il messaggio Finished.
  • TLS 1.0 e 1.1 utilizzano MD5 e SHA-1 nella firma del server. Nota: non si tratta della firma del certificato.
  • TLS 1.0 e 1.1 supportano solo le crittografie RC4 e CBC. RC4 non funziona ed è stato rimosso. La costruzione della modalità CBC di TLS è difettosa ed è vulnerabile agli attacchi.
  • Le crittografie CBC di TLS 1.0 costruiscono inoltre i loro vettori di inizializzazione in modo errato.
  • TLS 1.0 non è più conforme allo standard PCI DSS.

Il supporto di TLS 1.2 è un prerequisito per evitare i problemi di cui sopra. Il gruppo di lavoro TLS ha deprecato TLS 1.0 e 1.1. Ora Chrome ha deprecato questi protocolli.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

Bypass della protezione avanzata per il downgrade di TLS 1.3

TLS 1.3 include una misura di protezione compatibile con le versioni precedenti per rafforzare le protezioni dal downgrade. Tuttavia, quando abbiamo distribuito TLS 1.3 l'anno scorso, abbiamo dovuto disattivare parzialmente questa misura a causa delle incompatibilità con alcuni proxy di terminazione TLS non conformi. Al momento Chrome implementa la misura di protezione dei certificati che concatenano a certificati radice noti, ma consente un bypass per il concatenamento dei certificati a certificati radice sconosciuti. Abbiamo intenzione di attivarlo per tutte le connessioni.

La protezione dal downgrade mitiga l'impatto sulla sicurezza delle varie opzioni legacy che conserviamo per garantire la compatibilità. Ciò significa che le connessioni dell'utente sono più sicure e, quando vengono scoperte vulnerabilità di sicurezza, rispondere alle domande è meno complicato. Questo, a sua volta, comporta un minor numero di siti non funzionanti per gli utenti più avanti nel tempo. Questo documento è inoltre conforme a RFC 8446.

Intent di rimozione | Stato della piattaforma Chrome | Bug di Chromium

Norme sul ritiro

Per mantenere integro la piattaforma, a volte rimuoviamo dalla piattaforma web le API che hanno seguito il loro corso. Ci possono essere molti motivi per cui dobbiamo rimuovere un'API, tra cui:

  • che vengono sostituite dalle API più recenti.
  • Vengono aggiornati in modo da riflettere le modifiche alle specifiche al fine di garantire l'allineamento e la coerenza con gli altri browser.
  • Si tratta dei primi esperimenti che non si sono mai realizzati con altri browser e possono quindi aumentare l'onere del supporto per gli sviluppatori web.

Alcune di queste modifiche avranno effetto su un numero molto ridotto di siti. Per mitigare i problemi in anticipo, cerchiamo di fornire un preavviso agli sviluppatori in modo che possano apportare le modifiche necessarie per mantenere attivi i loro siti.

Chrome attualmente dispone di una procedura per il ritiro e la rimozione di API, essenzialmente:

  • Pubblicalo nella mailing list blink-dev.
  • Imposta avvisi e fornisci scale temporali nella console Chrome DevTools quando viene rilevato l'utilizzo nella pagina.
  • Attendi, monitora e rimuovi la funzionalità quando l'utilizzo diminuisce.

Puoi trovare un elenco di tutte le funzionalità ritirate su chromestatus.com che utilizzano il filtro obsoleto e che sono state rimosse applicando il filtro rimosso. Cercheremo anche di riepilogare alcune delle modifiche, delle motivazioni e dei percorsi di migrazione in questi post.