Biais de plateforme

 (mozilla.github.io)
1 points par GN⁺ 2024-01-21 | 1 commentaires | Partager sur WhatsApp
  • Le Platform Tilt de Mozilla suit les conditions techniques qui désavantagent Firefox par rapport au navigateur propriétaire de référence sur les principales plateformes logicielles, et met en évidence les écarts de concurrence en matière de sécurité, de stabilité, de performances et de fonctionnalités
  • Les problèmes liés à Apple sont les plus étendus : interdiction des moteurs de navigateur tiers, restrictions d’iOS sur le multi-processus, le JIT et les API d’accessibilité, définition du navigateur par défaut, extensions et distribution des versions bêta, jusqu’au traitement des web apps sur l’écran d’accueil
  • Sur Google Android, les points clés sont l’absence d’API d’importation des données de navigation, des flux où les apps Google ouvrent Chrome au lieu du navigateur par défaut, et des cas où des pages de résultats de recherche de moindre qualité ont été fournies à Firefox Android
  • Sur Microsoft Windows, il est difficile pour les navigateurs tiers de définir le navigateur par défaut par programmation, et des flux comme Search, Copilot et Widgets privilégient Edge
  • De manière générale, le choix du navigateur par défaut par l’utilisateur, le transfert de données entre navigateurs, les capacités du moteur et l’accessibilité de la distribution, des tests et des extensions fonctionnent, selon les plateformes, à l’avantage du navigateur maison

Ce que suit Platform Tilt

  • Platform Tilt est un tableau de bord qui suit les cas techniques où Firefox est désavantagé par rapport au navigateur de référence sur les principales plateformes logicielles
  • Les domaines visés sont la sécurité, la stabilité, les performances et les fonctionnalités, et il propose des changements pour créer un environnement concurrentiel plus équilibré
  • Les discussions sur les problèmes en temps réel se déroulent sur le platform-tilt issue tracker

Restrictions sur le moteur de navigateur et les fonctionnalités iOS sur les plateformes Apple

  • App Store forbids third-party browser engines : la règle 2.5.6 des Apple App Store Review Guidelines exige que les apps de navigation web utilisent le framework WebKit approprié et le JavaScript WebKit
    • En raison de cette politique, Firefox ne peut pas être distribué avec Gecko sur iOS
    • Cela affecte aussi la distribution de Firefox via l’App Store sur d’autres plateformes Apple comme macOS
    • La politique de l’App Store doit être modifiée pour autoriser les moteurs de navigateur tiers pour les navigateurs web
  • Support for third-party multi-process applications on iOS : les navigateurs web modernes utilisent une architecture multi-processus comprenant des processus par site et des processus dédiés à des fonctions sensibles comme le GPU
    • Safari utilise une structure multi-processus sur iOS, mais le même mécanisme n’est pas proposé aux apps tierces qui n’utilisent pas le moteur WebKit de Safari
    • iOS doit fournir un mécanisme pour créer des processus enfants isolés et communiquer efficacement avec eux
    • Les exigences incluent le nombre et la durée de vie des processus enfants selon les actions de navigation de l’utilisateur, la définition de privilèges limités, la messagerie et la mémoire partagée, des zones de mémoire partagée en lecture/écriture ou en lecture seule, des entitlement indépendants pour les processus parent et enfant, le chargement de bibliothèques dans le bundle, ainsi que le rendu IOSurface via Metal ou OpenGL et le partage entre processus
    • Firefox utilise une base de code partagée sur plusieurs systèmes d’exploitation ; l’interface et le comportement de gestion des processus doivent donc rester globalement similaires à ceux d’autres plateformes comme macOS et Android
  • JIT Support on iOS : pour déployer un moteur JavaScript/WebAssembly performant, le processus du navigateur doit pouvoir créer des zones mémoire à la fois inscriptibles et exécutables
    • Les apps iOS ne peuvent pas créer de telles autorisations mémoire via l’appel système mmap(2)
    • Une exception existe pour le moteur de rendu WebKit de Safari, qui peut créer des zones mémoire inscriptibles et exécutables
    • Sur macOS, il existe un mécanisme correspondant au Hardened Runtime entitlement com.apple.security.cs.allow-jit ; iOS doit également fournir aux navigateurs non-WebKit un entitlement équivalent ainsi que l’autorisation d’utiliser les API pthread_jit_write_protect_np et sys_icache_invalidate
  • Accessibility APIs on iOS : la documentation des API d’accessibilité d’iOS est incomplète, et de nombreuses API nécessaires pour qu’un navigateur web prenne en charge les standards web d’accessibilité ne sont pas documentées
    • WebKit semble disposer d’un bundle système closed source chargé à l’exécution, ce qui rend même difficile d’en déduire le mode d’utilisation
    • Certaines constantes entières de trait comme « visited » et « radio button », ainsi que certaines constantes entières de type de notification comme « value changed », ne sont pas publiques
    • Toutes les API d’accessibilité utilisées par WebKit devraient être documentées et stables, et idéalement WebKit devrait aussi les utiliser de la même manière que les moteurs de navigateur tiers

