Google udgivelsen af webbrowseren . Samtidig stabil udgivelse af et frit projekt , som danner grundlaget for Chrome. Browseren Chrome ved at bruge Google-logoer, have et system til at sende beskeder i tilfælde af nedbrud, muligheden for at downloade Flash-modulet på anmodning, moduler til afspilning af beskyttet videoinhold (DRM), et automatisk opdateringssystem og overførsel ved søgning Den næste udgave af Chrome 85 er planlagt til 25. august.
:
- understøttelse af TLS 1.0 og TLS 1.1. For at få adgang til hjemmesider via en sikker kommunikationskanal skal serveren understøtte mindst TLS 1.2, ellers vil browseren nu vise en fejl. Ifølge Google sker omkring 0,5% af websideindlæsninger stadig med de forældede versioner af TLS. Deaktiveringen er foretaget i henhold til IETF (Internet Engineering Task Force). Begrundelsen for afvisningen af TLS 1.0/1.1 er manglen på støtte til moderne chiffere (f.eks. ECDHE og AEAD) og kravet om støtte til gamle chiffere, hvis pålidelighed i den moderne udvikling af computerteknologi er blevet sat under tvivl (f.eks. kræves støtte til TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, og til integritet og autentificering anvendes MD5 og SHA-1). Indstillingen, der giver mulighed for at genaktivere TLS 1.0/1.1, vil blive bevaret indtil januar 2021.
- Blokering af (uden kryptering) eksekverbare filer og tilføjet advarsler ved usikker indlæsning af arkiver. I fremtiden planlægges det gradvist helt at ophøre med at støtte indlæsning af filer uden anvendelse af kryptering. Blokeringen er implementeret, da indlæsning af filer uden kryptering kan bruges til at udføre ondsindede handlinger ved at ændre indholdet under MITM-angreb.
- indledende support , der udvikles som et alternativ til User-Agent-headeren. Client Hints mekanismen tilbyder, som erstatning for User-Agent, en række "Sec-CH-UA-*" headers, der muliggør selektiv levering af data om specifikke parametre for browseren og systemet (version, platform osv.) først efter anmodning fra serveren. Brugeren får mulighed for at definere, hvilke parametre der er tilladt at dele, og selektivt give sådanne oplysninger til webstedsejere. Ved brug af Client Hints sendes identifikatoren ikke som standard uden en eksplicit anmodning, hvilket gør det umuligt at gennemføre passiv identifikation (som standard angives kun browserens navn). efter indtil næste år.
- af
mere strengt overførsel af cookies mellem websteder, hvilket var på grund af COVID-19. For ikke-HTTPS-anmodninger er behandling af tredjeparts cookies, der sættes ved anmodninger til websteder, der er forskellige fra domænet for den aktuelle side, forbudt. Sådanne cookies bruges til at spore brugerens bevægelser mellem websteder i koden for reklamenetværk, sociale mediewidgets og webanalyse-systemer.Vi minder om, at håndtering af cookies styres af attributten SameSite, der angives i Set-Cookie-headeren, som som standard vil blive sat til "SameSite=Lax", hvilket begrænser afsendelsen af cookies til tværgående underanmodninger, såsom anmodninger om billeder eller indlæsning af indhold via iframe fra et andet websted. Websteder kan tilsidesætte den anvendte standard SameSite-tilstand ved tydeligt at angive SameSite=None, når de sætter cookies. Desuden kan SameSite=None kun angives for cookies i Secure-tilstand (gælder for forbindelser via HTTPS). Ændringen vil blive anvendt gradvist, først for en lille procentdel af brugerne og derefter udvidet.
- Der er tilføjet eksperimentel implementering , som kan aktiveres ved hjælp af indstillingen "chrome://flags/#enable-heavy-ad-intervention". Blokeringsværktøjet giver mulighed for automatisk at deaktivere reklame-iframe-blokke, når tærskelværdierne for trafik og CPU-belastning overskrides. Blokeringen træder i kraft, hvis der i hovedtråden er brugt mere end 60 sekunder af processorens tid i alt eller 15 sekunder i et 30-sekunders interval (forbruger 50% af ressourcerne i mere end 30 sekunder), samt når der er indlæst mere end 4 MB data over netværket.
Blokeringen træder kun i kraft, hvis brugeren ikke har interageret med reklameblokken (f.eks. ikke har klikket på den) inden for tidsrammen for overskridelse af grænserne, hvilket med hensyn til trafikbegrænsningen gør det muligt at blokere automatisk afspilning af store videoer i reklamer uden brugeren eksplicit aktiverer afspilningen. De foreslåede foranstaltninger vil befri brugerne fra reklamer med ineffektiv kodeimplementering eller bevidst parasitær aktivitet (f.eks. kryptovaluta-mining). Ifølge Google udgør reklamer, der falder ind under blokeringens kriterier, kun 0,30% af alle reklameblokke, men sådan reklameforlæg forbruger 28% af CPU-ressourcerne og 27% af trafikken fra hele reklamevolumenet.
- Der er blevet arbejdet på at reducere CPU-forbruget, når browservinduet ikke er synligt for brugeren. Chrome tjekker nu, om browservinduet bliver dækket af andre vinduer, og udelukker rendering af pixels i overlappingen. Den nye funktion vil blive gradvist aktiveret: selektivt for nogle brugere vil optimeringen være tilgængelig i Chrome 84, mens den for andre vil komme i Chrome 85.
- Aktiveret som standard beskyttelse mod , såsom spam-anmodninger om at modtage push-notificeringer. Da sådanne anmodninger afbryder brugerens arbejde og distraherer opmærksomheden fra handlinger i bekræftelsesdialoger, vil der i stedet for en separat dialog i adressefeltet blive vist et informativt pop-up med en advarsel om blokeringen af anmodningen om tilladelser, som automatisk vil blive minimeret til en indikator med et billede af en gennemstreget klokke. Ved at klikke på indikatoren kan det anmodede tilladelse aktiveres eller afvises på et hvilket som helst passende tidspunkt.
- Husk brugerens valg, når der åbnes håndterere for eksterne protokoller — brugeren kan vælge "altid tillad for denne hjemmeside" for en bestemt håndterer, og browseren vil huske denne beslutning i forbindelse med den nuværende hjemmeside.
- Tilføjet beskyttelse mod ændring af brugerindstillinger uden eksplicit samtykke. Hvis en tilføjelse ændrer den foreslåede standard søgemaskine eller siden, der vises for en ny fane, vil browseren nu vise en dialog, der beder om at bekræfte den angivne handling eller annullere ændringen.
- Implementering af beskyttelse mod indlæsning af blandet multimedieindhold (når der på en HTTPS-side indlæses ressourcer via http://). På sider åbnet vha. HTTPS vil links "http://" nu automatisk blive ændret til "https://" i blokke relateret til indlæsning af billeder (tidligere blev scripts og iframe ændret, automatisk ændring af lyd- og videoressourcer forventes i næste udgave). Hvis billedet ikke er tilgængeligt via https, blokeres det for indlæsning (manuelt kan blokeringen markeres gennem menuen tilgængelig via låsesymbolet i adresselinjen).
- API-support tilføjet (udviklet som SMS Receiver API), som muliggør indtastning af et engangspassword på en webside efter modtagelse af en SMS-besked med bekræftelseskoden leveret til brugerens Android-smartphone, hvor browseren kører. SMS-bekræftelse kan for eksempel bruges til at verificere telefonnummeret, som brugeren angav ved registrering. Tidligere skulle brugeren åbne SMS-applikationen, kopiere koden til udklipsholderen, vende tilbage til browseren og indsætte koden, mens det nye API gør det muligt at automatisere denne proces og reducere den til ét tryk.
- API'et er udvidet
til at styre afspilningen af webanimationer. Den nye version tilføjer support for sammensætningsoperationer, der gør det muligt at kontrollere, hvordan effekter kombineres, og leverer nye håndterere, der kaldes ved indtræden af indholdserstatningsbegivenheder. API Web Animations understøtter nu også Promise til at definere animationsfremvisningsrækkefølgen og bedre styre, hvordan animationer interagerer med andre funktioner i applikationen. - I Origin Trials (eksperimentelle funktioner, der kræver separat aktivering) er der tilføjet flere nye API'er. Origin Trial indebærer muligheden for at arbejde med den angivne API fra applikationer, der er indlæst fra localhost eller 127.0.0.1, eller efter tilmelding og modtagelse af et særligt token, der er gyldigt i en begrænset periode for et specifikt websted.
- API til at give Service workeren adgang til HTTP Cookies, som en asynkron alternativ til brugen af document.cookie.
- API til at bestemme brugerens inaktivitet, der gør det muligt at identificere, hvornår brugeren ikke interagerer med tastatur/mus, når skærmskåneren er aktiveret, skærmen er låst eller når arbejdet udføres på en anden skærm. Informering af applikationen om inaktivitet sker ved at sende en notifikation, når en bestemt inaktivitetsgrænse er nået.
- Tilstand , hvilket gør det muligt for udvikleren at anvende mere komplet isolering af indholdshåndtering i en separat proces knyttet til kilden (origin — domæne+port+protokol) snarere end til websitet, på bekostning af opgivelse af nogle forældede funktioner såsom synkron udførelse af scripts, der bruger document.domain, og kald af postMessage() til at sende beskeder til instanser af WebAssembly.Module. Med andre ord, Origin Isolation muliggør opdeling i forskellige processer baseret på domænet af ressourcen i stedet for websitet med alle eksterne inklusioner på siderne.
- API til at anvende vektor-SIMD-instruktioner i applikationer i WebAssembly-format. For at sikre platformuafhængighed tilbydes en ny 128-bit type, som kan repræsentere forskellige typer pakkede data, samt flere grundlæggende vektoroperationer til behandling af pakkede data. SIMD øger ydeevnen ved at parallellisere databehandling og vil være nyttig ved kompilering af native kode til WebAssembly. For at aktivere SIMD-support kan indstillingen «chrome://flags/#enable-webassembly-simd» anvendes.
- Stabiliseret og nu distribueret uden for Origin Trials
API , der giver metadata om indhold, der tidligere er cachet af web-applikationer, der fungerer i Progressive Web Apps (PWS) mode. Applikationen kan gemme forskellige data på browser-siden, inklusive billeder, videoer og artikler, og ved tab af netværksforbindelse kan den bruge dem via Cache Storage API og IndexedDB. Content Indexing API muliggør tilføjelse, placering og sletning af sådanne ressourcer. I browseren bruges denne API allerede til at liste sider og multimediedata, der er tilgængelige til offline visning. - Stabiliseret version af API baseret på Promise-mekanismen, der giver en sikrere måde at styre skærmens autolåsning og overførsel af enheder til energibesparende tilstande.
- I Android-versionen understøttelse af applikationsgenveje, der giver hurtig adgang til eftertragtede standard handlinger i applikationen. For at oprette genveje er det tilstrækkeligt at tilføje elementer til web-applikationens manifest i PWA (Progressive Web Apps) format.
- For Web Worker er brugen af API , der muliggør bestemmelse af en handler til generering af en rapport, der kaldes ved adgang til forældede funktioner. Den genererede rapport efter brugerens valg kan gemmes, sendes til serveren eller behandles af et script på JavaScript.
- Opdateret API , der muliggør tilslutning af en handler, hvortil der sendes meddelelser om ændring af størrelsen på de angivne elementer på siden. I ResizeObserverEntry er der tilføjet tre nye egenskaber: contentBoxSize, borderBoxSize og devicePixelContentBoxSize for at få mere detaljerede oplysninger, der gives i form af et array af ResizeObserverSize-objekter.
- Tilføjet nøgleordet «» for at nulstille elementets stil til standardværdien.
- Fritaget fra CSS-egenskabspræfikset «-webkit-appearance» og «-webkit-ruby-position», som nu er tilgængelige som «" og "«.
- I JavaScript understøttelse af at markere metoder og egenskaber i klassen som private, hvorefter adgangen til dem kun vil være tilgængelig inden for klassen (tidligere kunne kun felter være private). For at markere metoder og egenskaber som private skal tegn «#» før feltnavnet bruges.
- I JavaScript understøttelse af (weak reference) til JavaScript-objekter, der muliggør at holde en reference til objektet uden at forhindre sletning af det relaterede objekt af garbage collector. Derudover er der også tilføjet understøttelse af finalizers, der giver mulighed for at angive en handler, der kaldes efter garbage collection af det angivne objekt.
- Forbedret oppstart af applikationer på WebAssembly takket være implementeringen i den indledende (baseline) kompilator Liftoff. og . Forbedrede værktøjer til debugging af WebAssembly, som væsentligt forbedrer ydeevnen i debuggeren ved brug af breakpoints (tidligere blev der brugt en fortolker under debugging, men nu bruges Liftoff-kompileren).
- I værktøjerne til webudviklere pphttps://developers.google.com/web/updates/2020/05/devtools er panelet til analyse af ydeevne opdateret]] med generelle oplysninger om metrikken (Total Blocking Time), som viser, hvor længe en side synes at være tilgængelig, men faktisk ikke er (dvs. siden er allerede gengivet, men hovedtråden blokeres stadig, og indtastning er ikke mulig). Der er tilføjet et nyt afsnit Experience til at analysere metrikken (Cumulative Layout Shift), som reflekterer den visuelle stabilitet af indholdet. I CSS-stilinspektøren er der implementeret en forhåndsvisning af billeder angivet gennem egenskaben «background-image».
Udover nye funktioner og fejlrettelser er der i den nye version løst . Mange af sårbarhederne blev opdaget ved hjælp af automatiserede testværktøjer , , , og . Et problem (CVE-2020-6510, buffer overflow i background fetch-handleren) er markeret som kritisk, hvilket betyder, at det muliggør omgåelse af alle niveauer af browserbeskyttelse og udførelse af kode i systemet uden for sandbox-miljøet. I forbindelse med programmer for udbetaling af belønningspenge for opdagelse af sårbarheder har Google udbetalt 26 præmier for den nuværende version på i alt 21.500 USD (to præmier på $5000, to præmier på $3000, en præmie på $2000, to præmier på $1000 og tre præmier på $500). Størrelsen på 16 præmier er endnu ikke fastlagt.
Kilde: opennet.ru
