Le replay semblait normal.
L'exécution ne l'était pas.

Sept questions, sept réponses.

·01

EEI remplace-t-il la lecture de session ?

Non. La lecture de session répond à la question : 'à quoi ressemblait l'expérience utilisateur ?' EEI répond à la question : 'l'environnement d'exécution était-il fiable au moment où la valeur a été transférée ?' Les deux questions sont valides ; elles sont répondues en observant des couches différentes. Les équipes ingénierie et produit utilisent la lecture de session pour reproduire des erreurs et comprendre les parcours. Les équipes fraude, risque et conformité utilisent EEI pour vérifier ce que le runtime de l'appareil a déclaré à l'exécution. La plupart des déploiements Tier-1 bénéficient des deux.

·02

La lecture de session peut-elle détecter les attaques par overlay ?

Pas de manière fiable, et pas comme evidence d'exécution signée. La lecture de session enregistre ce que le SDK de l'app a observé — elle peut faire remonter des événements UI anormaux ou des erreurs dans certains cas, ce qui peut appuyer une investigation. Mais les overlays de couche OS, l'automatisation par service d'accessibilité et la manipulation runtime se situent en dehors de l'objet normal de l'instrumentation de lecture. Le replay ne doit pas être traité comme une preuve que l'environnement d'exécution de l'appareil était cohérent. Le TRP d'EEI évalue les conditions runtime configurées au niveau de la couche d'exécution. Quand ces vérifications identifient une condition compromise — un service d'accessibilité actif dans une configuration suspecte, la présence d'un overlay, la détection d'un hook — le token signé peut porter trust_basis: compromised_device. Cette déclaration fait partie de l'artefact signé et parvient au moteur de risque de l'opérateur indépendamment de ce que la couche de vue de l'app a observé.

·03

Qu'est-ce que trust_basis et pourquoi est-ce important ?

trust_basis est un champ de chaque Evidence Token EEI qui déclare l'évaluation par le TRP de son ensemble de vérifications runtime configurées au moment de la signature. Il ne représente pas une attestation exhaustive de toutes les conditions possibles de l'appareil — il reflète ce que les vérifications configurées ont observé. Les valeurs incluent hardware_backed (clé vérifiée par attestation matérielle), hardware_bound (profil standard, sans garantie de non-exportabilité matérielle), execution_proof (les vérifications configurées ont confirmé la cohérence au moment de la signature) et compromised_device (les vérifications ont identifié une anomalie — service d'accessibilité dans une configuration suspecte, présence d'overlay, hook ou défaillance d'intégrité du processus). Aucun outil de lecture de session n'a de concept équivalent : la lecture reconstruit l'expérience de la couche de vue ; elle n'observe ni ne déclare le contexte d'exécution. trust_basis est ce qui rend les tokens EEI utiles pour les litiges et l'audit — la déclaration signée de l'état d'exécution à chaque événement voyage avec le token. Pour la portée temporelle de la fenêtre d'évaluation de chaque token, voir la page d'architecture Runtime coherence.

·04

Qu'est-ce que l'angle mort du service d'accessibilité exactement ?

Sur Android, le framework d'accessibilité permet aux services enregistrés au niveau de l'OS d'observer le contenu de l'UI et d'interagir avec les apps sur l'appareil — y compris lire le texte des vues, naviguer dans les contrôles et injecter des actions. Les usages légitimes incluent les lecteurs d'écran ; les usages malveillants incluent le détournement de transactions. Quand un service d'accessibilité pilote une transaction de paiement, le processus de l'app voit un tap normal et le SDK de lecture l'enregistre comme une interaction utilisateur normale. Le service n'est pas visible pour l'instrumentation de la couche app. Le TRP d'EEI observe si un service d'accessibilité est actif dans le contexte d'exécution et, selon la politique runtime configurée par l'opérateur, peut le refléter dans le trust_basis du token. L'enregistrement signé peut ensuite être évalué par le moteur de risque de l'opérateur indépendamment de ce que montre la lecture de session. Sur iOS, le modèle de menace diffère — les restrictions sandbox d'iOS limitent la même surface d'attaque — et les vérifications de cohérence runtime sont calibrées en conséquence par plateforme.

·05

Peut-on utiliser la lecture de session et EEI ensemble ?

Oui — et la composition est naturelle. La lecture de session est acheminée vers les outils ingénierie et produit (Datadog, FullStory, LogRocket). Les tokens EEI sont acheminés vers le moteur de risque et l'evidence store de l'opérateur. Quand une transaction sous investigation dispose à la fois d'une lecture de session et d'une chaîne EEI, l'investigateur voit le parcours visuel et l'assertion runtime signée ensemble. La lecture fournit le contexte ; le token EEI fournit la déclaration au niveau exécution que la lecture ne peut pas produire.

·06

Qu'en est-il des plateformes RUM — Datadog Mobile, New Relic mobile monitoring ?

Les plateformes RUM modernes incluant Datadog Mobile Monitoring et l'agent mobile New Relic intègrent des fonctionnalités de lecture de session ou de reconstruction wireframe en complément des métriques de performance. La même considération s'applique : ces outils observent la couche de vue de l'app via l'instrumentation SDK. Les services d'accessibilité, les overlays de couche OS et les hooks runtime se trouvent généralement en dehors de la frontière d'observation prévue du SDK. EEI n'est pas un remplacement RUM ; il produit des preuves de contexte runtime signé pour des workflows que les outils RUM n'ont pas été conçus à servir.

·07

Pourquoi le chemin de vérification est-il important pour les litiges et la conformité ?

Une lecture de session est stockée dans le cloud vendor et accessible via la plateforme du vendor. Dans un litige, l'opérateur présente la lecture en référençant le système du vendor — le vendor reste dans la piste d'audit. Un token EEI est un artefact signé JWS-compact autonome : toute partie disposant de la clé publique de l'opérateur — émetteur, plateforme de litige, auditeur, contrepartie — peut le vérifier indépendamment, sans appeler une API YinkoShield ni la plateforme du vendor de lecture. Cette distinction importe quand le vérificateur n'a pas de relation avec le vendor, quand le vendor est indisponible, ou quand une piste de vérification indépendante est requise.