Toni Sagrista Selles (Hacker News):

In a dramatic turn of events, the Chromium team has reversed its Obsolete tag, and has decided to support the format in Blink (the engine behind Chrome/Chromium/Edge). Given Chrome’s position in the browser market share, I predict the format will become a de factor standard for images in the near future.

[…]

I’ve been following JPEG XL since its experimental support in Blink. What started as a promising feature was quickly axed by the team in a bizarre and ridiculous manner. First, they asked the community for feedback on the format. Then, the community responded very positively. And I don’t only mean a couple of guys in their basement. Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita, and many more. After that came the infamous comment[…]

[…]

To top it off, a couple of weeks ago, the PDF Association announced their intent to adopt JPEG XL as a preferred image format in their PDF specification.

Michael Larabel (Slashdot):

JPEG-XL image support is back in the very latest Google Chrome/Chromium codebase. Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support.

Luca Versari et al. (via Jarek Duda):

We’re excited to announce that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155. JPEG XL is a next-generation image format designed to meet the needs of modern web developers and photographers. It offers 30-50% better compression than JPEG, lossless compression, built-in HDR support, lossless JPEG transcoding, and more.

In general, we recommend trying both AVIF and JPEG XL to get the best results. We expect that JPEG XL is most helpful for high-fidelity or lossless compression, especially of photographic images or in cases in which fine-grained progressive decoding is preferred.

Previously:

• Chrome Doesn’t Support JPEG XL
• iPhone 16 Adds JPEG XL

A Apple bloqueou recentemente oito certificados vulneráveis que eram utilizados pelo Safari para determinar se uma página da web era legítima ou não — recurso que existe para proteger usuários de cópias baratas de sites feitas para golpes.

De acordo com informações do BleepingComputer, essas chaves privadas foram revogadas pela autoridade certificadora indiana eMudhra após pesquisadores descobrirem que eram tão fracas que qualquer pessoa poderia utilizá-las para forjar um certificado de uma página legítima.

Além do Safari, navegadores populares como o Mozilla Firefox e o Google Chrome também se baseavam nesses certificados para proteger usuários. Em um relatório, inclusive, a Mozilla explicou que todos os oito certificados utilizavam chaves privadas P-384 (geradas em abril de 2025), as quais tinham valores menores que 256 — o que permitia a qualquer pessoa recuperá-las testando apenas 256 possibilidades.

Descoberta primeiro por um pesquisador identificado apenas como Wayne, em 17 de outubro, a vulnerabilidade foi demonstrada no GitHub por outro pesquisador chamado Flüpke, o qual mostrou que uma chave privada para o certificado “EM OV TLS CA – G3C” da eMudhra contava com um valor de apenas 4.

Em uma resposta à Mozilla, desenvolvedora do Firefox, a eMudhra disse que identificou um erro em um script usado para gerar certificados que fazia com que um segundo conjunto de chaves mais fracas fosse gerado — as quais eram, então, selecionadas erroneamente como as chaves definitivas por terem rótulos parecidos com os das chaves corretas.

A autoridade também colocou panos quentes na situação ao afirmar que a maioria dos certificados nunca foi usada em produção e que não encontrou evidências de que o problema tenha afetado usuários finais.

Além do Safari, o Firefox e o Chrome também já revogaram esses certificados.

Macs ainda podem estar vulneráveis

Ainda de acordo com o veículo, Dennis Jackson, engenheiro de criptografia da Mozilla, alertou que o utilitário embutido /usr/bin/curl do macOS poderá continuar confiando nesses certificados vulneráveis, pois o seu bundle de certificados não verifica se os certificados foram revogados.

Isso quer dizer que, caso o Mac já tenha aceitado algum desses certificados, ele continuará confiando nele até que haja uma correção — algo que só poderá ser feito em uma futura atualização de segurança.

O Google anunciou uma série de novidades envolvendo cibersegurança para o Chrome, incluindo uma nova página de aviso para sites perigosos, proteção contra ataques do tipo ClickFix e uma expansão da detecção de golpes com o Gemini.

Agora, avisos sobre sites maliciosos se dividem entre “sites suspeitos” (quando há uma avaliação com menor grau de confiança, indicando um possível risco de danos ao usuário) e “sites perigosos” (quando há uma avaliação com alto grau de confiança, indicando um risco elevado de danos ao usuário).

Para sites suspeitos, os usuários são apenas notificados, enquanto para sites perigosos o aviso é exibido em um formato de tela inteira com fundo vermelho:

Essa avaliação, feita pelo recurso de Proteção Reforçada, também ganhou novidades, já que o Google migrou a ferramenta para um novo modelo do Gemini, capaz de avaliar o conteúdo das páginas (como a marca representada ou a intenção delas) e, se necessário, enviá-lo à nuvem.

O Google destacou, porém, que o Chrome minimiza a quantidade de dados compartilhados com os servidores, analisando o texto das páginas somente quando um site apresenta indicadores de golpe com alto grau de confiança. Sempre que algo é processado fora do dispositivo, o Google afirma que não registra logs, não armazena essas informações nem treina os modelos de IA da empresa com esses dados.

Além disso, o mesmo recurso passa a oferecer proteção contra golpes do tipo ClickFix (ataques que simulam verificações CAPTCHA para induzir usuários a copiar e colar comandos maliciosos no Terminal do macOS ou no prompt de comando do Windows), detectando automaticamente quando o usuário é induzido a copiar comandos suspeitos, que são “higienizados” antes de serem enviados para a área de transferência da máquina, com a remoção de informações de identificação pessoal (PII), e encaminhados à Navegação Segura para análise adicional. Se o comando for nocivo, um alerta é exibido.

via Tecnoblog

Sayan Sen (Hacker News):

For a while now the transition away from Manifest V2 (MV2) to MV3 has been on-going and it looks like it is entering its final phase of deprecation, at least, in the case of Google Chrome. A recent discussion thread in the w3c WebExtensions Community Group GitHub repo has highlighted how the latest and upcoming versions of the most popular browser are expected to be its final releases with support for MV2 extensions.

[…]

Here is a rundown of the changes coming in the final such releases of Chromium releases:

• Chromium 150 lost ExtensionManifestV2Disabled option
• Chromium 151 will loose ExtensionManifestV2Unsupported option
• Chromium 151 will loose ExtensionManifestV2Availability option
• Chromium 151 will likely loose AllowLegacyMV2Extensions option

Other Chromium-based browsers like Opera and Microsoft Edge could soon follow suit too. Although it is not specified, Edge began disabling uBlock Origin back in February, and Opera could also stop the functioning of MV2 add-ons, even though it had committed to support MV2 for longer in October 2024.

Google:

Aug 31st 2026: All remaining Manifest V2 extensions removed from the Chrome Web Store

Previously:

• Chrome Warning About Manifest V2 Extensions
• Chrome’s Manifest V3 and uBlock Origin

Update (2026-09-02): Web Iterate (Hacker News):

Google today reached the final milestone in a browser-extension transition that has been years in the making, all remaining Manifest V2 extensions were removed from the Chrome Web Store.