Passer au contenu

Il sera bientôt plus simple de payer en ligne avec votre mobile… mais gare à vos données !

Le consortium en charge du développement des technologies du Web travaille à une nouvelle solution pour fluidifier les paiements en ligne depuis un mobile. Si la simplicité est là, des questions sur le respect de nos vies privées se posent.

Parcours du combattant longuet et frustrant, qui demande de farfouiller d’une main son portefeuille pendant qu’on tient son smartphone de l’autre, l’achat en ligne sur mobile tombe souvent à l’eau. Alors que la majeure partie des sessions de surf se font sur mobile, un peu moins d’un tiers des achats en ligne se concluent sur smartphone, déplorait récemment Google dans un document de présentation d’un nouveau « candidat standard » du W3C qu’il a largement contribué à développer.

Faciliter les achats en ligne mobiles

Appelée Payment Request API, cette technologie devrait quitter le 31 octobre prochain le statut de « candidate recommendation » pour passer au stade suivant « proposed recommendation », avant de devenir un standard du W3C de plein droit.

Mais quel est son but ? Simplifier la procédure d’achat en supprimant les formulaires de paiement à remplir en fin de parcours. Précisons qu’il ne s’agit pas d’une nouvelle méthode de paiement. L’API Payment Request est conçue pour fonctionner quel que soit le site d’e-commerce.

Dans les faits, l’API donne plus d’importance au navigateur, puisqu’il va devenir l’intermédiaire entre le site marchand, l’utilisateur et les méthodes de paiement. Le navigateur propose ainsi un « flux » de communication standardisé pour les achats, capable de gérer différents moyens et méthodes de paiement.

Google

De manière schématique, le site Web établit une requête de paiement dans laquelle sont détaillées toutes les informations dont il a besoin. Le navigateur la reçoit et va réunir les données nécessaires au règlement auprès de l’application de paiement (qui valide les informations bancaires et le transfert des fonds), et de l’utilisateur (adresse, numéro de téléphone, acceptation de l’acheteur, etc.). Le fureteur renvoie ensuite la réponse au site qui procède au traitement de la commande.

Côté utilisateur, une pop-up s’affiche dans laquelle il est possible de choisir une adresse de livraison, un mode d’expédition et une méthode de paiement, par exemple. Si ces données ont été déjà enregistrées dans le navigateur, elles sont fournies par la fonction d’autoremplissage.
Il est bien entendu possible d’éditer ces éléments. Mais en général, l’achat peut se faire en deux étapes rapides. Appuyer sur le bouton Acheter pour afficher la fenêtre et cliquer ensuite sur Paiement pour valider l’opération.

Plus de sécurité….

Le plus intéressant avec cette solution, c’est que les sites d’e-commerce n’ont plus besoin de conserver les coordonnées bancaires de leurs clients. Cela signifie que ces informations très sensibles restent sur l’ordinateur ou le smartphone de l’utilisateur. Le risque de les voir dérobées lors d’une attaque est donc moindre. 

Mais la responsabilité est du coup reportée sur les utilisateurs, qui devront être bien plus précautionneux. En effet, en conservant les données localement, ils se verront obligés d’être plus vigilants face à d’éventuels malwares qui récupèrent vos identifiants, par exemple, et seraient a priori capables de récupérer les informations bancaires, stockées comme des mots de passe.

01net.com – Deux exemples d’interface de l’API Payment Request.

La solution de l’API Payment Request est-elle plus sûre ? Tout dépend de votre degré de confiance… en vous. Une chose est certaine, elle évitera les fuites de données en masse.

… moins de vie privée ?

Quoi qu’il en soit, au-delà de la question de la sécurité se pose celle de la vie privée. En donnant un pouvoir et un rôle centralisateur aux navigateurs, ce futur standard leur donne une vision complète de vos achats en ligne.

Il est donc fort possible que les défenseurs les plus actifs ou les utilisateurs les plus inquiets refusent d’utiliser cet outil. 

Mais il y a pire, le chercheur en sécurité Lukasz Olejnik s’est penché sur cette API et craint qu’elle puisse être utilisée par des sites (pas forcément marchands) afin d’établir des profils précis de leurs utilisateurs. Ils pourraient ainsi savoir quelles options de paiement chaque visiteur/navigateur a adoptées pour les sessions de surf classiques et celles effectuées en mode Navigation privée.

Car c’est un autre revers de l’API Payment Request : elle permet à un site Web de détecter quand une personne surfe incognito, ce qui « généralement ne devrait pas être possible », note l’expert.

Lukazs Olejnik indique avoir communiqué ses analyses au W3C, qui devrait clore la phase d’étude de ce standard en devenir d’ici la fin d’année. Un délai suffisant a priori pour corriger le tir. 

Pour l’heure, Chrome (sur Android depuis août 2016 et sur ordinateur depuis le mois dernier) et Edge (depuis septembre 2016, même s’il faut créer un compte Microsoft Wallet) sont les seuls navigateurs à supporter cette API. Firefox et Safari travaillent toujours à l’implémentation de ce standard en chantier. On imagine en tout cas qu’Apple aura plutôt tendance à vouloir pousser sa solution Apple Pay pour le Web. Samsung est également en cours d’étude de cette solution… comme Facebook, dont un des salariés est éditeur du standard au sein du W3C. Microsoft et surtout Google sont toutefois les plus gros contributeurs.

En attendant de la voir arriver dans tous nos navigateurs, l’API Request Payment est en tout cas une belle illustration de la difficulté de concilier à la fois la sécurité (informatique et des données privées) et la simplicité d’utilisation. Or, il faut impérativement que la préservation de nos données soit respectée pour qu’une telle fonction mérite d’être adoptée. Tant pis s’il faut continuer à jongler entre notre carte bancaire et notre smartphone à chaque achat…

Sources :
Site du W3C Payment Request API
Blog de Lukazs Olejnik

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Pierre FONTAINE