- Em apps para usuários no Japão com iOS 26.2 ou superior, agora é possível usar mecanismos de navegador diferentes do WebKit, com permissão para dois tipos de app: navegadores completos e apps que usam mecanismos de navegador embutidos
- A Apple concede a desenvolvedores aprovados acesso a tecnologias de sistema para implementar mecanismos de navegador de alto desempenho, como compilação JIT e suporte a multiprocessos
- Por causa dos riscos de segurança, a Apple concede essa permissão apenas a desenvolvedores que cumpram requisitos rigorosos de segurança e privacidade e se comprometam com atualizações contínuas de segurança
- Tanto apps de navegador quanto apps com navegação dentro do app precisam atender a critérios detalhados, como taxa de aprovação em testes, segurança de memória, resposta a vulnerabilidades e política de bloqueio de cookies
- A medida é vista como uma mudança de política que amplia as opções de mecanismos de navegador no mercado japonês, ao mesmo tempo em que busca manter a segurança dos usuários
Visão geral da permissão para mecanismos de navegador alternativos no iOS 26.2
- No iOS 26.2 ou superior, passa a ser permitido usar mecanismos de navegador além do WebKit para usuários no Japão
- A permissão cobre dois tipos de app:
- App de navegador dedicado (oferece experiência completa de navegação na web)
- App de navegação dentro do app fornecido pelo mantenedor do mecanismo de navegador (usa mecanismo embutido)
- A Apple concede a desenvolvedores aprovados acesso a tecnologias centrais do sistema, como compilação JIT e suporte a multiprocessos
- Como mecanismos de navegador ficam expostos a conteúdo malicioso e a dados sensíveis de usuários, a Apple aprova apenas desenvolvedores que atendam a critérios específicos e cumpram requisitos contínuos de segurança
Web Browser Engine Entitlement (para apps de navegador dedicados)
- Essa permissão permite desenvolver apps de navegador que usam mecanismos alternativos
- Antes da solicitação, é necessário revisar os requisitos e enviar o pedido à Apple
- Como referência técnica, são fornecidos BrowserEngineKit, BrowserEngineCore e o guia de configuração de navegador padrão
Requisitos de qualificação
- O app deve ser distribuído exclusivamente no iOS para o Japão e ser composto por um binário separado de outros apps que usem o mecanismo fornecido pelo sistema
- É preciso possuir o Default Browser Entitlement
- Requisitos funcionais:
- 90% ou mais no Web Platform Tests e 80% ou mais no Test262
- Os mesmos critérios também devem ser atendidos com o JIT desativado (por exemplo, no Lockdown Mode)
Requisitos de segurança
- Adotar um processo de desenvolvimento seguro e monitorar vulnerabilidades da cadeia de suprimentos
- Fornecer a URL da política de divulgação de vulnerabilidades e manter um canal para relatórios de terceiros
- Obrigação de resposta rápida, incluindo medidas de mitigação em até 30 dias
- Manter uma página pública de vulnerabilidades corrigidas
- Publicar a política de certificados raiz e participar do CA/Browser Forum
- É obrigatório oferecer suporte aos protocolos TLS mais recentes
Requisitos de segurança do programa
- Uso de linguagem com segurança de memória ou de recursos de segurança equivalentes
- Aplicação de técnicas modernas de mitigação, como Pointer Authentication Codes(PAC) e Memory Integrity Enforcement(MIE)
- Separação de processos e validação de IPC, com correção prioritária de vulnerabilidades
- Proibido usar bibliotecas que não recebam mais atualizações de segurança
Requisitos de privacidade
- Bloqueio de cookies de terceiros por padrão, liberados apenas com consentimento do usuário
- Isolamento de armazenamento por site e bloqueio de acesso entre sites
- Proibida a sincronização de estado entre apps, exceto com permissão explícita do usuário
- Proibido compartilhar identificadores do dispositivo; rotulagem no App Privacy Report é obrigatória
- APIs de acesso a PII exigem ativação e consentimento do usuário
Embedded Browser Engine Entitlement (para navegação dentro do app)
- Permite incorporar um mecanismo de navegador alternativo dentro do app para exibir conteúdo web
- A navegação dentro do app fica limitada à exibição de conteúdo acessível em um navegador web
- A interface deve ocupar a maior parte da tela, incluir um botão para abrir no navegador padrão e mostrar domínio/URL
Requisitos de qualificação
- O solicitante deve ser o responsável pelo mecanismo de navegador (browser engine steward)
- Uma organização que assume diretamente a responsabilidade pela operação e pela resposta de segurança do mecanismo
- O mecanismo deve ser separado, com arquitetura independente e suporte a Web APIs
Requisitos do app
- Distribuição exclusiva no iOS para o Japão e sem permissão de navegador padrão
- 90% no Web Platform Tests e 80% no Test262 ou mais
- Os mesmos critérios devem ser atendidos mesmo com o JIT desativado
Requisitos de segurança e do programa
- Processo de desenvolvimento seguro, política de divulgação de vulnerabilidades, resposta em até 30 dias e suporte a TLS iguais aos exigidos para apps de navegador dedicados
- Obrigação de usar linguagem com segurança de memória, aplicar técnicas modernas de mitigação de segurança e corrigir vulnerabilidades com prioridade
- Proibido usar bibliotecas que não recebam mais atualizações de segurança
Requisitos de privacidade
- Bloqueio de cookies de terceiros, isolamento de armazenamento por site e proibição de compartilhar identificadores do dispositivo
- São necessários rotulagem no App Privacy Report e consentimento do usuário ao acessar PII
Requisitos adicionais
- Ao enviar o app, é preciso informar o nome e a versão do mecanismo embutido
- Após o lançamento de uma nova versão do mecanismo, é preciso enviar uma atualização do app em até 15 dias
Materiais de referência para desenvolvedores e guia de segurança
- Secure SDLC: recomendação de desenvolvimento com foco em segurança, como modelagem de ameaças, auditoria de código e testes de fuzzing
- Memory Safety: uso da segurança de memória padrão do Swift,
std::span no C/C++ e da opção -fbounds-safety
- Vulnerability Management: necessidade de gerenciar vulnerabilidades públicas com base em CVE-ID e distribuir patches rapidamente
- Network Security: recomendação de uso do Network framework e da SecTrust API do SDK do iOS
- Suporte a TLS 1.2 e 1.3 é obrigatório; ao usar protocolos antigos, é necessário alertar o usuário
Documentos relacionados e adendos contratuais
- Embedded Browser Engine Entitlement Addendum for Apps in Japan
- Web Browser Engine Entitlement Addendum for Apps in Japan
3 comentários
Não é sarcasmo, mas imagino que o Safari esteja mesmo... cumprindo bem essa infinidade de exigências, certo?
Uau, é curioso ver isso começar no Japão também. Eu achei que algo assim fosse acontecer primeiro na Europa ou nos Estados Unidos.
Comentários do Hacker News
Não acho que a Apple vá impedir navegadores concorrentes, mas sei que isso vai acontecer
Acho que o iPhone é praticamente a última barreira contra um monopólio do Chrome/Chromium
O Google não vai largar tudo como a Microsoft fez, mas ainda assim vai ganhar esse nível de influência
Eu realmente não quero voltar a uma situação em que a maioria dos sites só funciona direito no Chrome
No fim, a teimosia da Apple, mesmo que sem intenção, acaba segurando essa tendência
Acho exagerado o medo de o Chrome dominar a web. Só porque uma nova API foi adicionada não significa que todos os sites vão usá-la
O Firefox salvou a web mesmo na era do IE com 95% de participação, então não entendo por que agora precisaríamos depender de uma única Apple
Isso parece uma espécie de impotência aprendida
Além disso, a própria web móvel está cada vez mais encolhendo em favor dos apps
Também existe a tendência de busca com IA tentar substituir a busca na web, então a influência da web deve cair ainda mais
Por exemplo, o FaceTime não dava suporte ao Firefox, então usei o Edge, e no fim tive que migrar para o Google Meet
O problema começou quando eles pararam de inovar
Tecnologias como ActiveX, Flash e Silverlight criaram problemas de segurança e estragaram a web, e no fim o IE virou um inferno tanto para desenvolvedores quanto para usuários
Acho que o Mobile Safari assumiu esse papel hoje
Eu uso Firefox no PC e no Android, mas no celular acho que navegadores baseados em Chromium são uma escolha melhor
Achei interessante a exigência das novas regras do Japão sobre o “uso de linguagens com segurança de memória”
Mas a própria Apple atende isso? O WebKit é escrito em C++
Também é vago o que exatamente significa “recursos que melhoram a segurança de memória”
Surpreende que a Apple ainda não tenha aberto isso no mundo todo
Manter um sistema em que abre em um país e bloqueia em outro vai acabar gerando confusão e custo
Para empresas multinacionais, responder a regulações complexas assim faz parte da rotina
O controle sobre motores de navegador parece ser mais uma questão de manter controle do que de receita
A negociação com o Japão foi melhor do que com a UE, mas ainda há muita insatisfação
Por isso ela não vai ceder tão facilmente no mundo todo
Parece que a Apple está aplicando ao Japão as mesmas regras de permissão para motores de navegador de terceiros que criou na UE
Mas as condições são tão rígidas que, na prática, nem na UE nenhum navegador com motor alternativo foi lançado
O app precisa ser feito como um binário totalmente separado, então navegadores grandes como o Chrome têm dificuldade para migrar
Eu esperava que as leis do Japão e da UE levassem a mudanças globais, mas as grandes empresas têm fôlego para absorver ineficiências por país
Por exemplo, o iPhone restringe o acesso a lojas de apps alternativas com base na localização
Veja esta matéria
A Apple já foi multada em dois países por causa desse pop-up
Pelo requisito de “gerente de motor de navegador”, parece que na prática só Google e Mozilla se qualificam
Até a Microsoft fica de fora por usar Blink
Motores menores dificilmente conseguiriam atender os requisitos básicos, então na prática isso parece inacessível
Agora fico pensando se finalmente vai dar para usar Firefox de verdade + uBlock Origin no iOS
Exigências complexas, APIs limitadas, bugs ignorados — tudo isso vai dificultar a vida dos desenvolvedores
Parece improvável que alguma empresa invista recursos jurídicos e de desenvolvimento para portar um motor completo só para o mercado japonês
Matéria relacionada
É bem decente
Por enquanto, dá para usar o uBlock Origin Lite para Safari ou outros bloqueadores de anúncios
O Firefox também tem seu próprio recurso de bloqueio de rastreamento
Vejo com frequência pessoas com medo de que, se a Apple abrir o ecossistema, ela perca a imagem de empresa amiga do consumidor
Mas a lógica de que “se a Apple não controlar, virá o caos” é só uma falsa dicotomia
Precisamos de um meio-termo entre o controle total da Apple e o abandono do usuário à própria sorte
Se o mercado não funciona de forma competitiva, a regulação deve proteger usuários e desenvolvedores
A Apple travar o hardware é um precedente perigoso, e preocupa que outras empresas sigam o mesmo caminho
Novos recursos ou apps só podem existir se a Apple permitir
Serviços como Dropbox e GDrive também perderam recursos ao ter que se adaptar ao backend cheio de bugs da Apple
Essa estrutura é anormal
A exigência da Apple de binário separado é praticamente uma violação da lei
Proibir compartilhamento de estado de login e forçar bloqueio de cookies não é papel do sistema operacional
E a própria Apple nem cumpre a regra de corrigir falhas de segurança em até 30 dias
Impressiona o esforço extremo que a Apple faz para criar exceções apenas em países específicos