Inclinação da Plataforma

 (mozilla.github.io)
1 pontos por GN⁺ 2024-01-21 | 1 comentários | Compartilhar no WhatsApp
  • O Platform Tilt da Mozilla acompanha condições técnicas em grandes plataformas de software que colocam o Firefox em desvantagem em relação ao navegador primário da própria plataforma e expõem lacunas competitivas em segurança, estabilidade, desempenho e recursos
  • Os problemas ligados à Apple são os mais amplos, indo da proibição de mecanismos de navegador de terceiros, restrições de multiprocessos, JIT e APIs de acessibilidade no iOS, até configuração de navegador padrão, extensões, distribuição de betas e tratamento de web apps na tela inicial
  • No Android do Google, os pontos centrais são a ausência de uma API para importar dados do navegador, fluxos em que apps do Google abrem o Chrome em vez do navegador padrão e casos em que páginas de resultados de busca de baixa qualidade foram entregues ao Firefox no Android
  • No Windows da Microsoft, é difícil para navegadores de terceiros definir programaticamente o navegador padrão, e fluxos como Search, Copilot e Widgets priorizam o Edge
  • Em comum, a escolha do navegador padrão pelo usuário, a movimentação de dados entre navegadores, os recursos do mecanismo e a acessibilidade de distribuição, testes e extensões operam de forma favorável ao navegador da própria plataforma

O que o Platform Tilt acompanha

  • Platform Tilt é um painel que acompanha casos técnicos em que o Firefox fica em desvantagem em relação ao navegador primário em grandes plataformas de software
  • Os alvos são segurança, estabilidade, desempenho e recursos, e ele propõe mudanças para criar um ambiente competitivo mais equilibrado
  • As discussões de problemas em tempo real acontecem no platform-tilt issue tracker

Restrições de mecanismos de navegador e recursos do iOS nas plataformas Apple

  • App Store forbids third-party browser engines: a Rule 2.5.6 das App Store Review Guidelines exige que apps de navegação na web usem frameworks WebKit apropriados e o JavaScript do WebKit
    • Por causa dessa política, o Firefox não pode ser distribuído com Gecko no iOS
    • Isso também afeta a distribuição do Firefox pela App Store em outras plataformas da Apple, como o macOS
    • A política da App Store deve ser alterada para permitir mecanismos de navegador de terceiros em navegadores web
  • Support for third-party multi-process applications on iOS: navegadores web modernos usam uma arquitetura multiprocessos que inclui processos por site e processos dedicados para funções sensíveis, como a GPU
    • O Safari usa uma estrutura multiprocessos no iOS, mas o mesmo mecanismo não é oferecido a apps de terceiros que não usem o mecanismo WebKit do Safari
    • O iOS deveria fornecer mecanismos para criar processos filhos isolados e permitir comunicação eficiente entre eles
    • Os requisitos incluem número e tempo de vida dos processos filhos conforme o comportamento de navegação do usuário, configuração de permissões restritas, mensageria e memória compartilhada, regiões de memória compartilhada com acesso read/write ou read-only, entitlement independente entre processos pai e filho, carregamento de bibliotecas dentro do bundle e renderização com IOSurface via Metal ou OpenGL com compartilhamento entre processos
    • Como o Firefox usa uma base de código compartilhada em vários sistemas operacionais, a interface e o comportamento de gerenciamento de processos precisam ser, em linhas gerais, parecidos com outras plataformas como macOS e Android
  • JIT Support on iOS: para distribuir um mecanismo JavaScript/WebAssembly com bom desempenho, o processo do navegador precisa conseguir criar regiões de memória que sejam graváveis e executáveis ao mesmo tempo
    • Apps no iOS não conseguem criar esse tipo de permissão de memória com a chamada de sistema mmap(2)
    • Há uma exceção para o mecanismo de renderização WebKit do Safari, que pode criar regiões de memória graváveis e executáveis
    • No macOS, existe um equivalente por meio do entitlement do Hardened Runtime com.apple.security.cs.allow-jit; o iOS também deveria oferecer um entitlement equivalente para navegadores não WebKit e permissão para usar as APIs pthread_jit_write_protect_np e sys_icache_invalidate
  • Accessibility APIs on iOS: a documentação das APIs de acessibilidade do iOS é incompleta, e muitas APIs necessárias para que navegadores web suportem padrões web de acessibilidade não estão documentadas
    • O WebKit aparentemente tem bundles de sistema fechados carregados em tempo de execução, o que dificulta até inferir como são usados
    • Algumas constantes inteiras de traits, como “visited” e “radio button”, e constantes inteiras de tipos de notificação, como “value changed”, não são públicas
    • Todas as APIs de acessibilidade usadas pelo WebKit deveriam ser documentadas e estáveis, e o ideal seria que o WebKit também as usasse da mesma forma que mecanismos de navegador de terceiros

