Udgivelsen af Chrome 95

Google har præsenteret udgivelsen af webbrowseren Chrome 95. Samtidig er der en stabil udgave af det frie projekt Chromium, som danner grundlag for Chrome tilgængelig. Chrome-browseren er kendetegnet ved brug af Google-logoer, et system til at sende meddelelser i tilfælde af nedbrud, moduler til at afspille beskyttet videoinhold (DRM), et automatisk opdateringssystem og transmission af RLZ-parametre under søgning. I henhold til den nye 4-ugers udviklingscyklus er næste udgave, Chrome 96, planlagt til den 16. november. For dem, der har brug for mere tid til opdatering, understøttes en separat Extended Stable-gren, som har en 8-ugers opfølgningsperiode, hvor en opdatering til den tidligere udgave Chrome 94 er udformet.

De vigtigste ændringer i Chrome 95:

• For brugere af Linux, Windows, macOS og ChromeOS er der introduceret en ny sidepanel, der vises til højre for indholdet og aktiveres ved at klikke på et speciellt ikon i adresselinjen. Panelet viser et resumé af bogmærker og en læseliste. Ændringen er ikke aktiveret for alle brugere; for at aktivere kan indstillingen "chrome://flags/#side-panel" bruges.
• Der er implementeret en tydelig anmodning om tilladelser til at gemme adresser indtastet i webformularer til senere brug i autofyldssystemet. Når der findes adresser i formularer, vil brugeren nu se en dialog, der gør det muligt at gemme adressen, redigere den, opdatere en tidligere gemt adresse eller at nægte at gemme.
• Koden til understøttelse af FTP-protokollen er blevet fjernet. I Chrome 88 blev understøttelsen af FTP som standard deaktiveret, men der blev efterladt en flag til at genaktivere den.
• Understøttelsen af URL'er med hostnavne, der slutter med et tal, men ikke svarer til IPv4-adresser, er blevet stoppet. For eksempel vil URL'er som "http://127.1/", "http://foo.127.1/" og "http://127.0.0.0.1" nu blive betragtet som ugyldige.
• For WebAssembly er muligheden for at oprette undtagelseshåndtere blevet implementeret, som kan gribe ind, hvis der opstår en undtagelse under udførelsen af bestemt kode. Både fangst af kendte undtagelser fra WebAssembly-modulet og undtagelser under opkald af importerede funktioner understøttes. For at kunne fange undtagelser skal WebAssembly-modulet være kompileret med en kompilator, der understøtter undtagelser, som f.eks. Emscripten.

  Det bemærkes, at håndtering af undtagelser på WebAssembly-niveau væsentligt kan reducere størrelsen af den genererede kode sammenlignet med håndtering af undtagelser med JavaScript. For eksempel fører optimering med Binaryen, når undtagelser håndteres med JavaScript, til en stigning i koden på 43 %, mens det med WebAssembly kun er 9 %. Desuden adskiller kode med undtagelseshåndtering i WebAssembly sig praktisk talt ikke i ydeevne fra kode uden undtagelseshåndterere, når der anvendes optimeringsmetoden '-O3', mens håndtering af undtagelser via JavaScript fører til en nedsættelse af udførelseshastigheden på 30 %.

• Det er forbudt at dele WebAssembly-moduler mellem forskellige domæner (cross-origin) ved behandling af et enkelt websted.
• 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.
  • Der er indført begrænsning af informationer i HTTP-headeren User-Agent samt JavaScript-parametrene navigator.userAgent, navigator.appVersion og navigator.platform. I headeren er der kun efterladt oplysninger om browsernavn, væsentlig versionsnummer for browseren, platform og enhedstype (mobiltelefon, PC, tablet). For at få yderligere data, såsom præcise versioner og udvidede platformoplysninger, skal API'et User Agent Client Hints anvendes. Starten på begrænsning af User-Agent på systemer for almindelige brugere er planlagt til release af Chrome 102, som vil blive offentliggjort om seks måneder.
  • Der er foreslået mulighed for at oprette adgangshåndtag (Access Handles) til File System Access API'et, som gør det muligt for webapplikationer at læse og skrive data direkte til filer og mapper på brugerens enhed. For at reducere måderne, hvorpå webapplikationer kan tilgå filsystemet, planlægger Google at kombinere File System Access API'et og Storage Foundation. Som et forberedende skridt til en sådan sammenlægning er støtte til adgangshåndtag foreslået, hvilket supplerer metoderne til arbejde baseret på filhåndtag med udvidede funktioner som f.eks. at sætte skrivebeskyttelse af andre processer og skabe separate strømme til skrivning og læsning, herunder støtte til læsning og skrivning fra arbejdere i synkron tilstand.
