Une page web peut-elle lire un tag NFC ?

Où cela fonctionne

Web NFC est arrivé dans Chrome 89 pour Android, selon l'article de Chrome sur Web NFC. L'entrée du statut de plateforme ne liste aucune prise en charge sur ordinateur, sur iOS ni dans la WebView d'Android : une page affichée dans le navigateur intégré d'une application ne l'a donc pas non plus.

Les autres moteurs ont dit non. La position publiée de WebKit s'oppose à l'API, au nom de la vie privée, de la sécurité et de l'indépendance vis à vis des appareils, et celle de Mozilla est négative. La spécification est incubée par un groupe communautaire du W3C plutôt que publiée en recommandation.

Une page qui lit des tags sert donc les visiteurs sous Android qui emploient Chrome, et personne d'autre. Cela convient bien mieux à un outil interne, sur des téléphones que le projet maîtrise, qu'à quoi que ce soit que le public ouvrira.

Ce qui doit précéder un scan

La page est servie en HTTPS, dans un cadre de premier niveau et non dans une iframe. Le premier scan() est appelé en réponse à un geste de l'utilisateur, un appui sur un bouton par exemple, et c'est à ce moment que Chrome demande la permission nfc. Une fois accordée, l'exemple de l'article vérifie la permission par l'API Permissions et démarre le scan sans attendre de geste.

Le téléphone a aussi besoin du matériel NFC, allumé. La détection de fonctionnalité ne le dit pas : 'NDEFReader' in window dit que le navigateur prend en charge Web NFC, et la promesse est rejetée ensuite si le matériel manque.

La spécification nomme les rejets. NotAllowedError signale une permission refusée, NotSupportedError l'absence d'adaptateur NFC, et NotReadableError que le navigateur n'a pas le droit de s'en servir, à cause d'un réglage par exemple.

Ce que la page reçoit

Chaque tag apporte un événement reading avec deux choses : le message, et serialNumber, l'identifiant que le tag emploie pour l'anticollision, ou une chaîne vide quand il n'y en a pas. Cet identifiant n'est pas un secret, comme l'explique la page de l'UID.

Le message porte des enregistrements que la page décode elle même, par recordType : texte, URL, URL absolue, MIME, affiche intelligente, type externe, vide, inconnu et types locaux. Chaque enregistrement expose sa charge utile comme une DataView, et le décodage du texte est laissé à la page.

Un tag que le navigateur ne sait pas lire comme du NDEF déclenche readingerror à la place. Sans écouteur pour cet événement, un tag non pris en charge donne l'impression que rien ne s'est passé.

Ce qui l'arrête

La page doit rester visible. Chrome suspend les opérations NFC pendant que la page est masquée et les reprend à son retour, et il bloque la radio quand l'écran est éteint ou le téléphone verrouillé.

Un tag présenté avant le démarrage du scan part vers Android, pas vers la page. L'article le dit parmi ses conseils : Android traite les tags au niveau du système avant que Web NFC ne soit opérationnel, donc un tag qui porte un lien peut déclencher le traitement de ce lien par le téléphone.

Et le scan se termine avec la page. Il n'y a pas de lecture en arrière plan : une page ne peut pas attendre des tags dans une poche comme le fait une application déclarée dans son manifeste.