Lacunas de experiência do usuário, distribuição e expansão na plataforma da Apple

  • Messages integration on iOS: a página inicial do Safari no iOS mostra links recebidos recentemente e contatos enviados no app Messages, mas navegadores de terceiros não podem oferecer o mesmo recurso porque não têm permissão de acesso aos dados do Messages

  • Importing browser data on iOS: no iOS, informações de navegação como histórico, favoritos e cookies não podem ser acessadas por navegadores de terceiros, e também não existe uma API de importação

    • Esses dados são sensíveis, mas recursos de importação semelhantes são possíveis nas principais plataformas desktop
    • O iOS poderia intermediar o acesso a dados sensíveis com consentimento do usuário, como já faz com dados de saúde e fitness
    • Quando a importação de dados não é possível, mudar do Safari para outro navegador gera atrito

  • Setting and checking default browser on iOS: o iOS não oferece a navegadores de terceiros um recurso para exibir um prompt do sistema pedindo que eles sejam definidos como navegador padrão

    • O Android oferece recurso semelhante por meio da solicitação de browser role, e o macOS por meio de LSSetDefaultHandlerForURLScheme e LSSetDefaultRoleHandlerForContentType
    • Navegadores no iOS só podem fazer deep link para a interface de Configurações, e o usuário precisa entender a tela e fazer a mudança manualmente
    • Há casos em que, no iOS 17.2.1, digitar “Default browser app” ou “Default” na busca de Settings não mostra o resultado para alterar o navegador padrão
    • Navegadores de terceiros também não conseguem detectar se são atualmente o navegador padrão, o que dificulta otimizar o navegador com base na intenção do usuário ou solicitar a mudança no momento adequado

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: para que navegadores que não usam WebKit possam oferecer suporte a password autofill, one-time codes, passkeys e Apple Pay, eles precisam poder especificar associated domain com base na origin do conteúdo web

    • Navegadores baseados em WebKit podem sobrescrever o associated domain do app do navegador com o domínio que o usuário está visitando
    • Por exemplo, em um campo de senha de example.com, o navegador precisa indicar que aquele campo pertence à origin de example.com para que o gerenciador de senhas seja acionado no escopo de example.com
    • O suporte a Apple Pay pode exigir mudanças adicionais para que, como no Safari, seja possível receber pagamentos para destinatários Apple Pay registrados

  • Browser extension support on iOS: o Safari oferece suporte a extensões distribuídas pela iOS App Store, mas navegadores de terceiros têm dificuldade para oferecer seu próprio sistema de extensões por causa da diretriz 2.5.2 da App Store Review Guidelines

    • Extensões de navegador são um elemento central do ecossistema web e permitem que desenvolvedores adicionem recursos ao navegador para melhorar utilidade, usabilidade e interoperabilidade com apps do sistema
    • Os requisitos de software da App Store deveriam ser flexibilizados para permitir que navegadores de terceiros usem seu próprio catálogo de extensões

  • Beta testing on iOS: no iOS, apps beta não podem ser distribuídos pela App Store e é preciso usar o TestFlight

    • O TestFlight tem limite de 10.000 pessoas, pequeno em comparação com a base de testadores beta de navegadores de grande porte
    • Quando o limite é atingido, é preciso remover manualmente usuários antigos, o que gera carga de manutenção
    • O usuário precisa passar pelo processo de instalar o app TestFlight, solicitar um access code, esperar, e inserir o código
    • Novas versões do Safari vêm incluídas nas betas do sistema operacional iOS e não sofrem a mesma limitação
    • Como solução, foi proposto permitir a distribuição de builds de pré-lançamento de navegadores pela App Store ou remover o limite de usuários do TestFlight e permitir distribuição ilimitada por link público

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: os menus de contexto Search Web ou Search with <Search Engine> no iOS e no macOS, assim como os pontos de entrada de busca do Services na barra de menu do macOS, executam a busca no Safari independentemente do navegador padrão do usuário

  • SFSafariViewController should respect the user’s default browser: o SFSafariViewController é uma API de alto nível que permite a apps no iOS incorporar conteúdo web dentro do app, delegando a renderização ao navegador do usuário

    • Essa API sempre usa a versão do Safari, independentemente do navegador padrão do usuário
    • A experiência de exibição de conteúdo web fica inconsistente, e o tráfego escapa dos navegadores alternativos

  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS: a proposta atual da Apple exige que fornecedores de navegadores que queiram usar seu próprio motor distribuam um app separado na UE, em vez de atualizar o app existente

    • Usuários atuais na UE teriam de migrar para o novo app, o que tem baixa viabilidade e cria uma barreira competitiva
    • Entre as preocupações levantadas pelo Firefox estão a dificuldade de descoberta e migração do Firefox com WebKit para o Firefox com Gecko, a perda de acesso para usuários do Firefox com Gecko na UE ao permanecerem mais de 30 dias fora da UE, e o risco de usuários do Firefox com WebKit fora da UE que se mudarem permanentemente para a UE ficarem presos a uma versão “órfã” sem atualizações
    • Desenvolvedores de navegadores teriam de desenvolver, manter e distribuir dois apps totalmente separados, o que cria complexidade na migração de dados, evasão de usuários, redução na aquisição e limitações para rollouts iterativos de A/B voltados a usuários de iOS na UE
    • Como alternativa, foi proposta a inclusão dos webviews dos dois motores em um único binário e bundle global, com o sistema operacional informando ao app, na inicialização, a elegibilidade do BrowserEngineKit

  • Web developers should be able to test with alternative browser engines on iOS regardless of location: quando o BrowserEngineKit foi anunciado pela primeira vez, havia uma restrição geográfica que impedia o teste de motores próprios em dispositivos fora da UE

    • Essa restrição foi removida para desenvolvimento e testes locais no beta 18.2, mas ainda permanece para desenvolvedores web
    • Como desenvolvedores web fora da UE também podem oferecer suporte a usuários da UE, é necessário um mecanismo que permita testar sites facilmente em motores de navegador alternativos, independentemente da localização

  • Browsers with alternative engines should be able to install and manage home screen web apps on iOS: há uma API que permite que motores de navegador alternativos adicionem web apps à tela inicial do iOS, mas esses apps são abertos no Safari

    • Antes e depois da instalação, recursos específicos do motor, estado do usuário e preferências diferem, fragmentando a experiência
    • A Apple se opôs a permitir a renderização de web apps na tela inicial por motores que não sejam WebKit, alegando motivos de segurança
    • Os requisitos básicos de segurança para web apps na tela inicial são os mesmos requisitos de sandbox e isolamento entre sites já aplicados na navegação web comum
    • O Android já delega há anos a renderização de web apps a motores de navegador de terceiros, e isso também deveria ser habilitado no iOS

