J'ai forcé une réactualisation, et ça a fini par passer.
Un problème de cache (entre celui du navigateur et du service worker, c'est pas toujours évident ^^)
[edit] Par contre, maintenant, quand je clique sur un article avec des commentaires non lu, quand j'arrive sur l'article, ils sont tous lus
Le
08/02/2024 à
11h
09
On va regarder ça, merci beaucoup du signalement !
De rien, j'ai pas fait de ticket sur github car pas encore eu le temps de regarder pourquoi ça fait ça. Et je voudrais tester en navigation privée avant pour être sur que ce n'est pas une extension ou autre qui génère ce comportement.
Le
08/02/2024 à
10h
58
Alors je n'ai pas le souci d'affichage, mais j'ai un souci similaire sur les temps de réponse. Le site s'affiche assez rapidement, mais je ne peux rien faire avant quelques secondes, comme si il était bloqué (impossible de scroller ou de cliquer sur un lien par exemple).
Cela ne me le fait pas à chaque fois, mais assez régulièrement.
Le
02/02/2024 à
11h
07
A priori, plutôt un problème de l'extension. Avec le thème noir, aucun souci pour moi ;)
Le
01/02/2024 à
19h
45
Matomo n’a rien à voir avec Google. C’est un logiciel auto hebergé, équivalent à Google Analytics mais sans partage de données avec des tiers.
Tout à fait. Et Matomo est ancienne connu sous le nom de Piwik pour les plus curieux (le changement de nom à eu lieu en 2018).
Le
01/02/2024 à
19h
43
Je suis loin d’être un expert en matière de données personnelles et de dev web, mais voici ce que j’en comprends : - on n’utilise pas de cookie de traçage (vous avez un cookie de session mais c’est différent) - on obfusque une partie des IP - les informations qu’on a sur les visiteurs sont assez précises, et cela nous permettrait sans doute de faire du profilage assez pointu si on le voulait.
Maintenant, on n’utilise ces données que dans le strict cadre de l’exploitation du site, un compteur par pages n’en dirait pas assez pour bosser convenablement, autant ne rien avoir du tout presque, et cet hypothétique profilage nécessiterait un gros travail de dev, qu’il serait absurde de faire puisqu’il suffirait juste de changer deux réglages sur matomo pour tout avoir en clair. Et d’ailleurs, nous avons également des logs sur les différents services web qui eux retiennent les ips à des fins de diagnostic - sur une durée beaucoup plus courte, mais tout de même.
Pour conclure, en tant qu’hébergeur d’un site, nous avons la donnée, immanquablement, à un instant t. Si on decide d’en faire un usage proportionné et que les bonnes pratiques de conservation sont respectées, je pense que c’est un compromis nécessaire.
- les informations qu’on a sur les visiteurs sont assez précises, et cela nous permettrait sans doute de faire du profilage assez pointu si on le voulait.
Notamment, le guide de la CNIL précise qu'il faut désactiver le UserID, les mesures e-commerces ainsi que les cartes de chaleurs pour pouvoir être exempté de consentement. Le guide de la CNIL donne aussi les vérifications à faire pour s'assurer d'être "dans les clous" ;)
Dans les notices techniques on perçoit rarement l'émotion de l'auteur Mais je suis d'accord avec le reste !
L'émotion non, mais les habitudes des langues oui. Exemple avec le Danois, où la voix passive est fortement utilisée. Traduit littéralement, on aurait un truc du genre "une gélule doit être prise toutes les 2h". En Français, on dira simplement "prendre une gélule toutes les 2h".
C'est ça aussi le boulot d'un traducteur.
Le
09/02/2024 à
19h
55
Ca devait pas être agréable du tout cette relecture... 200 pages de contenu "traduit" par IA ça doit donner plus que la nausée.
J'espère pour elle que ça va s'arranger. On va finir par se rendre compte que l'IA est un outil, bien pratique, mais ne peut remplacer l'humain comme on le pense actuellement. Ca peut juste l'aider dans son travail. Surtout dans la traduction où le traducteur ou la traductrice (qui fait bien con boulot) va percevoir le sens profond de ce que transmet l'auteur, l'émotion, que l'IA sera incapable de transmettre en intégralité... si elle peut le faire en partie, ce qui finalement n'est pas souvent le cas.
Je te confirme qu'elle n'a pas vraiment apprécié. Mais bon, avec les baisses du nombre de missions, il faut bien vivre donc elle a accepté (elle est indépendante, donc pas de travail = pas d'argent)
On va finir par se rendre compte que l'IA est un outil, bien pratique, mais ne peut remplacer l'humain comme on le pense actuellement.
Je pense aussi. Sauf que cela va prendre un certains temps. Au moins quelques années à mon avis. Et le mal sera déjà fait.
Le
09/02/2024 à
19h
51
Le problème est qu'un LLM ne traduit pas, il réécrit. C'est une très grosse différence qu'on oublie rapidement.
Ce qui biaise l'idée aussi, c'est que Transformer vient à l'origine de Google Translate. Mais entre Transformer et GPT, y'a un monde.
Beaucoup des gens qui utilisent les LLM ne savent malheureusement pas comment ça fonctionne. Je ne parle pas de rentrer dans le détail (plutôt technique !) mais bien le principe.
Résultat : on fait un essai sur un ou deux exemples simples. Ca fonctionne, donc c'est validé. Et après... ben c'est la merde, mais les gens ne s'en rendent compte que bien tard... lorsqu'ils s'en rendent compte .
Le
09/02/2024 à
14h
20
Cela me rappelle un article que j'avais lu linuxfr, sur les dangers de l'utilisation de l'IA (et notamment des LLM) pour des traductions.
En gros, la traduction /résumé peut sembler tout à fait correct si on n'a pas lu le texte d'origine.
Je discutais pas plus tard qu'hier avec une amie traductrice, qui envisage de changer de métier, tant l'IA est utilisée aujourd'hui (on ne lui propose plus beaucoup de traduction en tant que telle, mais de la relecture/vérification, ce qui est encore moins bien payé tout en étant aussi difficile, voire plus). Et des notices de 200 pages traduites par IA, elle en a "bouffé" cet été.
Le
09/02/2024 à
14h
12
A écouter un podcast directement par conduction osseuse (ben quoi, on peut bien rêver non ^^)
Je ne dévie pas du sujet: FF sur PC Linux/Windows (sans doute idem sur les Mac) on peut passer outre et c'est ce genre de truc qui fait que j'y reste fidèle.
Android on ne peut plus car depuis qq années le about:config a été viré: Pb spécifique dont je parle depuis le départ mais pas de meilleur sourd...
Et les RFC n'ont jamais rien eu d'impératif, c'est à mon sens plus niveau pré-spécification mais tenant trop souvent lieu de spec "finale"... jamais écrite: Parfois bon dans un domaine évolutif, ceci dit, mais "amusant" de voir ceux qui veulent conserver de la souplesse en restant niveau "requête"... la refuser aux autres!
Android on ne peut plus car depuis qq années le about:config a été viré: Pb spécifique dont je parle depuis le départ mais pas de meilleur sourd...
Autre possibilité : tes propos manquent de précisions.
Et les RFC n'ont jamais rien eu d'impératif, c'est à mon sens plus niveau pré-spécification mais tenant trop souvent lieu de spec "finale"... jamais écrite: Parfois bon dans un domaine évolutif, ceci dit, mais "amusant" de voir ceux qui veulent conserver de la souplesse en restant niveau "requête"... la refuser aux autres!
C'est intéressant comme position, sachant que la très grande majorité des protocoles informatiques (pas que réseau) sont régis par... des RFC.
Maintenant, j'arrête ici. Entre ton ton condescendant et ta vision "étroite" (pour éviter de faire comme toi et de la qualifier de "débile"), il me semble bien difficile d'avoir une discussion constructive.
Bonne continuation à toi.
Le
08/02/2024 à
10h
56
Arf, Android n'a jamais été troué peut-être?! La situation est à mon sens bien pire que pour les PC malgré la liberté très contrôlée d'installer des trucs sur un appareil que l'on achète, faut-il le rappeler.
Celui qui va chercher une configuration bien cachée, mais ayant le mérite d'exister, est en mesure de juger les risques bien plus que celui qui va ouvrir les droits de son carnet d'adresse pour pouvoir installer une appli météo...
D'ailleurs pousser au tout appli qui pourraient être substitué à sans doute 80% des store Apple/Google par des versions mobiles des sites web derrière, utilisé de son navigateur préféré (et configurable!) est responsable de l'immense majorité du problème sécurité/vie privée des smartphones. Le gros du problème n'est pas les navigateurs et le concept typiquement américain de foolproof (= à l'épreuve des cons), si cela fonctionnait, cela se saurait: Tu peux retirer tes barrés et les ajouts en gras, les faits sont têtus.
Sinon, des gens qui gueulent dans le vide chez Mozilla pour la feature citée, ça dure depuis des années. Les pdm de FF prennent aussi leurs origines dans ce type de retrait débile de features ayant existé.
Arf, Android n'a jamais été troué peut-être?! La situation est à mon sens bien pire que pour les PC malgré la liberté très contrôlée d'installer des trucs sur un appareil que l'on achète, faut-il le rappeler.
On parle de Firefox et de HSTS, pas d'Android, des stores, etc. Merci de ne pas dévier et de faire du hors sujet.
Sinon, des gens qui gueulent dans le vide chez Mozilla pour la feature citée, ça dure depuis des années. Les pdm de FF prennent aussi leurs origines dans ce type de retrait débile de features ayant existé.
Et si tu arrêtais de juger les comportements/choix que tu n'approuves pas comme étant débile ? Quand tu as des utilisateurs, tu as des choix à faire. Certains utilisateurs approuveront, d'autres non. Mais ce n'est pas pour autant qu'il est débile.
Maintenant, et je le répète une fois encore, le blocage est IMPOSE par HSTS. Si le site n'avait pas activé HSTS, tu aurais la possibilité de continuer avec un message d'avertissement. Donc tu peux gueuler autant que tu veux sur Mozilla et ses choix pour Firefox, mais cela ne changera rien au fait qu'il respecte une norme de sécurité répandue et n'est absolument pas une décision débile.
Et si tu n'es pas content, change de navigateur, mais tu auras le même problème sur la majorité d'entre eux.
Le
08/02/2024 à
09h
02
Je pars surtout du principe qu'a force de tout vouloir rendre foolproof, cela amène à une situation type Android justement ou tout l'applicatif est bien bordé. Avec au final un truc qui emmerde les gens qui pèsent leurs choix sans protéger réellement les autres...
Je pars surtout du principe qu'a force de tout vouloir rendre foolproof, cela amène à une situation type Android justement ou tout l'applicatif est bien bordé. Avec au final un truc qui emmerde les gensune minorité de geeks qui pèsent leurs choix sans protéger réellementtout en protégeant les autres...
Sinon, au risque de me répéter : 1) tu peux quand même contourner (donc pourquoi tu te plains ?) 2) si tu veux te plaindre, c'est part ici (si tu veux que les choses avancent) => https://bugzilla.mozilla.org/index.cgi
Le
05/02/2024 à
16h
19
La banque j'avais dit plus haut ceci: "Bloquer mes choix éclairés avec des politiques de sécurité valables ici surtout pour ma banque ou si je résidais en Chine/Iran/Russie, par contre cela m’insupporte."
C'est juste une question de liberté de choix éclairée. Si on doit forker/maintenir tout ce qui ne le permet plus en raison de spécifications au curseur virant totalement foolproof (est-ce simplement réaliste?), ce n'est pas une option raisonnable.
Tu pars du principe que tout le monde agit comme toi et dispose des mêmes connaissances que toi. C'est loin d'être le cas et de très loin.
Maintenant, si vraiment ça t'insupporte, ce n'est pas ici que tu régleras ton problème, mais sur le bugtracker de Mozilla
Le
05/02/2024 à
15h
37
Pas vu l'annonce Github, mais FF sur PC et son about:config le "network.stricttransportsecurity.preloadlist" mis à false indiqué ci-dessus permet de valider une exception et nitter fonctionne actuellement alors sans problème. Et même mieux que d'habitude car peu chargé.
Et cela me parait assez bien planqué, avec un message clair quand le besoin est là, pour que les 99% que tu cites ne se mettent pas en danger.
Franchement, je m'en fiches un peu que qqun puisse théoriquement faire du MITM sur les qq comptes intéressants que je suis sans vouloir de compte chez Musk (in-fine un risque plus grand, de mon point de vue).
Je veux juste qu'on me laisse un choix qui a toujours été laissé! Si même FF ne permets plus cela sur toute plateforme en sucrant la page de configs planquées sur mobile, Mozilla ne va même pas conserver les geeks au final. Déjà que leur situation n'est pas fameuse...
C'est quand même, avec la richesse de configurations vie privée et autres (déjà sur mobile le fait que le glisser-haut ne ferme pas l'appli est pénible car cela rends inefficace les stratégies "vidage des poubelles" en quittant), un de leurs points forts auxquels sont attachés des utilisateurs dont je suis.
Sans cela, ils ne valent pas beaucoup mieux que les autres.
Franchement, je m'en fiches un peu que qqun puisse théoriquement faire du MITM sur les qq comptes intéressants que je suis sans vouloir de compte chez Musk (in-fine un risque plus grand, de mon point de vue).
HSTS ne se limite pas à Nitter. Ton côté geek sera bien content que ton navigateur t'envoie bouler si tu tentes d'accéder à ta banque et que tu es victime d'un MITM.
Je veux juste qu'on me laisse un choix qui a toujours été laissé!
Et Firefox (comme les autres navigateurs) en interdisant (pas simplement avertissant) suivent la spécification de HSTS. Si un navigateur autorise à outrepasser la connexion, alors il ne respecte pas HSTS. C'est pas un choix de (manque de) configuration, c'est le protocole qui veut ça. J'ai bien envie de dire de t'estimer heureux de pouvoir encore le faire en modifiant via about:config.
Alors entre un geek qui pleure (et qui représente 0,01% des utilisateurs) et les 99,99% autres qui sont protégés, le choix est vite fait.
[edit] Et si vraiment tu n'es pas content, j'ai une bonne nouvelle pour toi : Firefox est open-source. Tu peux donc le forker et rajouter ton option, plutôt que d'attendre que d'autres le fasse pour toi ;)
Le
05/02/2024 à
10h
28
97 avec Edge et 95 avec Firefox
J'aurais juste pensé que depuis le temps, les navigateurs auraient tous un score de 100 (ou 99) vu que le test à 15 ans maintenant.
En creusant un peu, il semblerait que les tests qui posent problèmes sont plus ou moins controversés et ne reflète pas (ou plus) le consensus de l'époque.
Le
05/02/2024 à
10h
11
Si tu as un moyen, du côté du client, de faire en sorte que le boulot côté serveur soit fait je suis impatient de le connaître? Comme il n'y en a pas, la possibilité de coller des exceptions réfléchies a toujours existé avant ce bidule de plus dans le grand cirque de la "sécurité" et c'était très bien ainsi.
Ce n'est pas au client de faire le boulot du serveur.
Il y aura un problème de configuration rendant le serveur non joignable, tu ferais quoi ? Tu patienterais. Le certificat n'est pas renouvelé ? Considère que le site est injoignable, et patiente. Point.
L'époque du "grand cirque" où on pouvait outrepasser les problèmes de certificats, on a connu. 99% des gens continuaient sans comprendre de quoi il en retournait, pour le plus grand plaisir des hackers. Tu sais peut être comment contourner le problème : très bien, fait le (en plus to donne la solution pour Firefox). Mais tout le monde n'a pas la connaissance que tu sembles avoir et la solution la plus sûre est de bloquer, purement et simplement, pour eux, pour les protéger d'une attaque.
Maintenant, sache aussi que le projet Nitter est mort. Annonce faite la semaine dernière par son mainteneur sur github, suite à la suppression par X des comptes invités. Et je pense que le véritable problème que tu rencontres vient de là. Même si le certificat est renouvelé, pas sur que tu puisses vraiment utiliser le site...
Le
05/02/2024 à
09h
17
Si Mozilla pouvait faire un Firefox Mobile à niveau avec la version PC, entre autres avec le about:config qui permet de parer aux débiles qui ont été pondre le HSTS (bloque la possibilité d'exceptions, sauf à toucher au "network.stricttransportsecurity.preloadlist") et font chier quand nitter se loupe sur le renouvellement de son Let's Encrypt.
Pourquoi tant de haine ? HSTS fait ce pour quoi il a été conçu. Nitter se loupe sur son renouvellement Let's Encrypt ? C'est la responsabilité de Nitter (de ne pas surveiller, de ne pas automatiser, d'avoir activé HSTS, ...), mais certainement pas la faute de ce protocole, qui a été conçu à des fins de sécurisation.
Tu remarqueras la présence du « généralement » à la fin de ma phrase 🤣 Dans 99.9999% des cas le DPO ne pourra de toute façon comparer avec rien du tout donc pièce inutile…
Je répondais sur l'aspect non-confirmité ;) La CNIL ne dit pas que la pièce d'identité n'est pas conforme. Elle dit que ce n'est pas une nécessite absolue et rappelle d'autres moyens à mettre en oeuvre avant d'en arriver là ;)
Le
07/02/2024 à
21h
04
La demande de communication d’une pièce d’identité est une non conformité RGPD généralement. C’est la CNIL qui le dit. Twitter
Elle résume d'ailleurs ce principe ainsi : "pas de pièce d’identité, sauf en cas de doute raisonnable."
On peut fournir un numéro de client, se connecter à son compte, utiliser l'adresse e-mail qui reçoit les communications, etc. pour prouver son identité et faire sa demande sans avoir besoin de fournir une pièce d'identité.
Maintenant, si un site qu'on ne connait ni d'Adam ni d'Eve dispose d'information nous concernant et qu'on souhaite procéder à l'exécution de ses droits, cela va dépendre de la demande : - pour une demande de suppression, j'ai presque envie de dire, pas de souci, pas besoin de carte d'identité (surtout quand il s'agit de publicité). - pour une demande d'accès, ça me parait légitime. Sinon, n'importe qui peut demander les informations de n'importe qui sans justification.
Je ne crois pas que ce soit si simple... * Parce que le système est ancien * Parce que le système est déjà interconnecté selon des modalités existantes, et donc que ce sont tous les autres systèmes qu'il faudra modifier aussi * Parce que l'interrogation d'individu pour obtenir un NIR n'est pas si simple que ce que tu proposes: entre le fait de devoir montrer patte blanche et le fait que le résultat n'est souvent pas unique pour juste nom et prénom
Tout à fait. Il faut rajouter également que l'usage du NIR est très réglementé, et qu'il peut changer au cours de la vie d'un individu (le changement de sexe étant une des raisons possible).
Il n'est pas possible de se baser uniquement sur le nom et prénom (homonymie). Il est impératif d'ajouter des traits d'identité supplémentaires, avec la date de naissance a minima (mais là encore, c'est insuffisant).
Pour donner un exemple, dans le domaine de la santé (où l'identito-vigilence est primordiale), la "nouvelle" identité actuellement poussée (INS) c'est : - le nom de naissance - le prénom de naissance - la date de naissance - le NIR - le code INSEE de la commune de naissance, au moment de la naissance du patient
Ça c'est la théorie. En pratique, ça a tendance à donner des immondices. Proc stock non versionnées (enfin.. maproc, maproc_v2, maproc_test_nico, ma-proc...), du code dégueulasse ou spaghetti, et des différences entre environnements de dev preprod/uat prod, et une grande difficulté à savoir quelles proc stock sont encore utilisées. Vu le niveau général de l'informatique (un métier de débutant, + une course effrénée à la rentabilité), miser sur cette approche c'est souvent une catastrophe.
Alors, ce que tu décris, ça n'a rien à voir avec l'usage de procédures stockées. On retrouve la même chose dans du code "classique".
On peut tout à fait versionner les modifications faites sur le schéma d'une BDD (et de manière totalement automatisé via des triggers sur les DDL).
C'est tout à fait possible, et assez simplement, de savoir les procédures stockées encore utilisées ou non, à la condition que le code appelant (java, C#, PHP, ...) soit lui aussi nettoyé. Pour ma part, je fais ça en plusieurs temps : - je récupère la liste des procédures stockées utilisées par le code - je récupère la liste des procédures stockées utilisées par des procédures stockées - je retire de la liste de l'ensemble des procédures stockées les 2 premières listes - et je purge au fur et à mesure les procédures restantes (je les renomme dans un premier temps avant de les supprimer, comme ça, si un cas d'utilisation m'a échappé, je peux la rétablir en un rien de temps).
L'énorme avantage que je vois d'utiliser la BD pour le métier c'est : - la cohérence des données, via les contraintes (FOREIGN KEY, CHECK, UNIQUE, ...) - la rapidité d'exécution relativement à la même chose côté code (faire 1 appel à une procédure stockée est bien plus rapide et sûr que x appels encapsulés par une transaction côté code, avec les aller/retour entre le code et le SGBD) - la facilité de faire des corrections en live
Mais après, c'est comme tout. Il faut une bonne discipline et de bonnes pratiques (mais ces problèmes là, on les retrouve indépendamment du langage choisi). La chose qui change vraiment si je puis dire, c'est qu'il faut passer d'un paradigme séquentiel à un paradigme ensembliste. Cela peut parfois être un peu déroutant au début.
Il n'y a pas aussi une histoire de réduction des risques et le professionnel doit archiver en sauvegarde froide, un dossier qu'il n'a plus besoin après un certains temps??
Le médecin doit conserver les données médicales jusqu'au décès du patient (voir quelques années après, je ne sais plus trop).
Le médecin doit conserver les données médicales jusqu'au décès du patient (voir quelques années après, je ne sais plus trop).
Ca dépend. Un médecin en cabinet n'a pas vraiment d'obligation, tandis que pour un établissement de santé, c'est 20 ans après le dernier passage du patient, ou 10 ans après son décès.
Je vois 2 possibilité (et pas forcément exclusive)
Soit c'est un organisme (au sens très très large) qui met de fausses données afin de faire réfléchir les "méchants pitits pirates" à deux fois avant d'acheter des données sur le darkweb. Cela peut être un bon moyen pour tenter de limiter un peu la propagation de vraies données.
Soit c'est un "méchant pitit pirate" qui a compris que ses "clients" n'allaient certainement pas porter plainte. Difficile en effet d'aller voir les forces de l'ordre et de leur dire, "voilà, j'ai voulu acheter une série de données volées sur le darkweb mais je me suis fait arnaqué".
Ne pas oublier que dans la technologie RFID, c'est le lecteur RFID qui sert à la fois d'émetteur et de récepteur et qui alimente la radio-étiquette (qui elle, est passive).
Donc quand on parle de quelques m de portée, c'est la porté pour que les émissions de la radio-étiquette soit 'réceptionable' par la partie réceptrice du lecteur.
La partie émettrice doit donc émettre à une puissance bien plus forte. Ce qui explique sans doute les interférences avec la bande GSM. A noter également que le lien de l'ANFR indique que la puissance max pour ce type de dispositif est de 4W soit du même ordre de grandeur que celle rayonnée par un téléphone (autour de 2W)
Je n'ai jamais parlé d’authentification mais bel et bien de ce dont mentionne: la détection des nouvelles connections depuis des adresses réputées inconnues.
Avec IPv4, ton arrivée sur leur serveur est assez constante niveau adresse alors que cette adresse change constamment en IPv6. Mais si tu ne retient que le préfixe 64 bits qui est LA NORME contrairement à ce que tu penses, là, c'est assez constant.
Donc, en IPv6, toute connexion à leurs service déclenche le fameux mail qui demande si c'est normal. D'où mon agacement.
Si la détection de nouveau lieu de connexion se faisait avec le préfixe IPv6 ou tout simplement avec l'ASN, cela éviterait ces messages tellement fréquents que le jour où un vrai piratage est tenté, on ne les lit plus.
Je n'ai jamais parlé d’authentification mais bel et bien de ce dont mentionne: la détection des nouvelles connections depuis des adresses réputées inconnues.
Merci pour la précision, car ce n'est pas ce que j'avais compris dans ton premier message ;)
Avec IPv4, ton arrivée sur leur serveur est assez constante niveau adresse alors que cette adresse change constamment en IPv6. Mais si tu ne retient que le préfixe 64 bits qui est LA NORME contrairement à ce que tu penses, là, c'est assez constant.
Et bien non. Désolé. . Il y a bien une histoire de 64 bits. Pour être précis, l'interface ID fait bien 64 bits. Le global routing prefix + subnet ID aussi du coup. Mais du coup, un prefix de 64 bits permet juste d'identifier l'adresse publique fourni par le FAI, et ne permet pas de détecter si 2 IP différentes dans le même préfix correspondent à deux machines différentes ou à une seule ayant changé d'adresse IP.
Il est donc tout à fait normal de recevoir une alerte pour toute connexion. Et cette alerte elle est aussi bien présente en IPv4 qu'en IPv6.
Tu trouves peut être ça "trop", car j'ai l'impression que chaque jour, tu te connectes (=authentifie) plusieurs fois. Ce n'est pas l'usage de la grande majorité des utilisateurs, qui se connecte une fois (=authentifie) et se reconnecte ensuite mais sans authentification (via une option style "se souvenir de moi").
Le
03/02/2024 à
22h
03
Je pense que tu as raison concernant l'impact des diverses protections contre le pistage et les cookies mais l'adresse IP, même quand c'est une IPv4 qui est partagée par plusieurs utilisateurs, est belle est bien utilisée par Google et par tous les autres services qui tracent la connexion de leurs utilisateurs.
La preuve en est que les messages envoyés par Google sont du type « une nouvelle connexion depuis un linux ... viens d'être réalisée. Si c'est bien vous, pas besoin de répondre à ce message ». Et dans le message de Google, il y a bien l'adresse IPv4 quand c'est celle-là qui est utilisée.
Ca dépend de ce que tu entends par "est utilisée". l'IP n'est pas utilisée à des fins d'authentification, mais de sécurisation lors d'une nouvelle connexion.
Le fait que Google ajoute l'information dans le mail n'est une preuve de rien, si ce n'est que l'information est transmise. C'est juste une information supplémentaire, au même titre que le navigateur, le système d'exploitation ou la date et l'heure pour permettre à l'utilisateur de dire savoir si c'est lui ou pas qui est à l'initiative de la connexion.
Si Google s'en servait à des fins d'authentification, alors changer d'IP ou de User Agent te déconnecterait. Ce qui n'est pas le cas en pratique. On n'a jamais vu non plus quelqu'un se retrouver automatiquement connecté aux services de Google car il a la même adresse IP qu'un autre utilisateur (et heureusement).
Pour une connexion établie, Google (et les autres) se fiche "généralement" de ton adresse IP (bien qu'elle soit tracée). Je dis généralement, car ils peuvent s'en servir pour détecter et bloquer des activités suspectes. C'est ainsi que Microsoft par exemple, a bloqué des tentatives de connexion sur mon compte, car les IP utilisées pour les nouvelles connexions étaient en dehors des adresses IP que j'utilise classiquement (adresse en Allemagne au lieu de la France) pendant que j'étais déjà connecté en France.
Mais à moins d'une activité véritablement suspecte (comme la connexion à 2 endroits séparés par des milliers de km en même temps ou une nouvelle connexion depuis un lieu inconnu), l'adresse IP ne sert pas si tu es déjà connecté.
Sauf que configurer un nat ne servira bientôt plus à rien quand les FAI seront tous derrière leur propre cgnat parce qu'ils ne peuvent plus donner d'ipv4 à tout le monde, juste une adresse partagée, mais pas en ipv6.
C'est un problème de FAI, pas de version de protocole IP. Tu peux avoir une adresse IPv4 ou IPv6 sans pouvoir configurer un serveur derrière (internet 4G chez certains opérateurs par exemple), car la notion d'IP fixe n'existe tout simplement pas dans ce cas, et que toutes les connexions entrantes sont bloquées par le FAI (rendant inutile tout usage éventuel d'un DNS dynamique pour palier le manque d'adresse IP fixe).
Le
03/02/2024 à
23h
08
Il existe, probablement, mais qui fonctionne ainsi ? IPV6 pourrait changer la donne, mais il faudrait encore lui rajouter des fonctions autour pour rendre la chose simple.
Pourquoi IPv6 changerait quoi que ce soit ? Installer un réseau domotique requiert un minimum de savoir faire. Une personne qui arrive à "domotiser" son habitation arrivera très certainement à configurer un NAT.
Après, pour savoir qui utilise ce genre de solution, c'est difficile à donner des info chiffrées, mais les communautés sont assez active.
Le
03/02/2024 à
22h
08
A ma connaissance, toutes les domotiques s'appuient sur le cloud pour le contrôle.
Non. Jeedom, Domoticz, Home Assitant, ... il existe de nombreuses solutions open-source auto-hébergables :)
Pour Jeedom (que j'ai chez moi), je peux le contrôler depuis mon tel si je suis chez moi, mais pas depuis l'extérieur (c'est configurable, il faut juste que j'ouvre des ports et configure le NAT, ce que je me refuse à faire).
Pour les autres solutions, je ne m'avancerai pas, faute de les connaitre en détail, mais cela ne m'étonnerait pas que cela soit possible.
@fred42@fdorin : oui mais il était possible sur du dns interne avec un tld public de produire des certificats via LE par ex même si ces (sous-)domaines n'étaient pas accessible en tant que tel sur internet. Donc même pour des ressources internes, on pouvait utiliser des certificats LE & co.
Avec le .internal, cela ne sera plus possible pour les raisons évoquées.
Certes, on peut déployer une PKI en interne (même si c'est un peu fastidieux) mais le confort apporté par LE & co va disparaitre avec le .internal. Pas un inconvénient insurmontable mais un inconvénient quand même :-)
Et la réponse "on est en interne, on peut se passer de certificats" n'est pas la bonne réponse ;-)
Je sais pas s'il fait de la pub pour lui ou un proche ou jusque parce qu'il connait le service ou qu'il cherche à partager une réponse au problème, mais il reste que le point qu'il soulève est juste...
oui mais il était possible sur du dns interne avec un tld public de produire des certificats via LE par ex même si ces (sous-)domaines n'étaient pas accessible en tant que tel sur internet.
Si il est effectivement possible via Let's encrypt de générer des certificats pour des domaines pas accessibles sur internet (mais des domaines existants et enregistrés), il faut malgré tout que le domaine t'appartienne. C'est pour ça que Let's encrypt ne pourra pas générer des certificats pour .internal, car .internal n'appartient à personne et qu'il ne sera pas possible de répondre aux challenges permettant de valider un certificat (ni challenge DNS, ni challenge HTTP)
Le
03/02/2024 à
19h
41
L'extension .local, bien que d'usage répandue, n'est, à ma connaissance, pas normalisé. Donc non, le 169.254 n'est pas associé à .local. Ca ne veut rien dire (d'autant plus que la norme précise bien que c'est un link-local et non un private-use network
Comme on peut le voir dans le lien de ce commentaire .local a été réservé par l'IETF afin qu'il ne soit pas un TLD. Il a fini par entériner le passage en force d'Apple.
Ah ben si, c'est normalisé. Lecture intéressante. Merci Le coup d'Apple est pas mal non plus et instructif.
En tout cas, ne pas utiliser .local pour un réseau local donc.
Le
03/02/2024 à
18h
43
Non, car les adresses 169.254.0.0/16 ne permettent pas de créer et gérer les réseaux, ni de donner un accès à internet. Tu ne pourras communiquer qu'avec les machines directement accessible (pas de routeurs, mais le switch doit passer).
Désolé mais ta réponse est à côté du sujet. Rappel du sujet: les noms dns et en sujet secondaire les plages d'adresses IP réservées pour les réseaux locaux. La plage 169.254.0.0/16 est bien réservée pour cet usage et c'est celle qui est associée à l'extension .local . a aucun moment je n'ai dis que cette plage était routable.
Avec les adresses de lien local 169.254.0.0/16 et fe80::/64 tu peut tout à fait créer et gérer un réseau même si effectivement ce réseau ne donnera aucun accès à Internet. Et si cela n'avait aucune utilité, les protocole bonjour et mdns n'existeraient pas.
Après, l'IPv4 est encore très fortement répandue et majoritaire, notamment dans les réseaux d'entreprises (IPv4 ne pose aucun souci en interne à une entreprise). Le seul problème vrai d'IPv4, c'est la pénurie d'adresse au niveau mondial, ce qui est sans impact pour les réseaux locaux d'entreprise.
IPv4 pose des soucis en entreprise mais les IT on l'habitude de faire avec. De la à dire qu'ils n'ont pas besoin d'IPv6, c'est juste de la résistance au changement et on sais tous que cela n'a rien de rationnel. IPv4 pose bien plus de problème que l'adressage et réduire le passage à IPv6 à une augmentation du nombre d'adresses est passer à côté de 99% des ajouts d'IPv6. C'est limite insultant pour ceux qui y ont travaillé.
Désolé mais ta réponse est à côté du sujet. Rappel du sujet: les noms dns et en sujet secondaire les plages d'adresses IP réservées pour les réseaux locaux.
Ben non, ce n'est pas à côté de la plaque. Une fois encore, tu sembles confondre réseau et lien local. Les adresses 169.254.0.0/16, c'est pour du lien local. Rien d'autre. C'est la norme (RFC 5735 section 4)
10.0.0.0/8 Private-Use Networks RFC 1918
169.254.0.0/16 Link Local RFC 3927
172.16.0.0/12 Private-Use Networks RFC 1918
192.168.0.0/16 Private-Use Networks RFC 1918
La plage 169.254.0.0/16 est bien réservée pour cet usage et c'est celle qui est associée à l'extension .local . a aucun moment je n'ai dis que cette plage était routable.
L'extension .local, bien que d'usage répandue, n'est, à ma connaissance, pas normalisé. Donc non, le 169.254 n'est pas associé à .local. Ca ne veut rien dire (d'autant plus que la norme précise bien que c'est un link-local et non un private-use network
Avec les adresses de lien local 169.254.0.0/16 et fe80::/64 tu peut tout à fait créer et gérer un réseau même si effectivement ce réseau ne donnera aucun accès à Internet. Et si cela n'avait aucune utilité, les protocole bonjour et mdns n'existeraient pas.
Encore une fois, non. Avec le 169.254 tu pourrais certes gérer un réseau (comme déjà dit dans un autre commentaire, même si je clouerais volontier le type qui ferait ça).
Par contre, c'est techniquement impossible en IPv6, puisque les routeurs ne doivent pas transmettre les paquets qui s'échangent sur un lien-local. Ci-dessous un extrait de la RFC 4291 section 2.5.6
Routers must not forward any packets with Link-Local source or destination addresses to other links.
IPv4 pose des soucis en entreprise mais les IT on l'habitude de faire avec. De la à dire qu'ils n'ont pas besoin d'IPv6, c'est juste de la résistance au changement et on sais tous que cela n'a rien de rationnel. IPv4 pose bien plus de problème que l'adressage et réduire le passage à IPv6 à une augmentation du nombre d'adresses est passer à côté de 99% des ajouts d'IPv6. C'est limite insultant pour ceux qui y ont travaillé.
Je te trouve bien agressif dans tes propos. L'IPv6 dispose effectivement d'avantage par rapport à l'IPv4, mais réduire le manque de déploiement à une simple résistance au changement c'est ne pas avoir compris les problématiques des entreprises. Les avantages de l'IPv6 sur l'IPv4 sur la QoS ou le routage par exemple ne sont que très rarement utile pour un réseau interne d'entreprise.
Le
03/02/2024 à
12h
49
Let's Encrypt ne fonctionnera pas sur du .internal puisque ce TLD n'est pas accessible depuis Internet. Ça m'étonnerait que les autres autorités de certifications émettent des certificats sur ce TLD puisqu'il n'appartient à personne ou à tout le monde ce qui revient au même.
À partir de là, il n'y a que les certificats locaux qui fonctionnent ou utiliser son propre nom de domaine en ayant une partie publique et une partie privée, mais c'est ce que veut éviter ce .internal.
J'ai l'impression que le monsieur qui a posté ce commentaire en profite pour faire de la pub à son service.
J'ai l'impression que le monsieur qui a posté ce commentaire en profite pour faire de la pub à son service.
Tout à fait. Surtout que s'il y a besoin d'établir des certificats pour du .internal, alors il suffit simplement de déployer son propre CA en interne.
Internal, c'est du "localhost" au niveau d'une entité (par exemple une entreprise). La même problématique se pose avec les certificats localhost. Soit du autosigné que l'on accepte, soit une CA maison.
Le
03/02/2024 à
00h
17
A la base, le système automatique apipa qui permet d'affecter une ipv4 169.254.0.0/16 ne fournit pas de passerelle par défaut à l'interface, mais un tyoe vicieux qui voudrait numéroter statiquement ou par un DHCP son réseau privé aussi, pourrait configurer des routes par défaut vers un routeur dans le même réseau, ça pourrait donc être une adresse privée tout pareil, genre extension rfc 1918, ce qui n'est pas le cas avec les adresses lien local (fe80::/10) de l'ipv6, déjà qu'on ne nate pas en principe.
Le même type pourrait aussi décider de router 127.0.0.0/16. La seule chose que mériterait un type faisant ça est le pilori, attaché et fouetté avec des câbles RJ45 !
Les adresses en 169.254.0.0/16 sont les liens locaux pour l'IPv4. C'est la norme. La différence avec l'IPv6, c'est que la norme IPv6 précise explicitement que les routeurs ne doivent pas transmettre le trafic des liens locaux.
Autrement dit, en IPv6, c'est techniquement impossible. En IPv4, c'est techniquement possible mais interdit par la norme. Si jamais je vois un réseau comme ça, je préfère encore demander à Numérobis de le refaire. Ce sera toujours mieux !
Le
02/02/2024 à
09h
08
J'ai même observé l'usage d'IP non privé pour des accès internes (99.77.55.33,...). Ça gère parfois de très grandes flotte d'appareils et ils se fichent des accès internet.
Pareil pour les DNS d'ailleurs. Si vous souhaitez utiliser .gouv.fr en interne ça posera aucun problème. Faut pas avoir besoin a des services externes sur ces extensions là et puis c'est tout.
Ou un cas plutôt connu aussi, où les box d'Orange considérait que 1.1.1.1 c'était une adresse en interne. Sauf que c'est une adresse qui existe bel et bien et est à CloudFlare je crois (notamment pour leur DNS).
Après, on peut bien évidemment utiliser n'importe quel adressage en interne, d'autant plus si le réseau n'est pas connecté à Internet. Mais comme la plupart le sont...
Maintenant, la norme prévoit des usages spécifiques pour certaines plages, et si on respecte la norme, la plage 169.254.0.0/16 n'est pas utilisable (et c'était là-dessus que je réagissais ;) ).
Le
02/02/2024 à
08h
40
Non, car les adresses 169.254.0.0/16 ne permettent pas de créer et gérer les réseaux, ni de donner un accès à internet. Tu ne pourras communiquer qu'avec les machines directement accessible (pas de routeurs, mais le switch doit passer).
Après, l'IPv4 est encore très fortement répandue et majoritaire, notamment dans les réseaux d'entreprises (IPv4 ne pose aucun souci en interne à une entreprise). Le seul problème vrai d'IPv4, c'est la pénurie d'adresse au niveau mondial, ce qui est sans impact pour les réseaux locaux d'entreprise.
Étonnamment, l'obligation de certification HDS ne concerne pas tous les traitements concernant des données de santé, mais uniquement les "données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de personnes physiques ou morales à l'origine de la production ou du recueil de ces données ou pour le compte du patient lui-même" (Article L1111-8 du CSP). Les deux conditions sont cumulatives et l'ensemble des activités manipulant des données de santé ne rentrent pas dans ce cadre.
Je ne connais pas bien l'ensemble des finalités du HDH, mais il ne rentre peut-être même pas dans ce cadre précis (à cause de la seconde condition).
Étonnamment oui et non. La certification HDS est à destination des hébergeurs. Un hôpital qui heberge en interne ses propres données n'a pas besoin d'avoir la certification HDS.
Un hôpital qui hébergerait des données d'autres structures devraient avoir la certification HDS. De même qu'un hôpital hébergeant ses données ailleurs (externalisation) devra prendre un hébergeur HDS.
Les obligations de certification telle qu'elle est aujourd'hui permet d'éviter que des médecins traitant par exemple, se retrouvent à avoir une certification HDS parce qu'ils ont sur leur poste des dossiers patients.
Le
02/02/2024 à
15h
08
De nombreux grands acteurs sont HDS maintenant, comparé a il y a encore 5 ans. Azure est HDS. De même qu'OVH (pour les hébergeurs grand public). Après, il en existe d'autres, dont c'est la spécialité depuis le début (Clara.Net, CEGEDIM, ...)
Le
01/02/2024 à
20h
40
Je ne peux qu'abonder dans ton sens. Je côtoie plus DSI d'hôpitaux, et si certains font du bon boulot, ce n'est pas le cas de tous. J'ai même eu un DSI qui me disait qu'il ne voyait pas pourquoi on chiffrait et que cela ne servait à rien...
Par contre, de mon côté, je note malgré tout une adoption en hausse de la MSS (Messagerie Sécurisée de Santé) auprès des professionnels de santé.
Et si les formats comme HL7 sont effectivement des formats en clair. Mais ce sont plus des formats d'échange que des formats de stockage, ils sont encapsulés dans des protocoles sécurisés (comme peut l'être HTTP par exemple).
Résumé: pour des contraintes de bande passante forte, avif c'est mieux et pour tout le reste, jxl. Donc si il ne devrait y avoir qu'un seul format utilisé, ça serait le jxl.
C'est justement ce genre de chose qui manque à l'article je trouve. Merci pour le lien !
Le format de fichier image AV1 Image File Format (AVIF) est un format ouvert de fichier image permettant de sauvegarder des images ou séquences d'images au format compressé avec le format AV1 HEIF. Il est développé par le consortium Alliance for Open Media. Il concurrence le format HEIC qui utilise le même format de conteneur, conçu à partir de ISOBMFF (en), mais HEVC pour la compression.
On y dit que AVIF est un AV1 HEIF. Donc du HEIF avec comme CODEC AV1. Du coup, c'est un cas particulier de HEIF. HEIC n'est pas décrit comme un codec, mais comme le "concurrent" de l'AVIF car est un HEVC HEIF.
Bref, du coup, avec tous ces acronymes dans tous les sens et qui se ressemblent, je suis largué :aie:
Le
02/02/2024 à
11h
51
Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp, qui me parait être le concurrent le plus direct (licence open-source, animation, avec / sans perte, ratio supérieur en général à ceux de JPEG, ...). On doit se contenter d'un léger "Il est également meilleur que le webp" en parlant de la compression.
Et le webp existe depuis 14 ans maintenant.
Et j'ai un sentiment mitigé, à la lecture de l'article, dont la première lecture me laisse un amalgame entre le format AVIF (qui est un conteneur si j'ai bien compris) et le format AV1 (qui est le codec). Parfois, j'ai l'impression que l'on parle des avantages de l'AVIF alors qu'en réalité, on parle des avantages du codec et inversement. Exemple :
Ce n’est justement pas le cas de l’AVIF, comme d’autres codecs open source, à l’instar de l’OpenH264, du Xvid ou du FLAC.
En matière de compression, le format AVIF fait à peu près jeu égal avec son concurrent direct, le HEIF
Cela n'enlève rien au fait que l'article est intéressant, mais du coup, ne connaissant pas l'AVIF, je suis perdu !
Que ce soit 541 ou 5.41, ça ne change pas grand-chose, en vrai…
Mais pendant ce temps, 10 ans après sa première « Technical Preview » et bientôt 9 ans après sa version 1 finale, Vivaldi devrait sortir sa version 6.6 (basée sur Chromium 122, canal LTS qui ne contient que les numéros de version pairs). Comme quoi, il reste des logiciels qui continuent à utiliser une numérotation classique (même si celle basée sur les dates a du sens, mais peut parfois donner des bizarreries comme certains logiciels ou paquets Linux qui, sortant aujourd’hui, se retrouveraient en version 20240202, pour 2 février 2024…).
Un truc qui n’est pas mentionné dans cette brève : on peut activer une surbrillance de toute les lignes et colonnes actives dans le tableur Calc, pour mieux repérer l’emplacement de la cellule active (c’est optionnel).
La situation était différente aussi. Firefox avait une part de marché importante à l'époque, qui s'effritait petit à petit face au monstre Chrome. Je pense que c'était aussi une tentative de renverser la tendance (avec le succès que l'on connait malheureusement aujourd'hui)
Le
02/02/2024 à
10h
24
Firefox a changé sa numérotation par le passé, pour se caler à un rythme plus ou moins équivalent à celui de Chrome, car beaucoup d'utilisateurs avait l'impression d'un manque de mise à jour, et préférait donc passer sur Chrome car plus souvent mis à jour donc plus "sécurisé"
2773 commentaires
Le poing Dev – Round 10
01/02/2024
Le 09/02/2024 à 20h 01
J'ai forcé une réactualisation, et ça a fini par passer.Un problème de cache (entre celui du navigateur et du service worker, c'est pas toujours évident ^^)
[edit]
Par contre, maintenant, quand je clique sur un article avec des commentaires non lu, quand j'arrive sur l'article, ils sont tous lus
Le 08/02/2024 à 11h 09
Le 08/02/2024 à 10h 58
Alors je n'ai pas le souci d'affichage, mais j'ai un souci similaire sur les temps de réponse. Le site s'affiche assez rapidement, mais je ne peux rien faire avant quelques secondes, comme si il était bloqué (impossible de scroller ou de cliquer sur un lien par exemple).Cela ne me le fait pas à chaque fois, mais assez régulièrement.
Le 02/02/2024 à 11h 07
A priori, plutôt un problème de l'extension. Avec le thème noir, aucun souci pour moi ;)Le 01/02/2024 à 19h 45
Le 01/02/2024 à 19h 43
Notamment, le guide de la CNIL précise qu'il faut désactiver le UserID, les mesures e-commerces ainsi que les cartes de chaleurs pour pouvoir être exempté de consentement. Le guide de la CNIL donne aussi les vérifications à faire pour s'assurer d'être "dans les clous" ;)
Autopsie de la vraie fausse attaque de trois millions de brosses à dents connectées
09/02/2024
Le 09/02/2024 à 19h 58
C'est ça aussi le boulot d'un traducteur.
Le 09/02/2024 à 19h 55
Je pense aussi. Sauf que cela va prendre un certains temps. Au moins quelques années à mon avis. Et le mal sera déjà fait.
Le 09/02/2024 à 19h 51
Résultat : on fait un essai sur un ou deux exemples simples. Ca fonctionne, donc c'est validé. Et après... ben c'est la merde, mais les gens ne s'en rendent compte que bien tard... lorsqu'ils s'en rendent compte
Le 09/02/2024 à 14h 20
Cela me rappelle un article que j'avais lu linuxfr, sur les dangers de l'utilisation de l'IA (et notamment des LLM) pour des traductions.En gros, la traduction /résumé peut sembler tout à fait correct si on n'a pas lu le texte d'origine.
Je discutais pas plus tard qu'hier avec une amie traductrice, qui envisage de changer de métier, tant l'IA est utilisée aujourd'hui (on ne lui propose plus beaucoup de traduction en tant que telle, mais de la relecture/vérification, ce qui est encore moins bien payé tout en étant aussi difficile, voire plus). Et des notices de 200 pages traduites par IA, elle en a "bouffé" cet été.
Le 09/02/2024 à 14h 12
A écouter un podcast directement par conduction osseuse (ben quoi, on peut bien rêver non ^^)Navigateurs : Interop 2024 se concentre sur la mise en page
05/02/2024
Le 08/02/2024 à 15h 02
C'est intéressant comme position, sachant que la très grande majorité des protocoles informatiques (pas que réseau) sont régis par... des RFC.
Maintenant, j'arrête ici. Entre ton ton condescendant et ta vision "étroite" (pour éviter de faire comme toi et de la qualifier de "débile"), il me semble bien difficile d'avoir une discussion constructive.
Bonne continuation à toi.
Le 08/02/2024 à 10h 56
Et si tu arrêtais de juger les comportements/choix que tu n'approuves pas comme étant débile ? Quand tu as des utilisateurs, tu as des choix à faire. Certains utilisateurs approuveront, d'autres non. Mais ce n'est pas pour autant qu'il est débile.
Maintenant, et je le répète une fois encore, le blocage est IMPOSE par HSTS. Si le site n'avait pas activé HSTS, tu aurais la possibilité de continuer avec un message d'avertissement. Donc tu peux gueuler autant que tu veux sur Mozilla et ses choix pour Firefox, mais cela ne changera rien au fait qu'il respecte une norme de sécurité répandue et n'est absolument pas une décision débile.
Et si tu n'es pas content, change de navigateur, mais tu auras le même problème sur la majorité d'entre eux.
Le 08/02/2024 à 09h 02
Sinon, au risque de me répéter :
1) tu peux quand même contourner (donc pourquoi tu te plains ?)
2) si tu veux te plaindre, c'est part ici (si tu veux que les choses avancent) => https://bugzilla.mozilla.org/index.cgi
Le 05/02/2024 à 16h 19
Maintenant, si vraiment ça t'insupporte, ce n'est pas ici que tu régleras ton problème, mais sur le bugtracker de Mozilla
Le 05/02/2024 à 15h 37
Et Firefox (comme les autres navigateurs) en interdisant (pas simplement avertissant) suivent la spécification de HSTS. Si un navigateur autorise à outrepasser la connexion, alors il ne respecte pas HSTS. C'est pas un choix de (manque de) configuration, c'est le protocole qui veut ça. J'ai bien envie de dire de t'estimer heureux de pouvoir encore le faire en modifiant via about:config.
Alors entre un geek qui pleure (et qui représente 0,01% des utilisateurs) et les 99,99% autres qui sont protégés, le choix est vite fait.
[edit] Et si vraiment tu n'es pas content, j'ai une bonne nouvelle pour toi : Firefox est open-source. Tu peux donc le forker et rajouter ton option, plutôt que d'attendre que d'autres le fasse pour toi ;)
Le 05/02/2024 à 10h 28
En creusant un peu, il semblerait que les tests qui posent problèmes sont plus ou moins controversés et ne reflète pas (ou plus) le consensus de l'époque.
Le 05/02/2024 à 10h 11
Il y aura un problème de configuration rendant le serveur non joignable, tu ferais quoi ? Tu patienterais. Le certificat n'est pas renouvelé ? Considère que le site est injoignable, et patiente. Point.
L'époque du "grand cirque" où on pouvait outrepasser les problèmes de certificats, on a connu. 99% des gens continuaient sans comprendre de quoi il en retournait, pour le plus grand plaisir des hackers. Tu sais peut être comment contourner le problème : très bien, fait le (en plus to donne la solution pour Firefox). Mais tout le monde n'a pas la connaissance que tu sembles avoir et la solution la plus sûre est de bloquer, purement et simplement, pour eux, pour les protéger d'une attaque.
Maintenant, sache aussi que le projet Nitter est mort. Annonce faite la semaine dernière par son mainteneur sur github, suite à la suppression par X des comptes invités. Et je pense que le véritable problème que tu rencontres vient de là. Même si le certificat est renouvelé, pas sur que tu puisses vraiment utiliser le site...
Le 05/02/2024 à 09h 17
Pourquoi tant de haine ? HSTS fait ce pour quoi il a été conçu. Nitter se loupe sur son renouvellement Let's Encrypt ? C'est la responsabilité de Nitter (de ne pas surveiller, de ne pas automatiser, d'avoir activé HSTS, ...), mais certainement pas la faute de ce protocole, qui a été conçu à des fins de sécurisation.Le 05/02/2024 à 08h 57
Cela me rappelle la bonne vieille époque des tests ACID :- épisode 1
- épisode 2
- épisode 3
A noter que mon Chrome n'a qu'un score de 97 au test Acid3
Deepfakes : des internautes utilisent l’IA générative pour « rhabiller » les femmes
08/02/2024
Le 08/02/2024 à 11h 00
+1000La CNIL accusée de ne pas remplir « sa mission de veiller au respect du RGPD »
06/02/2024
Le 08/02/2024 à 09h 04
Le 07/02/2024 à 21h 04
Elle résume d'ailleurs ce principe ainsi : "pas de pièce d’identité, sauf en cas de doute raisonnable."
On peut fournir un numéro de client, se connecter à son compte, utiliser l'adresse e-mail qui reçoit les communications, etc. pour prouver son identité et faire sa demande sans avoir besoin de fournir une pièce d'identité.
Maintenant, si un site qu'on ne connait ni d'Adam ni d'Eve dispose d'information nous concernant et qu'on souhaite procéder à l'exécution de ses droits, cela va dépendre de la demande :
- pour une demande de suppression, j'ai presque envie de dire, pas de souci, pas besoin de carte d'identité (surtout quand il s'agit de publicité).
- pour une demande d'accès, ça me parait légitime. Sinon, n'importe qui peut demander les informations de n'importe qui sans justification.
Des associations critiquent la création d’un fichier des personnes ayant changé de nom ou prénom
06/02/2024
Le 07/02/2024 à 16h 24
Il n'est pas possible de se baser uniquement sur le nom et prénom (homonymie). Il est impératif d'ajouter des traits d'identité supplémentaires, avec la date de naissance a minima (mais là encore, c'est insuffisant).
Pour donner un exemple, dans le domaine de la santé (où l'identito-vigilence est primordiale), la "nouvelle" identité actuellement poussée (INS) c'est :
- le nom de naissance
- le prénom de naissance
- la date de naissance
- le NIR
- le code INSEE de la commune de naissance, au moment de la naissance du patient
Le CNRS se demande où en est la « révolution quantique ? »
07/02/2024
Le 07/02/2024 à 15h 42
Il faut demander à Guerlain. Eux, ils sachent, avec leur Crème Nettoyante et Réjuvénante de la Science.[Maj] Parcoursup : six ans après, la promesse d’ouvrir le code n’est pas tenue, Ouvre-boîte « pas surprise »
06/02/2024
Le 07/02/2024 à 08h 53
On peut tout à fait versionner les modifications faites sur le schéma d'une BDD (et de manière totalement automatisé via des triggers sur les DDL).
C'est tout à fait possible, et assez simplement, de savoir les procédures stockées encore utilisées ou non, à la condition que le code appelant (java, C#, PHP, ...) soit lui aussi nettoyé. Pour ma part, je fais ça en plusieurs temps :
- je récupère la liste des procédures stockées utilisées par le code
- je récupère la liste des procédures stockées utilisées par des procédures stockées
- je retire de la liste de l'ensemble des procédures stockées les 2 premières listes
- et je purge au fur et à mesure les procédures restantes (je les renomme dans un premier temps avant de les supprimer, comme ça, si un cas d'utilisation m'a échappé, je peux la rétablir en un rien de temps).
L'énorme avantage que je vois d'utiliser la BD pour le métier c'est :
- la cohérence des données, via les contraintes (FOREIGN KEY, CHECK, UNIQUE, ...)
- la rapidité d'exécution relativement à la même chose côté code (faire 1 appel à une procédure stockée est bien plus rapide et sûr que x appels encapsulés par une transaction côté code, avec les aller/retour entre le code et le SGBD)
- la facilité de faire des corrections en live
Mais après, c'est comme tout. Il faut une bonne discipline et de bonnes pratiques (mais ces problèmes là, on les retrouve indépendamment du langage choisi). La chose qui change vraiment si je puis dire, c'est qu'il faut passer d'un paradigme séquentiel à un paradigme ensembliste. Cela peut parfois être un peu déroutant au début.
Fuite de données chez Almerys, un autre prestataire du tiers payant
06/02/2024
Le 06/02/2024 à 23h 33
Une fausse fuite de données chez Europcar, peut-être créée par une IA générative
06/02/2024
Le 06/02/2024 à 22h 49
Je vois 2 possibilité (et pas forcément exclusive)Soit c'est un organisme (au sens très très large) qui met de fausses données afin de faire réfléchir les "méchants pitits pirates" à deux fois avant d'acheter des données sur le darkweb. Cela peut être un bon moyen pour tenter de limiter un peu la propagation de vraies données.
Soit c'est un "méchant pitit pirate" qui a compris que ses "clients" n'allaient certainement pas porter plainte. Difficile en effet d'aller voir les forces de l'ordre et de leur dire, "voilà, j'ai voulu acheter une série de données volées sur le darkweb mais je me suis fait arnaqué".
Quand une borne RFID mal configurée brouille des communications
05/02/2024
Le 06/02/2024 à 10h 47
Justement, hors de portée de la BorneLe 05/02/2024 à 22h 43
Ne pas oublier que dans la technologie RFID, c'est le lecteur RFID qui sert à la fois d'émetteur et de récepteur et qui alimente la radio-étiquette (qui elle, est passive).Donc quand on parle de quelques m de portée, c'est la porté pour que les émissions de la radio-étiquette soit 'réceptionable' par la partie réceptrice du lecteur.
La partie émettrice doit donc émettre à une puissance bien plus forte. Ce qui explique sans doute les interférences avec la bande GSM. A noter également que le lien de l'ANFR indique que la puissance max pour ce type de dispositif est de 4W soit du même ordre de grandeur que celle rayonnée par un téléphone (autour de 2W)
[Édito] Mots de passe, double authentification : grrrrr… il est temps d’agir !
12/01/2024
Le 04/02/2024 à 20h 55
Et bien non. Désolé. . Il y a bien une histoire de 64 bits. Pour être précis, l'interface ID fait bien 64 bits. Le global routing prefix + subnet ID aussi du coup. Mais du coup, un prefix de 64 bits permet juste d'identifier l'adresse publique fourni par le FAI, et ne permet pas de détecter si 2 IP différentes dans le même préfix correspondent à deux machines différentes ou à une seule ayant changé d'adresse IP.
Il est donc tout à fait normal de recevoir une alerte pour toute connexion. Et cette alerte elle est aussi bien présente en IPv4 qu'en IPv6.
Tu trouves peut être ça "trop", car j'ai l'impression que chaque jour, tu te connectes (=authentifie) plusieurs fois. Ce n'est pas l'usage de la grande majorité des utilisateurs, qui se connecte une fois (=authentifie) et se reconnecte ensuite mais sans authentification (via une option style "se souvenir de moi").
Le 03/02/2024 à 22h 03
Le fait que Google ajoute l'information dans le mail n'est une preuve de rien, si ce n'est que l'information est transmise. C'est juste une information supplémentaire, au même titre que le navigateur, le système d'exploitation ou la date et l'heure pour permettre à l'utilisateur de dire savoir si c'est lui ou pas qui est à l'initiative de la connexion.
Si Google s'en servait à des fins d'authentification, alors changer d'IP ou de User Agent te déconnecterait. Ce qui n'est pas le cas en pratique. On n'a jamais vu non plus quelqu'un se retrouver automatiquement connecté aux services de Google car il a la même adresse IP qu'un autre utilisateur (et heureusement).
Pour une connexion établie, Google (et les autres) se fiche "généralement" de ton adresse IP (bien qu'elle soit tracée). Je dis généralement, car ils peuvent s'en servir pour détecter et bloquer des activités suspectes. C'est ainsi que Microsoft par exemple, a bloqué des tentatives de connexion sur mon compte, car les IP utilisées pour les nouvelles connexions étaient en dehors des adresses IP que j'utilise classiquement (adresse en Allemagne au lieu de la France) pendant que j'étais déjà connecté en France.
Mais à moins d'une activité véritablement suspecte (comme la connexion à 2 endroits séparés par des milliers de km en même temps ou une nouvelle connexion depuis un lieu inconnu), l'adresse IP ne sert pas si tu es déjà connecté.
[Édito] Il faut régler les problèmes de qualité de la fibre, et vite
02/02/2024
Le 03/02/2024 à 23h 53
Le 03/02/2024 à 23h 08
Après, pour savoir qui utilise ce genre de solution, c'est difficile à donner des info chiffrées, mais les communautés sont assez active.
Le 03/02/2024 à 22h 08
Pour Jeedom (que j'ai chez moi), je peux le contrôler depuis mon tel si je suis chez moi, mais pas depuis l'extérieur (c'est configurable, il faut juste que j'ouvre des ports et configure le NAT, ce que je me refuse à faire).
Pour les autres solutions, je ne m'avancerai pas, faute de les connaitre en détail, mais cela ne m'étonnerait pas que cela soit possible.
L’ICANN propose le domaine .internal pour votre réseau local
01/02/2024
Le 03/02/2024 à 20h 29
Le 03/02/2024 à 19h 41
En tout cas, ne pas utiliser .local pour un réseau local donc.
Le 03/02/2024 à 18h 43
L'extension .local, bien que d'usage répandue, n'est, à ma connaissance, pas normalisé. Donc non, le 169.254 n'est pas associé à .local. Ca ne veut rien dire (d'autant plus que la norme précise bien que c'est un link-local et non un private-use network
Encore une fois, non. Avec le 169.254 tu pourrais certes gérer un réseau (comme déjà dit dans un autre commentaire, même si je clouerais volontier le type qui ferait ça).
Par contre, c'est techniquement impossible en IPv6, puisque les routeurs ne doivent pas transmettre les paquets qui s'échangent sur un lien-local. Ci-dessous un extrait de la RFC 4291 section 2.5.6
Je te trouve bien agressif dans tes propos. L'IPv6 dispose effectivement d'avantage par rapport à l'IPv4, mais réduire le manque de déploiement à une simple résistance au changement c'est ne pas avoir compris les problématiques des entreprises. Les avantages de l'IPv6 sur l'IPv4 sur la QoS ou le routage par exemple ne sont que très rarement utile pour un réseau interne d'entreprise.
Le 03/02/2024 à 12h 49
Internal, c'est du "localhost" au niveau d'une entité (par exemple une entreprise). La même problématique se pose avec les certificats localhost. Soit du autosigné que l'on accepte, soit une CA maison.
Le 03/02/2024 à 00h 17
Les adresses en 169.254.0.0/16 sont les liens locaux pour l'IPv4. C'est la norme. La différence avec l'IPv6, c'est que la norme IPv6 précise explicitement que les routeurs ne doivent pas transmettre le trafic des liens locaux.
Autrement dit, en IPv6, c'est techniquement impossible. En IPv4, c'est techniquement possible mais interdit par la norme. Si jamais je vois un réseau comme ça, je préfère encore demander à Numérobis de le refaire. Ce sera toujours mieux !
Le 02/02/2024 à 09h 08
Après, on peut bien évidemment utiliser n'importe quel adressage en interne, d'autant plus si le réseau n'est pas connecté à Internet. Mais comme la plupart le sont...
Maintenant, la norme prévoit des usages spécifiques pour certaines plages, et si on respecte la norme, la plage 169.254.0.0/16 n'est pas utilisable (et c'était là-dessus que je réagissais ;) ).
Le 02/02/2024 à 08h 40
Non, car les adresses 169.254.0.0/16 ne permettent pas de créer et gérer les réseaux, ni de donner un accès à internet. Tu ne pourras communiquer qu'avec les machines directement accessible (pas de routeurs, mais le switch doit passer).Après, l'IPv4 est encore très fortement répandue et majoritaire, notamment dans les réseaux d'entreprises (IPv4 ne pose aucun souci en interne à une entreprise). Le seul problème vrai d'IPv4, c'est la pénurie d'adresse au niveau mondial, ce qui est sans impact pour les réseaux locaux d'entreprise.
« Ça va être sanglant » : la CNIL autorise les données de santé chez Microsoft
01/02/2024
Le 02/02/2024 à 21h 38
Un hôpital qui hébergerait des données d'autres structures devraient avoir la certification HDS. De même qu'un hôpital hébergeant ses données ailleurs (externalisation) devra prendre un hébergeur HDS.
Les obligations de certification telle qu'elle est aujourd'hui permet d'éviter que des médecins traitant par exemple, se retrouvent à avoir une certification HDS parce qu'ils ont sur leur poste des dossiers patients.
Le 02/02/2024 à 15h 08
De nombreux grands acteurs sont HDS maintenant, comparé a il y a encore 5 ans. Azure est HDS. De même qu'OVH (pour les hébergeurs grand public). Après, il en existe d'autres, dont c'est la spécialité depuis le début (Clara.Net, CEGEDIM, ...)Le 01/02/2024 à 20h 40
Je ne peux qu'abonder dans ton sens. Je côtoie plus DSI d'hôpitaux, et si certains font du bon boulot, ce n'est pas le cas de tous. J'ai même eu un DSI qui me disait qu'il ne voyait pas pourquoi on chiffrait et que cela ne servait à rien...Par contre, de mon côté, je note malgré tout une adoption en hausse de la MSS (Messagerie Sécurisée de Santé) auprès des professionnels de santé.
Et si les formats comme HL7 sont effectivement des formats en clair. Mais ce sont plus des formats d'échange que des formats de stockage, ils sont encapsulés dans des protocoles sécurisés (comme peut l'être HTTP par exemple).
L’AVIF prend enfin ses aises sur Internet : c’est quoi ce format d’image ?
02/02/2024
Le 02/02/2024 à 14h 04
Le 02/02/2024 à 11h 58
D'ailleurs, à la lecture du premier paragraphe sur WikipédiaOn y dit que AVIF est un AV1 HEIF. Donc du HEIF avec comme CODEC AV1. Du coup, c'est un cas particulier de HEIF. HEIC n'est pas décrit comme un codec, mais comme le "concurrent" de l'AVIF car est un HEVC HEIF.
Bref, du coup, avec tous ces acronymes dans tous les sens et qui se ressemblent, je suis largué :aie:
Le 02/02/2024 à 11h 51
Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp, qui me parait être le concurrent le plus direct (licence open-source, animation, avec / sans perte, ratio supérieur en général à ceux de JPEG, ...). On doit se contenter d'un léger "Il est également meilleur que le webp" en parlant de la compression.Et le webp existe depuis 14 ans maintenant.
Et j'ai un sentiment mitigé, à la lecture de l'article, dont la première lecture me laisse un amalgame entre le format AVIF (qui est un conteneur si j'ai bien compris) et le format AV1 (qui est le codec). Parfois, j'ai l'impression que l'on parle des avantages de l'AVIF alors qu'en réalité, on parle des avantages du codec et inversement. Exemple :
Cela n'enlève rien au fait que l'article est intéressant, mais du coup, ne connaissant pas l'AVIF, je suis perdu !
Après LibreOffice 7.6, la suite bureautique libre revient en version 24.2
02/02/2024
Le 02/02/2024 à 10h 48
Le 02/02/2024 à 10h 24
Firefox a changé sa numérotation par le passé, pour se caler à un rythme plus ou moins équivalent à celui de Chrome, car beaucoup d'utilisateurs avait l'impression d'un manque de mise à jour, et préférait donc passer sur Chrome car plus souvent mis à jour donc plus "sécurisé"