Écarts d’expérience utilisateur, de distribution et d’extension sur la plateforme Apple

  • Messages integration on iOS : la page d’accueil de Safari sur iOS affiche les liens récemment reçus et les contacts envoyés dans l’app Messages, mais les navigateurs tiers ne peuvent pas proposer la même fonctionnalité faute d’accès aux données de Messages

  • Importing browser data on iOS : sur iOS, les données de navigation comme l’historique, les favoris et les cookies ne sont pas accessibles aux navigateurs tiers, et il n’existe pas non plus d’API d’importation

    • Ces données sont sensibles, mais des fonctions d’importation similaires sont possibles sur les principales plateformes desktop
    • iOS pourrait encadrer l’accès à ces données sensibles avec le consentement de l’utilisateur, comme pour les données de santé et de fitness
    • L’impossibilité d’importer les données crée des frictions lors du passage de Safari à un autre navigateur

  • Setting and checking default browser on iOS : iOS ne permet pas aux navigateurs tiers d’afficher une invite système demandant à l’utilisateur de les définir comme navigateur par défaut

    • Android propose une fonction similaire via une requête de browser role, et macOS via LSSetDefaultHandlerForURLScheme et LSSetDefaultRoleHandlerForContentType
    • Les navigateurs sur iOS ne peuvent faire qu’un deep link vers l’interface Réglages, et l’utilisateur doit comprendre cet écran puis effectuer lui-même le changement
    • Sur iOS 17.2.1, il existe des cas où saisir « Default browser app » ou « Default » dans la recherche des Réglages ne fait pas apparaître l’option de changement du navigateur par défaut
    • Les navigateurs tiers ne peuvent pas non plus détecter s’ils sont actuellement le navigateur par défaut, ce qui complique l’optimisation selon l’intention de l’utilisateur ou la demande de changement au bon moment

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS : pour qu’un navigateur non WebKit prenne en charge password autofill, les one-time codes, les passkeys et Apple Pay, il doit pouvoir définir un associated domain basé sur l’origin du contenu web

    • Les navigateurs basés sur WebKit peuvent substituer l’associated domain de l’app navigateur par le domaine que l’utilisateur est en train de consulter
    • Par exemple, dans un champ de mot de passe de example.com, le navigateur doit indiquer que ce champ appartient à l’origin de example.com afin que le gestionnaire de mots de passe soit invoqué dans le périmètre de example.com
    • La prise en charge d’Apple Pay pourrait nécessiter des changements supplémentaires pour permettre l’acceptation des paiements pour des bénéficiaires Apple Pay enregistrés, comme dans Safari

  • Browser extension support on iOS : Safari prend en charge des extensions distribuées via l’iOS App Store, mais les navigateurs tiers ont du mal à proposer leur propre système d’extensions à cause de la règle 2.5.2 des App Store Review Guidelines

    • Les extensions de navigateur sont un élément clé de l’écosystème web et permettent aux développeurs d’ajouter des fonctions au navigateur pour améliorer l’utilité, l’ergonomie et l’interopérabilité avec les apps système
    • Il faudrait assouplir les exigences logicielles de l’App Store pour permettre aux navigateurs tiers d’utiliser leur propre catalogue d’extensions

  • Beta testing on iOS : sur iOS, il n’est pas possible de distribuer une version bêta d’une app via l’App Store, et il faut passer par TestFlight

    • TestFlight impose une limite de 10 000 personnes, faible au regard de la taille des communautés bêta des grands navigateurs
    • Une fois la limite atteinte, il faut retirer manuellement les anciens utilisateurs, ce qui ajoute une charge de maintenance
    • Les utilisateurs doivent installer l’app TestFlight, demander un access code, attendre, puis saisir ce code
    • Les nouvelles versions de Safari sont incluses dans les bêtas du système iOS et ne subissent donc pas les mêmes limitations
    • Parmi les solutions proposées : autoriser la distribution de préversions du navigateur sur l’App Store, ou supprimer les limites d’utilisateurs de TestFlight et permettre une diffusion illimitée via lien public

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser : sur iOS et macOS, les menus contextuels Search Web ou Search with <Search Engine>, ainsi que les points d’entrée de recherche Services dans la barre de menus de macOS, lancent la recherche dans Safari indépendamment du navigateur par défaut

  • SFSafariViewController should respect the user’s default browser : SFSafariViewController est une API de haut niveau qui permet aux apps iOS d’intégrer du contenu web dans l’app tout en confiant son rendu au navigateur de l’utilisateur

    • Cette API utilise toujours la version Safari, indépendamment du navigateur par défaut de l’utilisateur
    • Cela rend l’expérience d’affichage du contenu web incohérente et détourne du trafic des navigateurs alternatifs

  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS : la proposition actuelle d’Apple oblige les éditeurs de navigateurs souhaitant utiliser leur propre moteur à distribuer une app distincte dans l’UE au lieu de mettre à jour l’app existante

    • Les utilisateurs existants dans l’UE doivent migrer vers la nouvelle app, ce qui a peu de chances de fonctionner et crée une barrière concurrentielle
    • Les préoccupations de Firefox incluent la difficulté de découverte et de migration de Firefox WebKit vers Firefox Gecko, la perte d’accès pour les utilisateurs européens de Firefox Gecko séjournant plus de 30 jours hors de l’UE, et le cas d’utilisateurs non européens de Firefox WebKit s’installant durablement dans l’UE et restant sur une version « orphaned » qui n’est plus mise à jour
    • Les développeurs de navigateurs doivent développer, maintenir et distribuer deux apps totalement distinctes, avec en plus une migration de données complexe, une perte d’utilisateurs, une baisse de l’acquisition et des limitations sur les déploiements A/B itératifs pour les utilisateurs iOS de l’UE
    • Comme alternative, il est proposé d’inclure les webviews des deux moteurs dans un binaire et un bundle uniques à l’échelle mondiale, l’OS indiquant à l’app au démarrage son éligibilité à BrowserEngineKit

  • Web developers should be able to test with alternative browser engines on iOS regardless of location : lors de son annonce initiale, BrowserEngineKit imposait une restriction géographique qui empêchait de tester son propre moteur sur les appareils situés hors de l’UE

    • Cette restriction a été levée dans la bêta 18.2 pour le développement et les tests en local, mais elle reste en place pour les développeurs web
    • Les développeurs web hors UE peuvent eux aussi prendre en charge des utilisateurs de l’UE ; il faut donc un mécanisme permettant de tester facilement un site avec des moteurs de navigateur alternatifs, indépendamment de la localisation

  • Browsers with alternative engines should be able to install and manage home screen web apps on iOS : les moteurs de navigateur alternatifs disposent bien d’une API pour ajouter des web apps à l’écran d’accueil d’iOS, mais ces apps s’ouvrent dans Safari

    • Avant comme après l’installation, les fonctionnalités propres au moteur, l’état utilisateur et les préférences diffèrent, ce qui fragmente l’expérience
    • Apple s’est opposé à l’autorisation du rendu des web apps d’écran d’accueil par des moteurs non-WebKit pour des raisons de sécurité
    • Les exigences de sécurité de base des web apps d’écran d’accueil sont les mêmes que les exigences de sandboxing inter-sites et d’isolation déjà appliquées à la navigation web classique
    • Android délègue depuis des années le rendu des web apps à des moteurs de navigateur tiers, et iOS devrait aussi l’activer

