Chrome udgivelse 95

Google har løftet sløret for udgivelsen af ​​webbrowseren Chrome 95. Samtidig er en stabil udgivelse af det gratis Chromium-projekt, der fungerer som grundlaget for Chrome, tilgængelig. Chrome-browseren er kendetegnet ved brugen af ​​Google-logoer, tilstedeværelsen af ​​et system til at sende meddelelser i tilfælde af et nedbrud, moduler til afspilning af beskyttet videoindhold (DRM), et system til automatisk installation af opdateringer og transmission af RLZ-parametre ved søgning. Under den nye 4-ugers udviklingscyklus er den næste udgivelse af Chrome 96 planlagt til den 16. november. For dem, der har brug for mere tid til at opdatere, er der en separat Extended Stable-gren, efterfulgt af 8 uger, som genererer en opdatering til den tidligere udgivelse af Chrome 94.

Vigtigste ændringer i Chrome 95:

  • For Linux-, Windows-, macOS- og ChromeOS-brugere tilbydes en ny sidebjælke, der vises til højre for indholdet og aktiveres ved at klikke på et særligt ikon i adresselinjepanelet. Panelet viser en oversigt med bogmærker og en læseliste. Ændringen er ikke aktiveret for alle brugere; for at aktivere den kan du bruge indstillingen "chrome://flags/#side-panel".
    Chrome udgivelse 95
  • Implementerede output af en eksplicit anmodning om tilladelser til at gemme adresser indtastet i webformularer til efterfølgende brug i formular autofyld systemet. Ved bestemmelse af tilstedeværelsen af ​​adresser i formularer, får brugeren nu vist en dialogboks, der giver dem mulighed for at gemme adressen, redigere, opdatere en tidligere gemt adresse eller nægte at gemme den.
  • Fjernet kode for at understøtte FTP-protokol. I Chrome 88 var FTP-understøttelse deaktiveret som standard, men der blev efterladt et flag for at bringe det tilbage.
  • Vi understøtter ikke længere URL'er med værtsnavne, der ender på et tal, men som ikke svarer til IPv4-adresser. For eksempel vil URL'erne "http://127.1/", "http://foo.127.1/" og "http://127.0.0.0.1" nu blive betragtet som ugyldige.
  • WebAssembly har nu mulighed for at oprette undtagelsesbehandlere, der kan opsnappe eksekvering, hvis der opstår en undtagelse, når en bestemt kode udføres. Det understøtter både at fange undtagelser kendt af WebAssembly-modulet og undtagelser i processen med at kalde importerede funktioner. For at fange undtagelser skal WebAssembly-modulet være kompileret med en undtagelsesbevidst compiler såsom Emscripten.

    Det bemærkes, at undtagelseshåndtering på WebAssembly-niveau kan reducere størrelsen af ​​den genererede kode betydeligt sammenlignet med undtagelseshåndtering ved hjælp af JavaScript. For eksempel resulterer opbygning af Binaryen-optimeringsværktøjet med undtagelseshåndtering ved hjælp af JavaScript i en stigning på 43 % i kode og en stigning på 9 % i kode ved hjælp af WebAssembly. Når du bruger "-O3"-optimeringstilstanden, udfører kode med undtagelseshåndtering ved hjælp af WebAssembly desuden stort set ikke anderledes end kode uden undtagelsesbehandlere, mens håndtering af undtagelser ved hjælp af JavaScript resulterer i en 30 % nedgang i eksekveringen.

  • Det er forbudt at dele WebAssembly-moduler mellem forskellige domæner (kryds-oprindelse) ved behandling af ét websted.
  • Adskillige nye API'er er blevet tilføjet til tilstanden Origin Trials (eksperimentelle funktioner, der kræver separat aktivering). Origin Trial indebærer evnen til at arbejde med den specificerede API fra applikationer downloadet fra localhost eller 127.0.0.1, eller efter registrering og modtagelse af et særligt token, der er gyldigt i en begrænset periode for et specifikt websted.
    • Aktiveret trimning af information i User-Agent HTTP-headeren og JavaScript-parametrene navigator.userAgent, navigator.appVersion og navigator.platform. Overskriften indeholder kun information om browsernavn, væsentlig browserversion, platform og enhedstype (mobiltelefon, pc, tablet). For at få yderligere data, såsom den nøjagtige version og udvidede platformsdata, skal du bruge User Agent Client Hints API. Starten med at skære User-Agent på systemerne af almindelige brugere er planlagt til udgivelsen af ​​Chrome 102, som vil blive offentliggjort om et halvt år.
    • Det er muligt at oprette Access Handles til File System Access API, som gør det muligt for webapplikationer at læse og skrive data direkte til filer og mapper på brugerens enhed. For at reducere den måde, webapplikationer får adgang til filsystemet på, planlægger Google at kombinere File System Access og Storage Foundation API'erne. Som et forberedende trin for en sådan ensretning foreslås understøttelse af adgangsdeskriptorer, der supplerer arbejdsmetoderne baseret på filbeskrivelser med avancerede muligheder, såsom at indstille en skrivelås til andre processer og oprette separate tråde til skrivning og læsning, herunder understøttelse af læsning og skrivning fra arbejdere i synkron tilstand.
  • Secure Payment Confirmation API er blevet stabiliseret og tilbudt som standard med implementeringen af ​​en ny 'betaling'-udvidelse, som giver yderligere bekræftelse af, at betalingstransaktionen udføres. En pålidelig part, såsom en bank, har evnen til at generere en offentlig nøgle PublicKeyCredential, som kan anmodes af sælgeren om yderligere sikker betalingsbekræftelse via Payment Request API'et ved hjælp af betalingsmetoden 'secure-payment-confirmation'.
  • Callback-kald installeret gennem PerformanceObserver-konstruktøren implementerer overførslen af ​​dropedEntriesCount-egenskaben, som giver dig mulighed for at forstå, hvor mange site-ydeevnemålinger, der blev kasseret på grund af det faktum, at de ikke passede ind i den angivne buffer.
  • EyeDropper API er blevet tilføjet, som giver dig mulighed for at kalde interfacet fra browseren for at bestemme farven på vilkårlige pixels på skærmen, som kan bruges for eksempel i grafiske editorer implementeret som webapplikationer. const eyeDropper = new EyeDropper(); const result = afvent eyeDropper.open(); // resultat = {sRGBHex: '#160731'}
  • Tilføjet self.reportError()-funktionen, som tillader scripts at udskrive fejl til konsollen, der emulerer forekomsten af ​​en ufanget undtagelse.
  • URLPattern API'et er blevet tilføjet for at kontrollere, om en URL matcher et bestemt mønster, som for eksempel kan bruges til at parse links og omdirigere anmodninger til behandlere i serviceworkeren. const p = new URLPattern({ protokol: 'https', værtsnavn: 'eksempel.com', stinavn: '/:mappe/*/:filnavn.jpg', });
  • Intl.DisplayNames API er blevet udvidet, hvorigennem du kan få lokaliserede navne på sprog, lande, valutaer, datoelementer osv. Den nye version tilføjer nye typer navne "kalender" og "dateTimeField", hvorigennem du kan finde ud af de lokaliserede navne på kalenderen og dato- og klokkeslætsfelter (for eksempel navnet på månederne). For typen "sprog" er der tilføjet understøttelse af brug af sprogdialekter.
  • Intl.DateTimeFormat API har tilføjet understøttelse af nye værdier af timeZoneName-parameteren: "shortGeneric" for at vise en kort tidszone-id (f.eks. "PT", "ET"), "longGeneric" for at vise en lang tidszone identifikator ("Pacific Time", "Mountain Time"), "shortOffset" - med en kort offset i forhold til GMT ("GMT+5") og "longOffset" med en lang offset i forhold til GMT ("GMT+0500").
  • U2F (Cryptotoken) API er blevet forældet, og Web Authentication API bør bruges i stedet. U2F API vil som standard være deaktiveret i Chrome 98 og fjernet fuldstændigt i Chrome 104.
  • Der er foretaget forbedringer af værktøjer til webudviklere. Panelet Typografier gør det nemmere at justere CSS-egenskaber relateret til størrelse (højde, polstring osv.). Fanen Problemer giver mulighed for at skjule individuelle problemer. I webkonsollen og panelerne Kilder og Egenskaber er visningen af ​​egenskaber blevet forbedret (egne egenskaber er nu fremhævet med fed skrift og vist øverst på listen).
    Chrome udgivelse 95

Ud over innovationer og fejlrettelser eliminerer den nye version 19 sårbarheder. Mange af sårbarhederne blev identificeret som et resultat af automatiseret test ved hjælp af AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer og AFL værktøjerne. Der er ikke identificeret nogen kritiske problemer, der ville tillade en at omgå alle niveauer af browserbeskyttelse og eksekvere kode på systemet uden for sandkassemiljøet. Som en del af kontantbelønningsprogrammet for at opdage sårbarheder for den aktuelle udgivelse, udbetalte Google 16 priser til en værdi af $74 tusinde (én pris på $20000, to priser på $10000, en pris på $7500, en pris på $6000, tre priser på $5000 og en pris på $3000). , $2000. og $1000). Størrelsen af ​​de 5 belønninger er endnu ikke fastlagt.

Kilde: opennet.ru

Tilføj en kommentar