Google a inventé une technologie appelée FLoC qui utilise le navigateur Chrome pour profiler les utilisateurs, car les cookies tiers semblent disparaître.
Cette technologie est fortement critiquée et un site web ou une application peut envoyer un en-tête Permissions-Policy: interest-cohort=() pour s’en désinscrire.
Nous estimons que la publicité reste une pierre angulaire importante du web en 2021, mais bien sûr, de nombreuses communautés y voient un problème majeur de confidentialité.
Le moyen le plus rapide de désinscrire votre installation Discourse de cette technologie est d’ajouter une balise meta dans la section /head d’un composant de thème : EDIT comme l’a souligné @supermathie, nous ne sommes pas sûrs que cela fonctionne.
Le désabonnement tant côté site web que côté utilisateur n’est pas un schéma viable pour introduire de nouvelles fonctionnalités de plateforme web.
En particulier, l’en-tête doit être envoyé à chaque requête, et vous devez également prendre en compte chaque URL CDN unique qui équivaudrait à une visite sur votre domaine de forum principal.
cdn.forum.example.com a exactement autant de pouvoir prédictif que forum.example.com.
Tous les changements à ce stade sont essentiellement motivés de manière aléatoire. Le fait que Google oblige l’ensemble du web à se débrouiller avec peu d’opportunités de recherche sur le mécanisme ou de visibilité sur les changements de politique ne favorise pas des décisions rationnelles.
Sommes-nous censés rester les bras croisés et ne rien faire pendant que Google fait cela ? Parce que Google le fait bel et bien, que cela nous plaise ou non. Que ce soit bien ou non.
Merci, j’ai fait quelques recherches : discussion pertinente ici et argument important (c’est moi qui souligne)
Je préférerais que nous ne fassions pas cela. Cela entraîne toutes sortes de conditions de course et vous obtiendrez également des fonctionnalités que vous ne pourrez désactiver qu’au niveau HTTP. Je préfère ne pas répéter le chaos que cela a créé avec CSP. Encourageons simplement tous les hébergeurs à fournir des options de configuration d’en-tête adéquates.
Bien que FLoC soit terrible, la suggestion sur WordPress ne semble pas parfaite non plus, car de nombreuses choses modifient les en-têtes. Comment prenez-vous tout cela en compte ?
La seule solution fiable pour le moment est d’utiliser n’importe quel navigateur autre que Chrome. L’utilisation d’instructions pour demander à Google de ne pas crawler ou suivre a montré qu’elle n’est pas toujours respectée, même lorsqu’elle est mise en œuvre conformément aux recommandations de Google.
Ainsi, dans l’univers de WordPress, un administrateur de site doit se tourner vers son hébergeur pour gérer ses en-têtes. (Édition : oups, voir ci-dessous pour une correction.)
Mais ici, dans l’univers de Discourse, nous disposons d’une image Docker qui configure tous les aspects de la présence web de notre site, y compris les en-têtes.
Je ne connais que ce qu’il faut pour être dangereux, mais je vois des paramètres d’en-têtes dans :
/var/discourse/shared/standalone/letsencrypt/http.header
/var/discourse/templates/web.ssl.template.yml
Il me semble donc que définir les en-têtes appropriés relève du champ d’action de Discourse, conformément à la politique de l’administrateur.
Certains administrateurs de Discourse pourraient ne pas souhaiter agir, d’autres pourraient préférer attendre et voir, et d’autres encore pourraient vouloir se désengager du suivi FLoC au nom de leurs communautés et envoyer un signal à Google.
Personnellement, je suis partisan de la suggestion faite par quelqu’un de rejeter purement et simplement les requêtes contenant l’en-tête FLOC, ce qui casserait Chrome. Mais je ne parviens pas à retrouver l’article que j’avais lu prônant cette idée…
Non — cette citation provenait d’une discussion générale sur l’en-tête Permissions-Policy. Dans le monde de WordPress, il existe un plugin qui ajoute cet en-tête.
## Toutes commandes personnalisées à exécuter après la construction
run:
- exec: echo "Début des commandes personnalisées"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /location \/ {/
to: |
location / {
add_header X-Clacks-Overhead "GNU Terry Pratchett";
add_header Permissions-Policy "interest-cohort=()";
Mise à jour de lobste.rs : Une fois la version bêta terminée, il n’y aura plus d’option pour exclure votre site des calculs.
Tous les sites avec des adresses IP accessibles publiquement que l’utilisateur visite en dehors du mode navigation privée seront inclus dans le calcul de la cohorte POC.
Ce « désabonnement » cessera de fonctionner dès que la phase de test sera terminée et, actuellement, il ne fonctionne que si vous diffusez des publicités.
Vous pouvez choisir de ne pas participer en tant qu’individu (pour l’instant).
À partir de Chrome 90 (version stable sortie le mardi 13 avril), les utilisateurs peuvent refuser FLoC et d’autres propositions du Privacy Sandbox via chrome://settings/privacySandbox. (Vous pouvez l’essayer dès maintenant dans Canary avec la démo floc.glitch.me.)
Cela m’a aussi pris un certain temps à comprendre, et je pense que j’ai maintenant compris (mais corrigez-moi si je me trompe). La confusion porte sur « les calculs ».
Il existe deux types de calculs ici, et trois façons pour un site de « participer » à FLoC.
L’algorithme « global » qui détermine les cohortes (globales). Le désengagement est impossible. En effetTous les sites ayant des adresses IP accessibles publiquement que l’utilisateur visite en dehors du mode navigation privée seront inclus dans le calcul de la cohorte POC.
L’algorithme qui détermine la cohorte pour un utilisateur spécifique, basé sur ses habitudes de navigation. Le désengagement se fait via un en-tête. Un site devrait pouvoir déclarer qu’il ne souhaite pas être inclus dans la liste des sites de l’utilisateur pour le calcul de la cohorte. Cela peut être réalisé via une nouvelle politique de permissionsinterest-cohort. (extrait du même document que votre citation)
Un site demandant la cohorte spécifique de l’utilisateur afin d’afficher une publicité ciblée (ou d’abuser de ces informations) en utilisant JavaScript. La valeur est rendue disponible aux sites web via une nouvelle API JavaScript :
cohort = await document.interestCohort();.
Cette API ne fonctionne pas sur les pages ayant opté pour le désengagement via l’en-tête mentionné au point #2, et c’est là que beaucoup de confusion a surgi. Toute frame qui n’a pas la permission interest-cohort recevra une valeur par défaut lorsqu’elle appellera document.interestCohort().
Ah — je confondais les points #2 et #3 de votre liste.
Dans ce cas, l’en-tête a une certaine valeur, bien que les en-têtes restent une méthode médiocre et sujette aux erreurs pour transmettre cette information.
