Ein Android-Profil läuft auf einem normalen Computer und erhält von iphey das Urteil Trustworthy. Die teuer erkaufte Erkenntnis war, Smartphone-Hardware nicht manuell zuzuweisen. Eine Einschränkung des Desktop-Fensters bleibt und wird offen angezeigt.
Ein mobiles Profil wird mit dieser Option erstellt:
Die Engine wählt eine stimmige mobile Identität aus Modell, Chipsatz, Bildschirm und Speicher. Das Gerätemodell wird in uaData.model; dort lesen auch die Prüfdienste das Modell aus. Die Testsuite erreicht 100 von 100 und iphey urteilt Trustworthy. Ein physisches Smartphone ist nicht erforderlich.
Die erste Version wies dem Smartphone Hardware aus unserer eigenen Modellliste zu. Dadurch wurde ein Pixel 7 mit einem Redmi-Chipsatz kombiniert. Ein falscher Chipsatz genügte für das iphey-Urteil Unreliable: Prüfdienste kennen reale Kombinationen aus Modell und Chipsatz besser als jede manuell gepflegte Liste.
Drei nacheinander erstellte mobile Profile auf einem sauberen Rechner:
| Oberfläche | Ergebnis |
|---|---|
| Windows-exklusive Schriften | keine sichtbar; alle dreizehn Prüfungen bestanden |
| Grafikkarte | in jedem Profil verschieden |
| Gemeldeter Bildschirm | in jedem Profil verschieden |
| Canvas | in jedem Profil verschieden |
| Anzahl logischer Prozessoren | acht in jedem Profil, wie auf den Referenz-Smartphones |
Schriften sind die eindeutigste Prüfung. Wenn ein angebliches Pixel-Profil Calibri oder Segoe UI zeigen würde, wäre der Widerspruch sofort sichtbar: Diese Schriften gehören nicht zu Android. Wir haben dreizehn Schriften getestet, die nur mit Windows oder Microsoft Office installiert werden. Das Profil legte keine davon offen.
Der Layout-Viewport eines mobilen Profils ist breiter als der gemeldete Bildschirm. Die Engine ändert screen und outerWidth, der Browser läuft jedoch weiterhin in einem echten Desktop-Fenster. Das Profil meldet 360×800, während der Layout-Viewport 500×731 misst. Wir haben folgende Ansätze geprüft:
| Ansatz | Breite des Layout-Viewports |
|---|---|
| ohne Anpassung | 500 |
| Fenster 412×915 | 500 |
| Fenster 300×600 | 500 |
| Rendering-Skalierung 1,27 | 510 |
| Headless-Modus | 478 |
Die Grenze ist die minimale Desktop-Fensterbreite von Chrome, ungefähr 500 CSS-Pixel. Smartphones verwenden keinen so breiten Viewport; solange der Browser in einem Desktop-Fenster läuft, lässt sich die Abweichung daher nicht entfernen. Eine Manipulation von innerWidth unabhängig vom echten Layout funktioniert nicht. Die erste Media Query würde die tatsächliche Breite offenlegen und zwei widersprüchliche Werte statt eines einzigen erzeugen.
Was sich verbessern ließ: Nach dem Start passt NimbusX das Fenster an die von der Seite gemeldete Höhe an, und CreepJS markiert den Bereich Screen nicht mehr. Die verbleibende Abweichung bei der Breite ist im Dashboard sichtbar: Die WIN-Zelle ist abgeblendet und unter der Tabelle steht die Erklärung. Verbergen wäre sinnlos, denn eine Website erkennt die Differenz früher als der Nutzer.
Konsistenz zählt mehr als Menge · Wie Prüfseiten Browserprofile verknüpfen