Transfert de données, navigateur par défaut et expérience de recherche sur Google Android

  • Importing browser data on Android : sur Android, les données de navigation comme l’historique, les favoris et les cookies ne sont pas accessibles aux navigateurs tiers
    • Les données sont stockées dans le data directory de l’application de navigateur web, auquel les navigateurs tiers ne peuvent pas accéder directement
    • Il n’existe pas non plus d’API ni de ContentProvider permettant l’importation
    • L’absence d’importation des données crée une forte friction pour passer de Chrome à un autre navigateur
  • Some Android features launch Chrome instead of the user’s default browser : des fonctionnalités préinstallées de la Google application, comme Google Search et Discover, ignorent le choix de navigateur par défaut de l’utilisateur et ouvrent toujours les liens de sites web externes dans Chrome
    • Il existe aussi des points d’entrée supplémentaires dans des fonctions intégrées comme la barre de recherche de l’écran d’accueil et le lanceur d’applications
    • Chaque fois qu’un lien s’ouvre dans Chrome, l’utilisateur est détourné de son navigateur par défaut
    • Toutes les applications et fonctionnalités intégrées qui ouvrent des liens externes devraient les ouvrir dans le navigateur par défaut de l’utilisateur
  • Lower quality search result pages in third-party browser engines on Android : sur Android, l’expérience de recherche web est étroitement intégrée à plusieurs fonctions natives, et il existe des cas où Firefox reçoit des pages de résultats de recherche de moindre qualité que Chrome
    • Pour une même requête, Firefox sur Android a reçu une page contenant moins d’informations et avec une qualité de design inférieure à celle de Chrome
    • Il s’agit à proprement parler d’un problème du site Google Search, mais en raison de l’importance de la recherche et de son niveau d’intégration sur Android, cela crée un écart d’expérience utilisateur qui décourage le choix d’un navigateur tiers
    • Il n’existe aucune restriction technique empêchant cette page de fonctionner dans Firefox
    • Le statut de ce problème est closed

