A Google apresentou o lançamento do navegador web Chrome 95. Ao mesmo tempo, uma versão estável do projeto de código aberto Chromium, que serve como base para o Chrome, está disponível. O navegador Chrome se destaca pelo uso dos logotipos do Google, a presença de um sistema de envio de notificações em caso de falhas, módulos para reprodução de conteúdo de vídeo protegido (DRM), um sistema de instalação automática de atualizações e a transmissão de parâmetros RLZ durante as pesquisas. De acordo com o novo ciclo de desenvolvimento de 4 semanas, o próximo lançamento do Chrome 96 está programado para 16 de novembro. Para aqueles que precisam de mais tempo para atualizar, uma versão Extended Stable é mantida separadamente, acompanhada por 8 semanas, na qual foi formada uma atualização para a versão anterior do Chrome 94.
Principais mudanças no Chrome 95:
- Para usuários do Linux, Windows, macOS e ChromeOS, foi proposta uma nova barra lateral, exibida à direita do conteúdo e ativada ao clicar em um ícone específico na barra de endereços. A barra exibe um resumo de favoritos e uma lista de leitura. Essa alteração não está habilitada para todos os usuários; para ativá-la, pode-se usar a configuração “chrome://flags/#side-panel”.
- Foi implementada a exibição de um pedido explícito para salvar endereços inseridos em formulários da web, para uso posterior no sistema de preenchimento automático de formulários. Ao identificar a presença de endereços nos formulários, agora o usuário vê uma caixa de diálogo que permite salvar o endereço, editar, atualizar um endereço previamente salvo ou recusar o salvamento.
- O código para suporte ao protocolo FTP foi removido. No Chrome 88, o suporte ao FTP foi desativado por padrão, mas um sinalizador para sua reativação foi mantido.
- O suporte a URLs com nomes de host que terminam em número, mas que não correspondem a endereços IPv4, foi interrompido. Por exemplo, URLs como “http://127.1/”, “http://foo.127.1/” e “http://127.0.0.0.1” agora serão considerados inválidos.
- Para WebAssembly, foi implementada a capacidade de criar manipuladores de exceções, que podem interceptar a execução em caso de uma exceção durante a execução de um código específico. Suporta tanto a interceptação de exceções conhecidas do módulo WebAssembly quanto exceções no processo de chamada de funções importadas. Para interceptar exceções, o módulo WebAssembly deve ser montado com um compilador que suporte exceções, como o Emscripten.
Observa-se que o tratamento de exceções em nível WebAssembly permite reduzir significativamente o tamanho do código gerado, em comparação com o tratamento de exceções por meio do JavaScript. Por exemplo, a compilação do otimizador Binaryen com tratamento de exceções por JavaScript resulta em um aumento de código de 43%, enquanto que por WebAssembly é de 9%. Além disso, ao usar o modo de otimização "-O3", o código com tratamento de exceções por WebAssembly praticamente não difere em desempenho do código sem manipuladores de exceções, enquanto que o tratamento de exceções por JavaScript leva a uma desaceleração de 30%.
- É proibido o compartilhamento de módulos WebAssembly entre diferentes domínios (cross-origin) ao tratar um único site.
- No modo Origin Trials (recursos experimentais que requerem ativação separada) foram adicionadas várias novas APIs. O Origin Trial permite o uso da API especificada a partir de aplicativos carregados a partir de localhost ou 127.0.0.1, ou após registro e obtenção de um token especial, que é válido por tempo limitado para um site específico.
- Inclui-se a restrição de informações no cabeçalho HTTP User-Agent e nos parâmetros JavaScript navigator.userAgent, navigator.appVersion e navigator.platform. O cabeçalho mantém apenas informações sobre o nome do navegador, a versão principal do navegador, a plataforma e o tipo de dispositivo (telefone celular, PC, tablet). Para obter dados adicionais, como a versão exata e dados ampliados sobre a plataforma, é necessário usar a API User Agent Client Hints. O início da restrição do User-Agent em sistemas de usuários comuns está previsto para o lançamento do Chrome 102, que será lançado em seis meses.
- Foi proposta a criação de descritores de acesso (Access Handles) para a API File System Access, permitindo que aplicativos web leiam e gravem dados diretamente em arquivos e diretórios no dispositivo do usuário. Para reduzir as formas de acesso dos aplicativos web ao sistema de arquivos, a Google planeja unir a API File System Access à Storage Foundation. Como uma etapa preparatória para essa união, foi proposta a suporte a descritores de acesso, que complementa os métodos de trabalho baseados em descritores de arquivos com recursos expandidos, como definição de bloqueio de gravação por outros processos e criação de fluxos separados para gravação e leitura, incluindo suporte para leitura e gravação de workers em modo síncrono.
- O API Secure Payment Confirmation foi estabilizado e proposto como padrão, implementando uma nova extensão 'payment', que proporciona uma confirmação adicional para transações de pagamento. A parte verificadora, como um banco, pode gerar uma chave pública PublicKeyCredential, que pode ser solicitada pelo vendedor para uma confirmação segura adicional do pagamento via API Payment Request, utilizando o método de pagamento 'secure-payment-confirmation'.
- Nos callbacks configurados pelo construtor PerformanceObserver, foi implementada a passagem da propriedade droppedEntriesCount, permitindo entender quantas métricas de desempenho do site foram descartadas devido à falta de espaço no buffer fornecido.
- Foi adicionado o API EyeDropper, que permite chamar a interface fornecida pelo navegador para determinar a cor de pixels arbitrários na tela, o que pode ser aplicado, por exemplo, em editores gráficos na forma de aplicativos web. const eyeDropper = new EyeDropper(); const result = await eyeDropper.open(); // result = {sRGBHex: '#160731'}
- Foi adicionada a função self.reportError(), que permite que scripts exibam erros no console, simulando a ocorrência de uma exceção não capturada.
- Foi adicionado o API URLPattern, para verificar se a URL corresponde a um determinado padrão, que pode ser usado, por exemplo, para analisar links e redirecionar solicitações para manipuladores em um service worker. const p = new URLPattern({ protocol: 'https', hostname: 'example.com', pathname: '/:folder/*/:fileName.jpg', });
- O API Intl.DisplayNames foi expandido, permitindo obter nomes localizados de idiomas, países, moedas, elementos de datas etc. Na nova versão, foram adicionados novos tipos de nomes 'calendar' e 'dateTimeField', através dos quais é possível conhecer nomes localizados de calendário e campos de data e hora (por exemplo, o nome dos meses). Para o tipo 'language', foi adicionada a compatibilidade com dialetos de idiomas.
- No API Intl.DateTimeFormat, foi adicionada a compatibilidade com novos valores para o parâmetro timeZoneName: 'shortGeneric' para exibir um identificador curto do fuso horário (por exemplo, 'PT', 'ET'), 'longGeneric' — longo ('Pacific Time', 'Mountain Time'), 'shortOffset' — com um deslocamento curto em relação ao GMT ('GMT+5') e 'longOffset' com um deslocamento longo em relação ao GMT ('GMT+0500').
- A API U2F (Cryptotoken) foi declarada obsoleta, devendo ser substituída pela API Web Authentication. A API U2F será desativada por padrão na versão 98 do Chrome e será completamente removida na versão 104 do Chrome.
- Foram feitas melhorias nas ferramentas para desenvolvedores web. No painel Styles, a edição das propriedades CSS relacionadas ao tamanho (altura, padding, etc.) foi simplificada. Na guia Issues, agora é possível ocultar problemas específicos. Melhorias na exibição das propriedades foram implementadas na web console e nos painéis Sources e Properties (as propriedades personalizadas agora são destacadas em negrito e aparecem no topo da lista).
Além das novas funcionalidades e correções de bugs, a nova versão resolveu 19 vulnerabilidades. Muitas das vulnerabilidades foram identificadas através de testes automatizados com as ferramentas AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer e AFL. Nenhum problema crítico foi encontrado que permita contornar todos os níveis de proteção do navegador e executar código fora do ambiente sandbox. No âmbito do programa de recompensas por descoberta de vulnerabilidades para esta versão, a Google pagou 16 prêmios totalizando 74 mil dólares americanos (um prêmio de $20000, dois prêmios de $10000, um prêmio de $7500, um prêmio de $6000, três prêmios de $5000 e um prêmio de $3000, $2000 e $1000 cada). O montante de 5 prêmios ainda não foi definido.
Fonte: opennet.ru
