Un profil Android s'exécute sur un ordinateur classique et obtient le verdict Trustworthy d'iphey. La leçon, apprise à nos dépens, consiste à ne pas attribuer manuellement le matériel du téléphone. Il reste une contrainte liée à la fenêtre de bureau, affichée ouvertement.
Créez un profil mobile avec l'option :
Le moteur sélectionne une identité mobile cohérente, avec son modèle, son chipset, son écran et sa mémoire. Le modèle est déclaré dans uaData.model ; c'est aussi là que les outils lisent le modèle. La batterie obtient 100 sur 100 et iphey renvoie Trustworthy. Aucun téléphone physique n'est nécessaire.
La première version attribuait le matériel du téléphone à partir de notre propre liste de modèles. Cette liste a associé un Pixel 7 à un chipset Redmi. Un seul chipset erroné a suffi pour qu'iphey renvoie Unreliable : les outils connaissent mieux les associations réelles entre modèles et chipsets que n'importe quelle liste maintenue à la main.
Trois profils mobiles créés à la suite sur une machine propre :
| Surface | Résultat |
|---|---|
| Polices réservées à Windows | aucune exposée ; les treize contrôles sont réussis |
| Carte vidéo | différente dans chaque profil |
| Écran déclaré | différent dans chaque profil |
| Canvas | différent dans chaque profil |
| Nombre de processeurs logiques | huit dans chaque profil, comme sur les téléphones de référence |
Les polices constituent le contrôle le plus clair. Si un profil se présentant comme un Pixel exposait Calibri ou Segoe UI, la contradiction serait immédiate : Android n'intègre pas ces polices. Nous en avons testé treize, installées uniquement avec Windows ou Microsoft Office, et le profil n'en a exposé aucune.
Le viewport de mise en page du profil mobile est plus large que l'écran déclaré. Le moteur modifie screen et outerWidth, mais le navigateur fonctionne toujours dans une véritable fenêtre de bureau. Le profil déclare 360×800, tandis que le viewport de mise en page mesure 500×731. Nous avons testé les approches suivantes :
| Approche | Largeur du viewport de mise en page |
|---|---|
| sans ajustement | 500 |
| fenêtre 412×915 | 500 |
| fenêtre 300×600 | 500 |
| échelle de rendu 1,27 | 510 |
| mode headless | 478 |
La limite vient de la largeur minimale d'une fenêtre Chrome sur ordinateur, environ 500 pixels CSS. Les téléphones n'utilisent pas un viewport aussi large ; l'écart ne peut donc pas disparaître tant que le navigateur tourne dans une fenêtre de bureau. Falsifier innerWidth sans modifier la mise en page réelle ne fonctionne pas. La première media query révélerait la vraie largeur et créerait deux valeurs contradictoires au lieu d'une.
Ce qui a pu être amélioré : après l'ouverture, NimbusX ajuste la fenêtre à la hauteur déclarée par la page et CreepJS ne signale plus la section Screen. L'écart de largeur restant est visible dans le tableau de bord : la cellule WIN est atténuée et l'explication figure sous le tableau. Le masquer n'aurait aucun sens, puisque le site le voit avant l'utilisateur.
La cohérence compte plus que la quantité · Comment les détecteurs relient les profils