Parcours favorisant Edge sur Microsoft Windows

  • Setting default browser on Windows : Windows ne permet pas à un navigateur tiers de demander par programmation à être défini comme navigateur par défaut
    • Même après l’installation du navigateur, l’utilisateur doit aller lui-même dans les paramètres du système d’exploitation pour le sélectionner, ce qui crée de la friction et de l’inertie en faveur d’Edge
    • Android et macOS proposent un modèle via une invite système ou des API associées permettant à l’utilisateur d’accepter ou de refuser facilement
    • Sous Windows 10, l’interface des paramètres exige plusieurs clics et une double confirmation, et sous Windows 11, le bouton Set default existe mais reste insuffisant
  • Default browser is set to Edge by several Windows flows : Windows 10 et 11 affichent de façon récurrente des messages indiquant que Microsoft Edge est le navigateur “recommended” de Windows, et proposent une interface pour remettre Edge comme navigateur par défaut
    • Certaines formulations demandent d’appliquer les “recommended browser settings”, sans indiquer clairement qu’il s’agit de changer le navigateur par défaut
    • Les exemples sont ajoutés et retirés sur des surfaces d’interface affichées automatiquement, comme lors des mises à jour de Windows, et continuent d’évoluer
    • Les composants de Windows peuvent modifier directement le navigateur par défaut de l’utilisateur, tandis que les navigateurs tiers doivent utiliser un lien profond vers le protocole ms-settings:
    • Windows devrait lui aussi utiliser les mêmes fonctionnalités et API que celles proposées aux navigateurs tiers
  • Some Windows features launch Edge instead of the user’s default browser : au moins trois fonctionnalités majeures de Windows ouvrent les URL dans Microsoft Edge plutôt que dans le navigateur par défaut actuel
    • Windows Search ou la recherche du menu Démarrer apparaissent via la zone de recherche de la barre des tâches, le bouton de recherche, la saisie dans le menu Démarrer ou le raccourci WIN+S, et les résultats de recherche comme les liens d’articles s’ouvrent tous dans Edge
    • Windows Copilot apparaît sous Windows 11 comme une fenêtre ancrée sur le côté droit de l’écran, et ouvre dans Edge les liens présents dans les réponses ou dans la zone de rendu
    • Widgets s’appelle “news and interests” sous Windows 10, affiche des informations comme l’actualité, la météo, les actions et les résultats sportifs, et ouvre les liens vers les pages web dans Edge

À lire aussi