Migração de dados, navegador padrão e experiência de busca no Google Android

  • Importing browser data on Android: no Android, informações de navegação como histórico, favoritos e cookies não podem ser acessadas por navegadores de terceiros
    • Os dados ficam armazenados no data directory do aplicativo de navegador web, e navegadores de terceiros não podem acessá-los diretamente
    • Também não há API nem ContentProvider que permita a importação
    • A ausência de importação de dados cria grande atrito para mudar do Chrome para outro navegador
  • Some Android features launch Chrome instead of the user’s default browser: recursos como Google Search e Discover do Google application, que vem pré-instalado, ignoram a escolha do navegador padrão do usuário e sempre abrem links de sites externos no Chrome
    • Também há pontos de entrada adicionais em recursos integrados, como a barra de busca da tela inicial e o launcher de apps
    • Toda vez que um link é aberto no Chrome, o usuário é desviado do navegador padrão
    • Todos os apps e recursos integrados que abrem links externos deveriam abri-los no navegador padrão do usuário
  • Lower quality search result pages in third-party browser engines on Android: no Android, a experiência de busca na web é fortemente integrada a vários recursos nativos, e houve casos em que o Firefox recebeu páginas de resultados de busca de qualidade inferior em relação ao Chrome
    • Para a mesma busca, o Firefox Android recebeu uma página com menos informações e qualidade de design inferior à do Chrome
    • Embora tecnicamente isso seja um problema do site Google Search, a importância da busca e seu nível de integração no Android fazem com que isso se traduza em uma diferença de experiência do usuário que desestimula a escolha de navegadores de terceiros
    • Não há limitação técnica que impeça essa página de funcionar no Firefox
    • O status deste problema é closed

