En raison des réglementations européennes sur la confidentialité, il est préférable d’éviter les requêtes vers des domaines tiers initiées par un site Web que vous hébergez. Il est difficile d’assurer la conformité avec Discourse, car la fonctionnalité Onebox amène le navigateur à récupérer la miniature du site Web d’origine, ce qui en fait une requête tierce. Voir l’article ci-dessous en onebox :
Vous pouvez voir dans les outils de développement que l’image est téléchargée à partir d’un site Web tiers. Comme le souligne également l’article, il s’agit d’un problème de RGPD même si la requête n’a pas de cookies.
Actuellement, j’ai désactivé la fonction onebox pour mon instance de Discourse, mais j’aimerais la réintroduire d’une manière qui respecte plus strictement la vie privée et n’ouvre pas la voie à une amende.
Les images pourraient être servies à partir d’un domaine principal, ou d’un domaine personnalisé comme cdn.mondomaine.com.
Vous ne pouvez pas enregistrer d’images tierces sur votre propre installation en raison du droit d’auteur, ce qui est très difficile avec les images (et cela rend une fonctionnalité de Discourse assez discutable, mais c’est une autre histoire). Mais le oneboxing n’est pas contraire au RGPD et ne l’a jamais été. Pour être du côté de la sécurité, il est sage de dire qu’il y a une tierce partie impliquée en créant des liens et que le respect du RGPD est de leur responsabilité. Mais vous n’en avez pas non plus besoin.
Le oneboxing en soi ne l’est pas, mais servir des ressources tierces l’est clairement, voir le cas Google Fonts ci-dessus
Peut-être pourrions-nous plutôt les proxifier via le serveur Discourse, de sorte que les tiers ne verraient que l’adresse IP du serveur Discourse, pas celle de l’utilisateur ?
Hein, c’est intéressant ! Est-ce une sorte de plugin ou un paramètre que je pourrais activer sur mon instance ?
Le Oneboxing ne sert pas de service tiers. Et le RGPD autorise l’utilisation des polices Google, il doit en informer les utilisateurs — et Google respecte également le RGPD.
Mais il ne s’agit pas du tout d’une question de RGPD. Les iframes, oui.
Il ne s’agit pas tant de « dire » aux utilisateurs que d’avoir une base légale, comme le consentement ou l’intérêt légitime. Avec le consentement, vous devez avoir un moyen pratique de refuser le consentement et ensuite la ressource n’est pas chargée. Avec un intérêt légitime, vous devez effectuer une évaluation des raisons légitimes, et moi (et j’imagine de nombreux autres administrateurs d’hébergements Discourse) préférerais ne pas le faire et plutôt désactiver complètement le oneboxing, ou masquer l’adresse IP de l’utilisateur derrière un proxy.
Il s’agit précisément de le dire. Vous avez besoin du consentement lors de la collecte, de l’utilisation et du stockage des données personnelles d’un utilisateur. Et même dans ce cas, vous devez dire ce que vous faites, pourquoi vous le faites et combien de temps vous le faites.
L’intégration de liens (Oneboxing) n’en fait pas partie, mais vous devez le dire s’il y a un tiers impliqué. Et les intégrations de liens ne sont que des liens sophistiqués.
Ce que je voulais dire, c’est que divulguer le fait que des tiers sont impliqués ne suffit pas. Conformément au RGPD, vous devez fournir :
le but de ce traitement de données
la base juridique de ce traitement
Nous ne pouvons pas utiliser le consentement, car Discourse ne permet pas d’afficher des images externes dans les liens intégrés uniquement pour les utilisateurs qui y ont consenti. Et l’intérêt légitime nécessite toujours l’intervention d’un avocat dans le processus pour mener correctement le test d’équilibre. Ce serait tellement plus simple si nous n’avions pas à le faire parce que le logiciel ne faisait pas envoyer de requêtes par le navigateur à des tiers (que nous ne pouvons même pas lister dans une politique de confidentialité, ni renvoyer aux politiques de confidentialité de ces tiers, car il peut s’agir de n’importe qui sur Internet).
Comme le montre le RGPD, ce ne sont pas que des liens, car ils sont consultés par le navigateur sans action de l’utilisateur.
(Au fait, je n’invente rien, je travaille dans la conformité RGPD dans ma vie professionnelle et j’ai une expérience pratique des plaintes et des amendes dans l’UE)
Mises à part les discussions juridiques, il y a des utilisateurs qui bloquent les ressources tierces spécifiquement dans le but de ne pas révéler leur IP et leurs habitudes de navigation à des tiers. Ce serait bien si les liens intégrés fonctionnaient pour eux
Mis à part les considérations juridiques, je pense qu’il serait utile de faire quelque chose dans ce domaine.
Cependant, j’ai tendance à dire que la solution consiste plutôt à demander à l’utilisateur une activation spécifique pour afficher des médias externes. Un certain nombre de sites Web allemands que je visite ont adopté la pratique de demander spécifiquement aux utilisateurs cela (exemple ci-dessous).
Je pense qu’en plus de cela, avoir des aperçus d’images statiques servis directement depuis l’hôte Discourse serait bien, mais j’ai tendance à dire que l’activation réelle est l’étape la plus importante.
Exemple (Golem.de, site d’actualités informatiques allemand) :
Je suis curieux à ce sujet. Je peux comprendre le problème de Google Font car il nécessite de récupérer la police du serveur de Google pour chaque utilisateur.
Cependant, dans mon expérience avec un « Onebox », l’aperçu du lien reste statique à moins de reconstruire le HTML. Ce que je veux dire par là. C’est que dans mon expérience, le onebox reste avec les mêmes informations d’aperçu même si la source change les informations sur la page.
Cela a été utile lorsqu’un site a radicalement modifié les informations de la page. Mon aperçu des informations du onebox est resté inchangé sans reconstruire le message via la clé à molette.
J’ai eu de vieux oneboxes qui sont restés intacts même si le site lié d’origine ne contenait même plus le contenu lié.
Les iframes, en revanche, je crois qu’ils se mettent à jour de la manière que vous avez identifiée, comme le mentionne @Jagster, comme un aperçu en direct lors de la visualisation par utilisateur, comme c’est le cas avec la récupération des polices Google.
Du moins, d’après ma compréhension. Je suppose que vous devriez également désactiver les intégrations, sinon ?
J’imagine qu’un plugin pourrait être créé pour ajouter une fonctionnalité comme celle ci-dessous.
Je comprends pourquoi mon ami allemand ici au Canada dit qu’il est préférable de bloquer l’UE.
Comme l’a dit @Firepup650 ci-dessus, ce n’est pas du tout le cas, car Discourse télécharge et sert automatiquement les images Onebox, ce qui est même un paramètre par défaut.
Vous pouvez même rendre cela plus strict en activant block hotlinked media.
Le problème venait de Google, qui n’a pas respecté le RGPD. C’est l’une des raisons pour lesquelles Google a reçu une amende assez conséquente de l’UE. Mais ce n’était pas un problème pour les sites qui utilisaient les polices Google, AdSense, etc. C’est pourquoi Google était en procès, pas ceux qui proposaient ces services.
Je comprends la frustration - beaucoup de choses que l’UE fait sont bien intentionnées, mais pas nécessairement bien mises en œuvre et compliquent souvent les choses pour les développeurs.
Dans ce cas précis, j’aime ce que les gens ont mis en œuvre, car cela donne un choix simple mais significatif à l’utilisateur.
Si cela peut être fait dans un plugin, tant mieux. J’ai supposé que cela devrait être fait dans le cœur car cela s’exécute sur toutes les oneboxes.
Les raisons ou les raisons imaginaires commencent à être hors sujet. Mais ces réglementations sont des points sensibles aux États-Unis. Et ces réglementations sont nécessaires car les giga-entreprises américaines n’ont pas du tout respecté la vie privée des utilisateurs, car il n’y a pas de réglementation aux États-Unis. Ou devrais-je dire maintenant… parce que la vie des développeurs n’est pas si compliquée
Alors, ne remerciez pas l’UE. Envoyez des cartes de remerciement à Google, Amazon, Microsoft, X, Apple, etc. Et en même temps, vous pouvez réfléchir à ce qu’ils ont en commun.
Au fait, j’ai reçu un message me disant de ne laisser entrer personne de moins de 13 ans sur mon forum. Je les laisserai certainement entrer, même de Californie, s’ils peuvent lire le finnois
Terminé (pourquoi n’y a-t-il pas d’emoji micro-drop…)
Je ne conteste pas la nécessité de réglementation - tout ce que je dis, c’est que le passage de « nous et nos 999 partenaires de confiance volerons vos données » à une grande fenêtre contextuelle disant « cliquez ici pour accepter que nous et nos 999 partenaires de confiance volerons vos données » ressemble parfois à une victoire à la Pyrrhus, et je peux comprendre pourquoi cela laisse certaines personnes perplexes
Mais pour en revenir au sujet principal : @kuba-orlik, si cela vous convient, je suggérerais de reformuler la demande de fonctionnalité en « Fournir une option pour exiger le consentement de l’utilisateur avant d’afficher des médias externes » (je voterais pour cela, alors).
Si vous estimez que le titre actuel correspond mieux à votre demande, c’est également acceptable. Dans ce cas, j’en ouvrirais probablement une autre moi-même.
Eh bien, cela va à des extrêmes fous. À moins que cela n’ait changé ou n’ait été déformé, je me souviens avoir lu qu’une entreprise pourrait devoir honorer une garantie sur, disons, du matériel que l’utilisateur final a endommagé en le démontant et en tentant de le réparer.
Le problème plus important est qu’il est allé à l’extrême pour protéger les gens de la pure stupidité.
D’après ce que je comprends, un plugin pourrait effectivement accomplir cela car il modifie des éléments du cœur côté serveur par opposition à un composant de thème qui modifie des choses côté client/navigateur ; les scripts Tampermonkey sont un peu comme des thèmes/composants installés côté navigateur. J’utilisais un script Tampermonkey sur un ancien jeu de navigateur appelé Fallen Sword pour modifier la façon dont il triait les articles sur le marché.
Note intéressante : je n’ai pas reçu de notifications pour ce sujet.