1 commentaires

 
GN⁺ 2024-01-21
Avis sur Hacker News

  • Il paraît qu’Android comme Microsoft ont des apps qui ouvrent les liens à leur manière plutôt que dans le navigateur choisi par l’utilisateur, mais le plus gros problème, c’est que lorsqu’on appuie sur un lien dans une app, celle-ci affiche une WebView intégrée comme s’il s’agissait d’un navigateur
    L’app peut surveiller l’activité web effectuée à l’intérieur. J’aimerais que l’Android Play Store et l’iOS App Store imposent l’ouverture de tous les sites web tiers dans le navigateur de l’utilisateur
    On pourrait classer les apps en « navigateur web » et « non-navigateur web », puis faire en sorte que les apps « non-navigateur web » n’enregistrent qu’une courte liste de domaines accessibles, environ 5 à 10, le reste étant bloqué par le système d’exploitation
    Des apps comme Facebook, FB Messenger ou Google Maps, dont l’usage principal n’est pas la navigation web, peuvent clairement être considérées comme des « non-navigateurs web »
    Cela permettrait d’empêcher le problème de surveillance des WebView intégrées, et de continuer à utiliser tels quels les mots de passe, adresses, favoris et historique de navigation synchronisés dans le profil du navigateur. Si je pouvais définir le monde à ma guise, j’exigerais aussi, pour les apps qui ouvrent des liens, un menu contextuel « ouvrir dans une fenêtre de navigation privée »

    • Personnellement, je suis du même avis, mais j’ai récemment constaté que la plupart des utilisateurs ne le sont pas. En lançant l’app autotempest, j’avais fait en sorte que tous les liens tiers menant directement aux pages de détail de véhicules sur différents sites s’ouvrent dans le navigateur par défaut de l’utilisateur, mais les utilisateurs n’ont pas aimé et voulaient fortement qu’ils s’ouvrent dans l’app
      J’ai donc fait de l’ouverture dans l’app le comportement par défaut, tout en conservant une option pour utiliser le navigateur par défaut
    • Résoudre le problème des navigateurs intégrés aux apps fait partie des toutes premières priorités d’Open Web Advocacy. Cela dit, c’est compliqué par ce qu’il est possible de faire dans le cadre du Digital Markets Act
      Je suis d’accord pour dire que c’est un sujet vraiment important ; si vous voulez aider, contactez Open Web Advocacy
    • Google a au contraire créé la fonctionnalité Custom Tabs pour pousser les développeurs Android dans la direction exactement opposée
      Même lorsqu’une app ne fait qu’ouvrir une page sans rapport, par exemple un lien fourni par l’utilisateur, il est recommandé de l’ouvrir dans un « custom tab » plutôt que dans le navigateur par défaut ; l’objectif explicite est d’éviter que l’utilisateur quitte l’app afin de préserver l’engagement
      Évidemment, il n’existe aucun réglage que l’utilisateur puisse désactiver à l’échelle du système ; il faut chercher app par app, en espérant qu’un réglage existe
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • C’est déjà possible dans une certaine mesure, puisqu’on peut appuyer sur « ouvrir dans le navigateur ». Je ne sais toutefois pas si cela va dans l’intérêt de Google
      Cela fait neuf versions majeures qu’Android a ajouté des permissions d’exécution comme pour l’appareil photo, mais l’accès à Internet ne demande toujours aucune permission
    • J’ai l’impression que les points 2 à 4, à savoir « sandboxer le contexte WebView pour qu’il ne recoupe pas la véritable activité de navigation web ni les WebView d’autres apps », entrent en conflit avec le point 1, « c’est dangereux parce que l’app peut contrôler sa propre WebView »
      Ce que signifie réellement « domaines accessibles » est aussi ambigu. Si l’on ne vérifie que le domaine de l’URL vers laquelle on a explicitement navigué, c’est trop permissif et facile à contourner ; si l’on vérifie toutes les URL de requêtes, c’est trop strict et beaucoup de développeurs pourraient ne même pas réussir à charger correctement leur propre site

  • Le fait que Mozilla soulève le problème que « l’App Store interdit les moteurs de navigateur tiers » est légitime, mais je ne sais pas si l’on a vraiment envie de tirer ce fil
    Comme il existe un monopole de Safari sur les appareils iOS, une bonne partie des développeurs se soucie de la prise en charge hors Chrome. Aujourd’hui, ils n’ont pas vraiment le choix
    Si les utilisateurs commencent à voir le message « la fonctionnalité cassée ne l’est pas dans Chrome », c’est la voie vers le monopole, et ensuite Google aura beaucoup moins besoin de consensus lorsqu’il créera de nouveaux standards du Web
    La situation actuelle est déjà un bazar, mais elle pourrait encore empirer. J’espère me tromper

    • Il est évidemment dans l’intérêt de Mozilla de contester le monopole de Safari imposé par Apple sur iOS. Le simple fait que Chrome soit lui aussi bridé sur iOS ne rend pas ce bridage bénéfique pour Firefox
      Si les restrictions d’Apple qui empêchent Firefox d’implémenter Gecko et les WebExtensions basées sur Gecko, en particulier les bloqueurs de publicité, disparaissent, la part de marché de Firefox sur iOS ne peut qu’augmenter
      Les utilisateurs de Firefox sur iOS ainsi gagnés pourront synchroniser Firefox iOS, avec blocage des pubs, avec Firefox desktop, ce qui pourrait les inciter à utiliser aussi Firefox sur desktop
    • Je venais dire la même chose. Le fait qu’on ne puisse pas remplacer Safari par Chrome sur iOS est, pour le meilleur ou pour le pire, le seul mécanisme qui empêche une domination totale de Chrome
    • Si la concurrence était libre sur iOS, je pense que beaucoup de gens installeraient Chrome. En particulier la plupart des utilisateurs de PC dont le seul appareil Apple est un iPhone
    • La raison pour laquelle je fais fonctionner mon site web sous Firefox n’est pas que je dois aussi le faire fonctionner sous Safari
      Firefox fonctionne généralement tout seul, et même si ce n’était pas le cas, Safari est déjà une plateforme négligée qui demande toujours du travail supplémentaire, ce qui ne me donne pas envie de m’occuper d’une autre stack technique en plus
    • Si Mozilla ne met pas Apple en cause, ses griefs contre d’autres entreprises pourront aussi être écartés en prenant Safari comme excuse. Comme Mozilla dit des choses justes sur le comportement d’Apple, critiquer Google/Microsoft en excluant Apple paraît hypocrite
      J’en ai assez des arguments qui défendent la situation actuelle. Le statu quo ne va pas dans la bonne direction et ne changera pas sans mesures énergiques. Même du côté de ceux qui défendent le statu quo d’Apple, on ne voit pas vraiment de plan expliquant comment les choses pourraient s’améliorer
      Safari seul ne suffit pas à empêcher la domination de Chrome, et une fois les règles de l’UE sur les app stores appliquées, il y a une probabilité non négligeable que l’ouverture des moteurs de navigateur soit imposée ; à long terme, le statu quo lui-même n’est donc pas garanti
      Nous sommes aujourd’hui à la fin d’une administration américaine qui a historiquement montré une forte volonté de faire appliquer le droit antitrust contre les entreprises technologiques. Beaucoup de gens ne mesurent pas à quel point l’administration Biden est favorable à l’antitrust
      Cette administration peut encore durer quatre ans, ou non, mais compte tenu de cette incertitude, c’est l’une des meilleures occasions depuis la première affaire antitrust contre Windows d’exiger une intervention réelle contre Google/Apple/Microsoft
      Avec une administration ouverte à l’antitrust, un changement du sentiment des consommateurs vis-à-vis des Big Tech, la pression exercée sur Apple autour d’iOS et les mouvements de Google en juin pour affaiblir les bloqueurs de publicité, le moment est propice pour pousser fortement à changer le statu quo
      Ce n’est pas sans risque, mais attendre davantage n’améliorera pas la situation. Plus on attend, moins Firefox sera pertinent, plus la probabilité d’un changement d’administration augmente, et plus il sera difficile pour Mozilla de tirer parti de l’opinion publique
      Il n’y aura jamais de moment où Mozilla pourra gagner cet argument à 100 % facilement ; s’il ne le fait pas maintenant, il finira par être complètement évincé du marché
      Je soutiens le fait de soulever le problème à fond contre tout le monde, Apple compris. Si la domination de Chrome après l’ouverture d’iOS vous inquiète, il faut traiter ce problème en régulant Google, et c’est maintenant le meilleur moment pour défendre cet argument

  • En tant qu’utilisateur Android, la principale raison pour laquelle je n’utilise pas Firefox n’est pas un comportement anticoncurrentiel, mais le fait qu’il donne une impression de lenteur
    Dans Firefox, la mise en page bouge souvent au chargement de la page d’accueil, les animations du clavier ont parfois des à-coups, et je ne peux pas utiliser l’option de menu « relâcher pour sélectionner »

    • Je l’utilise depuis des années et je n’ai jamais ressenti ce genre de différence
    • C’est quoi, « relâcher pour sélectionner » ?
    • Dans Firefox, les raccourcis de navigation au clavier de base d’un clavier externe ne fonctionnent pas du tout non plus

  • https://github.com/mozilla/platform-tilt/issues/3
    La prise en charge du JIT sur iOS est un élément beaucoup trop peu abordé dans les discussions autour de « l’UE va imposer les moteurs de rendu tiers sur iOS »
    Apple autorisera-t-il la prise en charge du JIT dans les apps ? Créera-t-il une nouvelle permission que les développeurs de navigateurs devront demander ? C’est intéressant, mais je doute que cela arrive

  • Article lié : https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    Je viens de https://news.ycombinator.com/item?id=39059255, mais il n’y a pas de commentaires là-bas

  • Sous macOS, si l’on fait un clic droit sur une sélection et qu’on choisit de chercher sur le Web, Safari s’ouvre toujours, même si le navigateur par défaut est défini sur autre chose. Peut-être que cela n’arrive que dans Mail.app, mais il me semble que cet élément a été oublié

  • Le principal grief concernant Firefox pour Android, c’est que parfois, quand on saisit un domaine dans la barre d’adresse et qu’on appuie sur Entrée, il ne se passe absolument rien.
    Ce comportement est irrégulier et ne touche que certains sites web, comme https://forum.syncthing.net.
    Fermer l’onglet ou en utiliser un autre ne résout pas le problème ; il faut forcer la fermeture de l’app pour que ça rentre dans l’ordre.

    • Le même problème existe aussi sur desktop. Ils ont, il me semble, introduit dans la barre d’adresse une modification qui ne changeait pratiquement rien et s’en sont vantés dans un billet de blog ; au passage, ils ont créé une condition de concurrence asynchrone et semblent l’avoir laissée cassée pendant des années.
      Malgré mes reproches, ça reste mieux que le navigateur de Google.
    • Je l’ai aussi vécu. C’est extrêmement agaçant. Il plante aussi parfois au hasard, et ça a commencé il y a environ un mois.

  • Je comprends l’essentiel, mais le point sur l’intégration de Messages sur iOS me met mal à l’aise.
    Une API du type « liens récemment envoyés », que l’utilisateur devrait choisir, ne poserait pas forcément problème, mais je ne voudrais absolument pas qu’une app tierce ait accès à toutes mes données de messages, même si le développeur est Mozilla.
    Pour les extensions iOS, Orion permet d’installer des extensions depuis les deux galeries Chrome et Firefox ; cela semble donc indiquer que ce n’est pas un vrai problème, ou que l’app a passé l’App Review et continue ainsi depuis des années.

  • Dans Google Colab, le copier-coller fonctionne correctement dans Chrome, mais pas dans Firefox.

  • On dit que « les informations de navigation comme l’historique, les sites mis en favoris et les cookies ne sont pas accessibles aux navigateurs tiers sur Android », mais du point de vue de l’utilisateur, pourquoi voudrais-je qu’une application tierce accède à l’historique, aux favoris et aux cookies de mon navigateur ?
    C’est clairement une fuite de confidentialité. Firefox n’a qu’à prendre les données créées par Firefox pendant que j’utilise Firefox, et pas des données provenant d’autres contextes.

    • Ce n’est une fuite que si l’accès se fait sans autorisation. Le simple fait qu’une app puisse demander l’accès à ces données, dans une situation où l’utilisateur peut répondre « absolument pas », ne pose pas problème.
    • En tant qu’utilisateur qui veut passer facilement à un nouveau navigateur, j’aimerais que ce nouveau navigateur puisse accéder aux données comme les favoris de l’ancien pour simplifier le processus.
    • C’est surtout destiné à l’import/export avec d’autres navigateurs. C’est une opération très courante lors de l’onboarding.
    • On peut clairement s’opposer à l’historique et aux cookies, mais exporter les favoris puis les réimporter est indispensable.
      Or Firefox pour Android ne prend même pas ça en charge :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • Je trouve que c’est une interprétation un peu de mauvaise foi. Les contacts et d’autres données sensibles peuvent déjà être récupérés sans « fuite de confidentialité ».
      Le ticket en question ne demande pas non plus une fonctionnalité d’import non vérifiée ; il dit qu’Android pourrait servir d’intermédiaire pour l’accès à d’autres données sensibles avec le consentement de l’utilisateur.