Comme d’habitude, un bon papier de @pixeldetracking sur la future véritable merde de tracking qui s’annonce après le tout aussi infâme CNAME cloacking de l’année dernière…
pixeldetracking.com/fr/google-

Il va sans dire qu’on a encore moins de possibilité de blocage que le CNAME cloaking qui n’en avait déjà pas beaucoup…
Là en l’état, considérez ce truc comme étant plus imblocable qu’autre chose… 🤷 😡

Vous voulez vous protéger de ce truc ? Installez µMatrix, en mode paranoïa. Désactivez a minima JS sur tout le contenu « tiers » y compris 1st party. C’est le domaine chargé qui peut faire du JS et c’est tout. Aucun sous-domaine. Bon courage avec votre navigation du coup… 😑

Et comme je ne doute pas un seul instant qu’un jour ils iront jusqu’à foutre le proxy sur une sous-URL du domaine principal, commencez déjà à hurler sur vos sites qui font du JS tout court en fait… 🤷

Parce que le jour où le proxy arrivera sur https://le-site-principal/{tracking-proxy}/ (sachant que la valeur peut être différente pour chaque appel en plus…), ça en deviendra littéralement imbloquable sans virer complètement JS de votre navigateur. Et encore.

Vu les « progrès » des trackers en l’état, disons qu’il nous reste quelques mois pour devoir virer JS complètement… 😭

@aeris sous prétexte que la terre est rempli de cons, on doit se passer de technos utiles ?

@sxpert Et en TLDR : je ne peux exercer mes libertés sur un outil qui ne me permet aucun contrôle à cause des (faux) besoins (débiles) des autres utilisateurs…

@aeris je suis pas sur que traiter les besoins des autres, qui ne sont manifestement pas aussi compétents dans le sujet que nous de “faux” et “débiles” ne va probablement pas aider a faire passer le message que je comprend parfaitement

@sxpert J’entend par faux et débile le résultat de l’analyse du besoin exprimé hein, pas a priori de l’expression du besoin.

@sxpert Et je pourrais résumer ça en un seul problème « mais pourquoi tu veux absolument faire ça en web bordel ! »

@sxpert Pourquoi est-ce qu’on a voulu faire des « applications web » quand on aurait du les faire en natif ? Pourquoi est-ce qu’on a absolument voulu faire webrtc quand on savait très bien le faire et en mieux en natif ?

@aeris @sxpert Alors, ça… Je me poserai toujours la question. D’ailleurs le plus grande énigme pour moi c'est Angular. Le truc pas bon du tout pour faire du web parce que ça balance 50 requêtes HTTP en parallèle à cause de son approche "composant". Mais pas aussi bon que Qt/QML pour coder des interfaces utilisateurs , si l’idée est de faire un client lourd.

@sxpert @charly Je pense que le problème vient du moment où on a considéré qu’on allait avoir un unique langage pour tout faire. Et en prenant le plus moisi qui n’ait jamais existé, JS.

@sxpert @charly On a du coup voulu tout faire avec, parce que tout le monde avait un navigateur sous la main. Et quand ça n’a plus suffit on a fait electron pour embarqué un nav dans une application…

@aeris @sxpert Mais en ce qui me concerne, le pire n’est pas que certains aient fait le choix de ce genre d’approche. Ce qui me révolte c’est la réaction des gens quand on essaie de leur faire comprendre que c’est une mauvaise approche :
- « Du moment que ça répond au besoin… »
- « C'est Google quand même… »
- « Tout le monde fait ça »
- « On ne m’a jamais remonté de problème pour le moment »
- « Le technologie, c’est fait pour évoluer »
etc.

@charly @sxpert Disons surtout qu’ils n’écoutent pas…
On prévient de la merde d’electron quasiment depuis sa sortie, en 2016 : twitter.com/aeris22/status/719

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!