Fluxos que priorizam o Edge no Microsoft Windows

  • Setting default browser on Windows: o Windows não oferece aos navegadores de terceiros um recurso para solicitar programaticamente que eles sejam definidos como navegador padrão
    • Mesmo após instalar o navegador, o usuário precisa ir manualmente às configurações do sistema operacional e fazer a escolha por conta própria, o que cria atrito e inércia que favorecem a continuidade do uso do Edge
    • Android e macOS oferecem um padrão em que o usuário pode aprovar ou recusar com facilidade por meio de prompts do sistema ou APIs relacionadas
    • No Windows 10, é preciso clicar várias vezes e passar por uma dupla confirmação na interface de configurações; no Windows 11, há um botão Set default, mas isso ainda não é suficiente
  • Default browser is set to Edge by several Windows flows: o Windows 10 e o 11 exibem continuamente mensagens de que o Microsoft Edge é o navegador “recommended” do Windows e oferecem interfaces para trocar o navegador padrão para o Edge
    • Alguns textos pedem para aplicar “recommended browser settings”, sem deixar claro que isso altera o navegador padrão
    • Os exemplos são adicionados e removidos em superfícies de UI exibidas automaticamente, como durante atualizações do Windows, e continuam mudando
    • Componentes do Windows podem alterar diretamente o navegador padrão do usuário, mas navegadores de terceiros precisam usar deep links do protocolo ms-settings:
    • O Windows também deveria usar os mesmos recursos e APIs oferecidos a navegadores de terceiros
  • Some Windows features launch Edge instead of the user’s default browser: pelo menos três recursos importantes do Windows abrem URLs no Microsoft Edge, e não no navegador padrão atual
    • Windows Search ou Start Menu Search aparece pela caixa de busca da barra de tarefas, pelo botão de busca, pela digitação no menu Iniciar ou pelo atalho WIN+S, e tanto os resultados de busca quanto links de artigos são abertos no Edge
    • Windows Copilot aparece no Windows 11 como uma janela acoplada à direita da tela e abre links em respostas ou na área de renderização no Edge
    • Widgets era chamado de “news and interests” no Windows 10, mostra informações como notícias, clima, ações e placares esportivos, e abre links de páginas web no Edge

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-21
Opiniões no Hacker News

  • Dizem que tanto o Android quanto a Microsoft têm apps que abrem links à sua própria maneira, e não no navegador escolhido pelo usuário, mas o problema maior é que, quando se toca em um link dentro de um app, ele exibe uma webview embutida como se fosse um navegador.
    A atividade web realizada ali dentro pode ser monitorada pelo app. Eu gostaria que a Android Play Store e a iOS App Store obrigassem todos os sites de terceiros a serem abertos no navegador do usuário.
    Seria possível classificar apps como “navegador web” e “não é navegador web”, e fazer com que apps “não navegador web” registrem apenas uma lista curta de cerca de 5 a 10 domínios acessíveis, enquanto o sistema operacional bloquearia o restante.
    Apps cujo uso principal não é navegação web, como Facebook, FB Messenger e Google Maps, claramente podem ser considerados “não navegador web”.
    Isso impediria o problema de monitoramento das webviews embutidas e permitiria usar diretamente senhas, endereços, favoritos e histórico de navegação sincronizados no perfil do navegador. Se eu pudesse definir o mundo como quisesse, também exigiria que apps que abrem links tivessem um menu de contexto “abrir em janela privada do navegador”.

    • Pessoalmente penso da mesma forma, mas recentemente percebi que a maioria dos usuários não pensa assim. Ao lançar o app autotempest, fiz com que todos os links de terceiros que apontavam diretamente para páginas de detalhes de veículos em vários sites fossem abertos no navegador padrão do usuário, mas os usuários não gostaram e queriam muito que abrissem dentro do app.
      Então mudei o padrão para abrir dentro do app, mas mantive a opção de usar o navegador padrão.
    • Resolver o problema do navegador dentro do app é uma das maiores prioridades da Open Web Advocacy. No entanto, isso fica complicado por causa do que é possível fazer dentro do escopo do Digital Markets Act.
      Concordo que é uma questão realmente importante e, se quiser ajudar, entre em contato com a Open Web Advocacy.
    • O Google, na verdade, criou o recurso Custom Tabs para empurrar os desenvolvedores Android exatamente na direção oposta.
      Ele recomenda que, mesmo quando um app apenas abre uma página não relacionada, por exemplo um link fornecido pelo usuário, isso seja feito em uma “custom tab” em vez do navegador padrão; o objetivo explícito é impedir que o usuário saia do app e, assim, preservar o engajamento.
      Naturalmente, não há uma configuração que o usuário possa desativar no sistema inteiro; é preciso procurar a configuração em cada app e torcer para que ela exista.
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • Até certo ponto isso já é possível, pois dá para tocar em “abrir no navegador”. Só não sei se isso está alinhado aos interesses do Google.
      Já se passaram 9 gerações de versões principais desde que o Android adicionou permissões em tempo de execução para coisas como a câmera, mas o acesso à internet ainda não exige permissão.
    • Acho que os itens 2 a 4, “isolar em sandbox o contexto da webview para que ele não se sobreponha à atividade real de navegação web nem às webviews de outros apps”, entram em conflito com o item 1, “é perigoso porque o app pode controlar sua própria webview”.
      Também é ambíguo o que “domínios acessíveis” realmente significa. Se verificar apenas o domínio da URL para a qual o usuário navegou explicitamente, é permissivo demais e fácil de contornar; se verificar todas as URLs de requisições, é rígido demais e muitos desenvolvedores talvez nem consigam carregar corretamente seus próprios sites.

  • É justo a Mozilla questionar o fato de que “a App Store proíbe engines de navegadores de terceiros”, mas não sei se ela realmente quer puxar esse fio
    Como existe um monopólio do Safari em dispositivos iOS, muitos desenvolvedores se preocupam em dar suporte a algo que não seja Chrome. Hoje não há escolha: é preciso fazer isso
    Se os usuários começarem a receber a mensagem “o recurso quebrado não quebra no Chrome”, esse é o caminho para um monopólio; depois disso, o Google passa a precisar de muito menos consenso ao criar novos padrões da Web
    A situação atual já é uma bagunça, mas ainda pode piorar. Espero estar errado nessa previsão

    • Desafiar o monopólio do Safari imposto pela Apple no iOS obviamente é do interesse da Mozilla. O fato de o Chrome também ser reprimido no iOS não faz com que o Firefox ser reprimido seja bom para o Firefox
      Se as restrições da Apple que impedem o Firefox de implementar o Gecko e WebExtensions baseadas em Gecko, especialmente bloqueadores de anúncios, desaparecerem, a participação do Firefox no iOS inevitavelmente vai subir
      Esses usuários do Firefox no iOS passariam a poder sincronizar com o Firefox no desktop e com o Firefox no iOS com bloqueio de anúncios, o que poderia incentivá-los a usar Firefox também no desktop
    • Vim dizer a mesma coisa. Para o bem ou para o mal, o fato de não ser possível substituir o Safari pelo Chrome no iOS é o único mecanismo que impede o domínio total do Chrome
    • Acho que, se houvesse livre concorrência no iOS, muita gente instalaria o Chrome. Especialmente a maioria dos usuários de PC cujo único aparelho da Apple é o iPhone
    • O motivo pelo qual faço meu site funcionar no Firefox não é porque também preciso fazê-lo funcionar no Safari
      O Firefox geralmente simplesmente funciona e, mesmo quando não funciona, o Safari já é uma plataforma abandonada que sempre exige trabalho extra; isso não me dá vontade de me preocupar ainda mais com outra stack tecnológica
    • Se a Mozilla não questionar a Apple, suas reclamações contra outras empresas também podem ser ignoradas usando o Safari como desculpa. Como a Mozilla está dizendo a coisa certa sobre o comportamento da Apple, criticar Google/Microsoft deixando a Apple de fora parece hipocrisia
      Estou cansado da lógica que defende a situação atual. O status quo não está caminhando em uma boa direção e não vai mudar sem medidas ousadas. Mesmo entre os que defendem o status quo da Apple, não parece haver um plano de como as coisas melhorariam daqui para frente
      O Safari sozinho não é suficiente para impedir o domínio do Chrome e, depois que as regras da App Store da UE forem aplicadas, há uma possibilidade nada pequena de que a abertura das engines de navegador seja obrigatória, então no longo prazo nem o próprio status quo está garantido
      Este é um momento em que está chegando ao fim uma administração dos EUA que historicamente demonstrou forte disposição para aplicar leis antitruste contra empresas de tecnologia. Muita gente não entende plenamente o quanto a administração Biden é favorável a antitruste
      Essa administração pode ou não durar mais 4 anos, mas, considerando essa incerteza, esta é uma das melhores oportunidades desde o caso antitruste inicial contra o Windows para exigir intervenção real contra Google/Apple/Microsoft
      Com uma administração aberta a antitruste, mudança no sentimento dos consumidores em relação às big techs, pressão sobre a Apple em torno do iOS e o movimento do Google em junho para enfraquecer bloqueadores de anúncios, este é um bom momento para pressionar fortemente por mudanças no status quo
      Não é que não haja riscos, mas esperar mais não vai melhorar a situação. Quanto mais se espera, menor fica a relevância do Firefox, maior a possibilidade de mudança de administração e mais difícil fica para a Mozilla aproveitar a opinião pública
      Nunca chegará um momento em que a Mozilla possa vencer esse argumento com 100% de facilidade; se não fizer isso agora, acabará sendo completamente expulsa do mercado
      Apoio levantar o problema com força total contra todos, incluindo a Apple. Se a preocupação depois da abertura do iOS for o domínio do Chrome, esse problema deve ser tratado regulando o Google, e agora é o melhor momento para defender esse argumento

  • Como usuário de Android, o principal motivo pelo qual não uso Firefox não é conduta anticompetitiva, mas o fato de ele parecer lento
    No Firefox, o layout costuma se mexer ao carregar a página inicial, a animação do teclado às vezes dá umas engasgadas, e não dá para usar a opção de menu “soltar para selecionar”

    • Uso há anos e nunca percebi essa diferença
    • O que é “soltar para selecionar”?
    • No Firefox, nem os atalhos de navegação pelo teclado padrão de um teclado externo funcionam

  • https://github.com/mozilla/platform-tilt/issues/3
    O suporte a JIT no iOS é um fator muito pouco abordado na discussão de que “a UE vai obrigar engines de renderização de terceiros no iOS”
    A Apple permitiria suporte a JIT em apps? Criaria uma nova permissão que desenvolvedores de navegadores teriam de solicitar? É interessante, mas não acho provável

  • Artigo relacionado: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    Vim de https://news.ycombinator.com/item?id=39059255, mas lá não há comentários

  • No macOS, se você clicar com o botão direito em uma seleção e escolher pesquisar na Web, o Safari sempre abre, mesmo que você tenha definido outro navegador como padrão. Talvez isso aconteça só no Mail.app, mas parece que esse item ficou de fora

  • A maior reclamação no Firefox para Android é que, às vezes, você digita um domínio na barra de endereços e aperta Enter, mas nada acontece
    Esse comportamento é irregular e afeta apenas alguns sites, como https://forum.syncthing.net
    Fechar a aba ou usar outra aba não resolve; só corrige ao forçar o encerramento do app

    • O mesmo problema existe no desktop. Parece que fizeram uma alteração que praticamente não mudava nada na barra de endereços e se gabaram disso em um post no blog, mas no processo criaram uma condição de corrida assíncrona e deixaram isso quebrado por anos
      Apesar das reclamações, ainda é melhor que o navegador do Google
    • Também passo por isso. É muito irritante. Às vezes também trava aleatoriamente, e isso começou há cerca de um mês

  • Entendo a maior parte, mas o item de integração com o Messages no iOS não me passa uma boa impressão
    Se fosse algo como uma API de “links enviados recentemente” que o usuário precisa escolher, não haveria problema, mas eu jamais gostaria de permitir acesso a todos os dados de mensagens para um app de terceiros, mesmo que a desenvolvedora seja a Mozilla
    No caso das extensões do iOS, o Orion permite instalar extensões tanto da galeria do Chrome quanto da do Firefox, então parece que isso não é um problema real ou que passou pelo App Review e vem sendo mantido há anos

  • No Google Colab, copiar e colar funciona corretamente no Chrome, mas não no Firefox

  • Dizem que “informações de navegação como histórico, sites nos favoritos e cookies não são acessíveis por navegadores de terceiros no Android”, mas, do ponto de vista do usuário, por que eu iria querer que um aplicativo de terceiros acessasse o histórico, os favoritos e os cookies do meu navegador?
    Isso é claramente um vazamento de privacidade. O Firefox só precisa levar os dados que o próprio Firefox criou enquanto eu o uso; dados de outros contextos, não

    • Só é vazamento quando o acesso acontece sem permissão. Não há problema em o app poder solicitar acesso a esses dados se o usuário puder responder “de jeito nenhum”
    • Como usuário que quer migrar facilmente para um novo navegador, eu gostaria que o novo navegador acessasse dados como favoritos do navegador anterior para facilitar o processo
    • É principalmente para importação/exportação com outros navegadores. É uma etapa muito comum no onboarding
    • Histórico e cookies certamente são questionáveis, mas exportar favoritos e importá-los de volta é essencial
      Só que o Firefox para Android nem isso oferece :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • Acho essa interpretação meio desonesta. Contatos e outros dados sensíveis já podem ser importados sem “vazamento de privacidade”
      A issue em questão também não está pedindo um recurso de importação sem verificação; ela diz que o Android pode intermediar o acesso a outros dados sensíveis com consentimento do usuário