Peut être géré par javascript qui va formater la date en heure locale, le site lui à juste à envoyer du UTC
Et c'est ce qui est fait. Mais le Javascript peut très bien renvoyer l'info au serveur aussi.
Il a besoin de la taille de ta fenêtre pour faire sa mise en page.
Si on a cette *@!]=#(% de css, c'est en partie pour ça
Je ne sais pas lequel des deux est apparu en premier. Et je pense que si on retirait Window.screen de l'API Javascript, les développeurs de trackers trouveraient bien un moyen d'extraire l'info à partir de css et je javascript tout de même.
Et je pense que c'est pareil pour les autres cas: ces infos doivent être accessibles d'une façon ou d'une autre (à part en effet pour le niveau de charge de batterie qui ne me semble pas indispensable, mais le besoin initial est tout de même compréhensible même s'il n'est pas acceptable).
Le vrai problème est que ces informations sont trop faciles à remonter au serveur. Chacune individuellement a été mise en place pour de bonnes raisons, mais sans suffisamment de considération pour les risques que ça pose pour le tracking, ou bien, les protections nécessaires n'ont pas pu être mises en place parque que la plateforme de base ne le permet pas (ça semble vraiment difficile de contrôler tout ça et à la fois d'autoriser le code Javascript a faire des requêtes dynamiques pour envoyer et recevoir tout et n'importe quoi).
Sûrement qu'une architecture pensée pour la vie privée dès le départ aurait, par exemple, complètement interdit au code Javascript de pouvoir déclencher tout accès au réseau, et limité fortement les possibilités d'envoyer des cookies et autres en-tête personnalisés. Le résultat serait bien différent de ce qu'on a aujourd'hui. Mais je pense que la seule solution pour y parvenir aujourd'hui ce serait de changer de plateforme, et par exemple utiliser quelque chose comme Gemini.
[^] # Re: Équipe de développement assez grande ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Librewolf, ce que Firefox devrait être.... Évalué à 3.
Et c'est ce qui est fait. Mais le Javascript peut très bien renvoyer l'info au serveur aussi.
Je ne sais pas lequel des deux est apparu en premier. Et je pense que si on retirait Window.screen de l'API Javascript, les développeurs de trackers trouveraient bien un moyen d'extraire l'info à partir de css et je javascript tout de même.
Et je pense que c'est pareil pour les autres cas: ces infos doivent être accessibles d'une façon ou d'une autre (à part en effet pour le niveau de charge de batterie qui ne me semble pas indispensable, mais le besoin initial est tout de même compréhensible même s'il n'est pas acceptable).
Le vrai problème est que ces informations sont trop faciles à remonter au serveur. Chacune individuellement a été mise en place pour de bonnes raisons, mais sans suffisamment de considération pour les risques que ça pose pour le tracking, ou bien, les protections nécessaires n'ont pas pu être mises en place parque que la plateforme de base ne le permet pas (ça semble vraiment difficile de contrôler tout ça et à la fois d'autoriser le code Javascript a faire des requêtes dynamiques pour envoyer et recevoir tout et n'importe quoi).
Sûrement qu'une architecture pensée pour la vie privée dès le départ aurait, par exemple, complètement interdit au code Javascript de pouvoir déclencher tout accès au réseau, et limité fortement les possibilités d'envoyer des cookies et autres en-tête personnalisés. Le résultat serait bien différent de ce qu'on a aujourd'hui. Mais je pense que la seule solution pour y parvenir aujourd'hui ce serait de changer de plateforme, et par exemple utiliser quelque chose comme Gemini.