• API'en til sikker betalingsbekræftelse er blevet stabiliseret og foreslået som standard, med implementeringen af den nye udvidelse 'payment', der giver mulighed for yderligere bekræftelse af den betalingsoperation, der udføres. Den kontrollerende part, for eksempel en bank, har mulighed for at generere en offentlig nøgle PublicKeyCredential, som kan anmodes om af sælgeren for en ekstra sikker bekræftelse af betalingen via API'en Payment Request, ved at bruge betalingsmetoden 'secure-payment-confirmation'.
• Der er implementeret overførsel af egenskaben droppedEntriesCount i callback-opkald, der er etableret gennem konstruktøren PerformanceObserver, hvilket gør det muligt at forstå, hvor mange webstedets performance-metrics der er blevet droppet, fordi de ikke kunne passe ind i den tildelte buffer.
• API'en EyeDropper er blevet tilføjet, hvilket gør det muligt at kalde browserens indbyggede interface til at bestemme farven på vilkårlige pixels på skærmen, hvilket kan anvendes, for eksempel i grafiske editorer realiseret som webapplikationer. const eyeDropper = new EyeDropper(); const result = await eyeDropper.open(); // result = {sRGBHex: '#160731'}
• Funktionen self.reportError() er blevet tilføjet, hvilket giver scripts mulighed for at udskrive fejl til konsollen ved at efterligne opkomsten af en ikke-opsnappet undtagelse.
• API'en URLPattern er blevet tilføjet til at kontrollere, om en URL matcher et specifikt mønster, hvilket for eksempel kan anvendes til at analysere links og til at omdirigere anmodninger til håndteringsprogrammer i en service worker. const p = new URLPattern({ protocol: 'https', hostname: 'example.com', pathname: '/:folder/*/:fileName.jpg', });
• API'en Intl.DisplayNames er blevet udvidet, så man kan få lokaliserede navne for sprog, lande, valutaer, dato-elementer osv. I den nye version er der tilføjet nye typer navne 'calendar' og 'dateTimeField', som gør det muligt at få lokaliserede navne for kalender og datofelter (for eksempel navnene på måneder). For typen 'language' er der tilføjet støtte til brugen af dialekter af sprog.
• I API'en Intl.DateTimeFormat er der tilføjet support til nye værdier for parameteren timeZoneName: 'shortGeneric' for at give en kort identifikation af tidszone (for eksempel 'PT', 'ET'), 'longGeneric' — lang ('Pacific Time', 'Mountain Time'), 'shortOffset' — med kort offset i forhold til GMT ('GMT+5') og 'longOffset' med lang offset i forhold til GMT ('GMT+0500').
• API U2F (Cryptotoken) er blevet erklæret forældet, og det anbefales at bruge API Web Authentication i stedet. API U2F vil som standard blive deaktiveret i Chrome 98 og helt fjernet i Chrome 104.
• Der er forbedringer i værktøjerne til webudviklere. I Styles-panelet er justeringen af CSS-egenskaber relateret til størrelse (height, padding osv.) blevet forenklet. I Issues-fanen er der mulighed for at skjule individuelle problemer. I webkonsollen samt i panelerne Sources og Properties er visningen af egenskaber forbedret (egne egenskaber fremhæves nu med fed skrift og vises øverst i listen).

Udover nye funktioner og fejlrettelser er der i den nye version rettet 19 sårbarheder. Mange af sårbarhederne blev opdaget ved hjælp af automatiserede tests med værktøjerne AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer og AFL. Der er ikke fundet kritiske problemer, der kan omgå browserens beskyttelseslag og køre kode uden for sandbox-miljøet. I forbindelse med belønningsprogrammet for opdagelse af sårbarheder, har Google udbetalt 16 præmier i alt 74.000 USD (én præmie på 20.000 USD, to præmier på 10.000 USD, én præmie på 7.500 USD, én præmie på 6.000 USD, tre præmier på 5.000 USD og én præmie hver på 3.000 USD, 2.000 USD og 1.000 USD). Størrelsen på 5 præmier er endnu ikke fastlagt.

Kilde: opennet.ru