Idée principale

Pour faire sortir du texte d'une conversation vers un serveur personnel, on peut déguiser une écriture en lecture : au lieu d'envoyer les données, on les glisse dans l'adresse d'une page Web et on demande à l'assistant de consulter cette page. Côté serveur, la ruse fonctionne parfaitement — depuis un navigateur, depuis une commande en ligne.

Elle échoue dès que c'est l'assistant qui fabrique l'adresse à partir du contenu de l'échange, puis la consulte. Ses protections de navigation bloquent l'opération.

La raison est que la protection ne porte pas sur la forme de la requête mais sur qui la fabrique et avec quoi. Déguiser la requête ne change rien à ces deux paramètres.

Pourquoi c'est important

Cela donne un critère avant d'investir dans un contournement : de quoi la restriction dépend-elle ? Si elle dépend de la forme — une méthode, un type d'appel —, la déguiser peut marcher. Si elle dépend de l'acteur ou de la provenance des données, aucun déguisement n'aboutira, et le temps passé sera perdu.

L'échec est d'ailleurs cohérent : le mécanisme visait exactement ce qu'on tentait de faire, sortir automatiquement du contenu de conversation vers un serveur tiers.

Nuances et limites

Le constat vaut pour les protections observées ici, à un moment donné. Elles évoluent, et rien ne garantit qu'elles restent placées au même endroit.

Et il ne dit rien de la légitimité du contournement : un usage personnel et un usage détourné rencontrent le même mur, pour de bonnes raisons dans un cas seulement.

Questions ouvertes

• Comment identifier, sans tout essayer, ce sur quoi une restriction porte réellement ?