2- Google ne pousse personne à l’utiliser. Ils ont créé une spec, diverses personnes se sont penchées sur la RFC ça a évolué et pouf ça a été normalisé. Google pousse son implémentation dans son logiciel. Après, ils ne forcent la main sur personne pour l’implémenter dans les autres logiciels (clients ou serveurs). Si des devs voient l’intéret de l’implémenter dans leur logiciel, libre à eux de le faire. Si c’est effectivement le cas, c’est que les devs y ont vu un intéret. Personne n’a été forcé/menacé dans l’histoire.
3- Les RFC ne sont pas jetés s’il n’y a pas de majs régulières. Certaines mettent des années avant d’être validées, d’autres le sont bien plus rapidement mais elles ne sont pas jetées s’il n’y a pas de maj. C’est même plutôt l’inverse. Quand il n’y a pas de maj pendant un moment et quelle a été discutée, la RFC aura plutôt tendance à sortir de brouillon et d’être officialisée. Donc pousser des majs régulières a plutôt tendance à retarder le processus.
Ça montre l’historique du dépôt du brouillon initial en 2015, sa filiation avec le brouillon de HTTP/3, et la ratification en 2021. Comme je le dis dans mon article, je présente des faits vérifiables (comme cet historique), mais c’est moi qui fait les liens. Libre à chacun d’en penser ce qu’il veut, pour ma part je trouve qu’il y a matière à soupçonner Google (entreprise privée) d’avoir forcer les choses concernant un outil public en copinant avec une organisation à but non lucratif.
Non, je reproche à Google d’avoir insisté pour que son propre outil devienne un standard du web, jusqu’à trouver quelqu’un à l’IETF qui accepte de le ratifier, comme ils l’ont fait avec le W3C (voir point 4 ci-dessous).
Justement, c’est la régularité de MàJ qui me pose problème parce qu’elle correspond plus ou moins avec le délais au-delà duquel l’IETF considère un draft comme étant obsolète.
Google a rejoint le WHATWG en 2017. Deux ans après une soi-disant collaboration entre le W3C et le WHATWG, le W3C abandonne la spec de HTML et de DOM au WHATWG. Chrome a le monopole des navigateurs web. Certes, juridiquement parlant, Google n’a pas pris le contrôle du W3C, mais l’entreprise fait désormais partie de ceux qui décident de l’avenir de deux des technologies les plus importantes du monde informatique à l’heure actuelle. Et qu’on ne vienne pas me faire croire qu’ils font ça par charité ou pour faire un meilleur web, l’intention initiale de Tim Berners Lee et du W3C. Le WHATWG est un regroupement d’acteurs privés, les décisions sont entre leurs mains (comme précisé dans ce document). Je doute que la communauté (les développeurs, les utilisateurs, bref les petites gens) ait véritablement leur mot à dire. Sinon ça fait depuis longtemps qu’on n’aurait plus de vendor-specific.
1- ça montre quoi ? Dans la RFC HTTP n’y est quasiment pas abordé. QUIC est à peu près indépendant de ce qu’il transporte. C’est utilisé pour du HTTP mais on commence à voir également des softs qui l’utilise pour autre chose notamment SSH, DNS et même des jeux vidéo. Tu peux utiliser QUIC sans HTTP3.
2- Donc tu reproches à Google d’implémenter une RFC ? Ça marche pour 100% de l’Internet ce reproche.
3- Mouai. J’ai pas spécialement d’avis là-dessus cela dit, en survolant vite fait le datatracker de la 9000, on voit que le nombre de révision est assez régulier dans le temps et que sans trop de surprise, plus ça avance moins les modifs sont importantes donc je suis pas vraiment convaincu de l’argument.
4- Alors non Google n’a pas pris possession du W3C par contre c’est le WHATWG qui a pris le dessus sur le W3C. Et à sa fondation, bha … Google n’en faisait pas parti.
(c’est fou on va croire que je défend Google mais c’est clairement pas une boîte que j’affectionne hein, mais faut pas non plus déformer l’histoire).
je ne vois pas une manoeuvre de Google mais Google qui comprend vite comment utiliser une techno pour leurs propres desseins.
c’est pourtant intéressant de voir que les choses sont allées très vite dès lors que Lars Eggert, ayant bossé dans la Task Force consacrée à QUIC, a pris la tête de l’IETF en 2021
non, évidemment, mais ça prouve bien que Google a poussé au cul l’IETF, et quand on voit comment ils ont pris possession du W3C, on ne peut que s’inquiéter devant une telle agressivité
Il semblerait que sur les routeurs domestiques ce ne soit pas une DMZ, mais un hôte DMZ. L’hôte DMZ aurait tous ses ports UDP/TCP ouverts et exposés. Le rôle de cet hôte serait hypothétiquement d’agir comme une DMZ. Il s’agirait en réalité d’un hôte du réseau local exposé sur l’Internet. Sauf que ce n’est pas ce à quoi je m’attendais. La documentation des Livebox est déplorable.
What is DMZ and DMZ Host and their Difference
A true DMZ is basically a section of your network that is exposed to the internet but do not connect to the rest of your internal network. However, most of the home routers offer DMZ setting or DMZ host settings. These settings allow you to just expose one computer or one device to the internet.
The problem is that this specific computer can still talk to the rest of your internal network. This means that if the “DMZ host” has been broken into and infected with computer virus or internet malware, it may affect the rest of the devices on your home network.
Donc, sans m’en rendre à compte, à cause de cette dénomination trompeuse, j’avais ouvert une grosse faille dans mon réseau domestique, en obtenant l’effet exactement inverse à celui recherché.
Édition : Tout cela est encore flou dans mon esprit.
QUIC n’est pas spécifique au web. C’est un protocole de transport qui peut bouger n’importe quoi à vrai dire même si ça a été en grande partie pensé pour le web. Donc non cette histoire de brouillon qui a été renouvellé plusieurs fois pour se transformer en http3 c’est juste faux. la RFC de QUIC est indépendante de la RFC de HTTP3.
Concernant DoH : là aussi tu vois une manœuvre de Google mais derrière c’est l’ICANN et Mozilla donc là pour le coup ils n’y sont pour rien. Par contre ils l’ont vite adopter sur Chrome et Android c’est vrai. Comme tu dis, pour eux c’est un moyen d’éviter le blocage des pubs par DNS traditionnel.
Pas besoin d’être pote avec quelqu’un à l’IETF pour publier une RFC. C’est absolument ouvert à tous. Là encore il n’y a pas conspiration de la part de Google pour publier une RFC.
Si un brouillon de l’IETF expire rien n’empêche d’en reposter un autre quasi identique.
La préface du livre « Flask Web Development, de Miguel Grinberg, ISBN 978-1-491-99173-2 » déclare en anglais : Modern Web applications cannot avoid the use of HTML, CSS and JavaScript.
Admettre que le choix se porte entre JavaScript ou Python en développement Web est tendancieux. Non, il faut dire s’il s’agit d’un développement d’application dorsale (back-end), frontale (front-end) ou intégrale (full-stack). D’autant plus que la comparaison entre Python et JavaScript qui est faite dans l’article, c’est du vent.
Le bouton “refuser” ne devrait pas être plus difficile à trouver que le “accepter”.
Ce deuxième screen en revanche est beaucoup plus intéressant justement.
Merci pour la réponse.
Je pense par contre qu’il serait intéressant que l’article soit mis à jour avec cette capture d’écran (ou les 2 à la limite).
Si Google Search se transforme définitivement en Google Reply, cela pourrait laisser une petite place pour des moteurs de recherche conventionnels qui fournissent des liens vers des site web, des blogs, des fichiers pdf, des cours, ….
Le lectorat n’étant pas le même.
Je cherche à comprendre le concept de DMZ. L’objectif est d’avoir un serveur Web dans un réseau domestique mais accessible publiquement sur l’Internet. Je débute en réseautique donc je ne comprends pas vraiment les choses. Je ne sais pas ce qu’est une interface réseau (cela me semble trop compliqué à appréhender dans l’instant) ou un sous-réseau. Donc, par sécurité, j’ai tout annulé. Avant, j’avais intégré le serveur Web fonctionnant grâce au SE YunoHost dans la DMZ créée par la Livebox Orange. Le problème est que la documentation en ligne de Orange est inopérante (ou ineffective). En la lisant, on entre en pleine confusion.
Sécurisation
Le niveau de pare-feu de votre Livebox Pro doit être configuré sur Minimum ou Faible pour utiliser une DMZ.
De même, vous devez absolument protéger l’ordinateur mis dans la DMZ par un pare-feu efficace.
Je ne comprends pas pourquoi Orange incite à désactiver le pare-feu de la Livebox afin de créer une DMZ. Orange renvoie vers la configuration de Livebox professionnel pour réseaux d’entreprises mais on peut également créer une DMZ sur une Livebox domestique.
En essayant de rester cohérent, il m’aurait semblé que le pare-feu aurait pu définir des règles différenciées entre chaque « zone » : la DMZ et le réseau local, la DMZ et l’Internet, l’Internet et le réseau local.
Livebox Pro V4 : modifier ou désactiver le pare-feu
Le firewall de votre Livebox Pro V4 contrôle les échanges de données entre votre réseau local et internet. Il assure ainsi la sécurité globale de vos équipements. Voici la marche à suivre si vous souhaitez le désactiver pour des besoins spécifiques (exemple : créer une DMZ).
Vous devez vous assurer que tous les ordinateurs raccordés à votre Livebox sont protégés par un pare-feu et un antivirus actifs. En effet, la désactivation n’est pas sans risque.
Dans mes souvenirs, je n’avais pas eu à modifier le niveau de sécurité du pare-feu de la Livebox domestique pour créer une DMZ. Mais on peut établir une configuration personnalisée en définissant des règles de filtrage.
Sur certains forums, des gens préconisaient des redirections de ports en déconseillant fortement d’employer la DMZ de la Livebox Orange.
Je suis totalement perdu. Le pare-feu de la Livebox 5 semble être un pare-feu applicatif, pour le reste je n’y comprends rien.
Les versions intermédiaires d’Ubuntu sont maintenues pendant seulement 6 mois et prennent les paquets dans Debian testing / unstable sans même se préoccuper des bogues et de leur résolution. Pour moi c’est de la version bêta inutilisable sur une machine de travail. Le bogue en question avait été corrigé chez Debian un mois avant la sortie d’Ubuntu 23.04 et signalé encore bien avant.
La 23.04 n’est certes pas une version LTS mais ce n’est en rien une beta. Et le sujet de l’article est juste une solution de contournement pour ceux qui sont sur cette version et qui ont besoin de leur imprimante. :)
On n’est pas assez informé des dérives en tout genre. Le vidéaste anti-cyber-escrocs Sandoz réalise un travail extra…ordinaire en luttant contre ces gens malveillants et sans foi. On est aussi devancé de très loin par le progrès technologique (voir la vidéo de Micode « J’ai infiltré un réseau d’arnaqueurs au SMS »).
2- Google ne pousse personne à l’utiliser. Ils ont créé une spec, diverses personnes se sont penchées sur la RFC ça a évolué et pouf ça a été normalisé. Google pousse son implémentation dans son logiciel. Après, ils ne forcent la main sur personne pour l’implémenter dans les autres logiciels (clients ou serveurs). Si des devs voient l’intéret de l’implémenter dans leur logiciel, libre à eux de le faire. Si c’est effectivement le cas, c’est que les devs y ont vu un intéret. Personne n’a été forcé/menacé dans l’histoire.
3- Les RFC ne sont pas jetés s’il n’y a pas de majs régulières. Certaines mettent des années avant d’être validées, d’autres le sont bien plus rapidement mais elles ne sont pas jetées s’il n’y a pas de maj. C’est même plutôt l’inverse. Quand il n’y a pas de maj pendant un moment et quelle a été discutée, la RFC aura plutôt tendance à sortir de brouillon et d’être officialisée. Donc pousser des majs régulières a plutôt tendance à retarder le processus.
Ça montre l’historique du dépôt du brouillon initial en 2015, sa filiation avec le brouillon de HTTP/3, et la ratification en 2021. Comme je le dis dans mon article, je présente des faits vérifiables (comme cet historique), mais c’est moi qui fait les liens. Libre à chacun d’en penser ce qu’il veut, pour ma part je trouve qu’il y a matière à soupçonner Google (entreprise privée) d’avoir forcer les choses concernant un outil public en copinant avec une organisation à but non lucratif.
Non, je reproche à Google d’avoir insisté pour que son propre outil devienne un standard du web, jusqu’à trouver quelqu’un à l’IETF qui accepte de le ratifier, comme ils l’ont fait avec le W3C (voir point 4 ci-dessous).
Justement, c’est la régularité de MàJ qui me pose problème parce qu’elle correspond plus ou moins avec le délais au-delà duquel l’IETF considère un draft comme étant obsolète.
Google a rejoint le WHATWG en 2017. Deux ans après une soi-disant collaboration entre le W3C et le WHATWG, le W3C abandonne la spec de HTML et de DOM au WHATWG. Chrome a le monopole des navigateurs web. Certes, juridiquement parlant, Google n’a pas pris le contrôle du W3C, mais l’entreprise fait désormais partie de ceux qui décident de l’avenir de deux des technologies les plus importantes du monde informatique à l’heure actuelle. Et qu’on ne vienne pas me faire croire qu’ils font ça par charité ou pour faire un meilleur web, l’intention initiale de Tim Berners Lee et du W3C. Le WHATWG est un regroupement d’acteurs privés, les décisions sont entre leurs mains (comme précisé dans ce document). Je doute que la communauté (les développeurs, les utilisateurs, bref les petites gens) ait véritablement leur mot à dire. Sinon ça fait depuis longtemps qu’on n’aurait plus de vendor-specific.
1- ça montre quoi ? Dans la RFC HTTP n’y est quasiment pas abordé. QUIC est à peu près indépendant de ce qu’il transporte. C’est utilisé pour du HTTP mais on commence à voir également des softs qui l’utilise pour autre chose notamment SSH, DNS et même des jeux vidéo. Tu peux utiliser QUIC sans HTTP3.
2- Donc tu reproches à Google d’implémenter une RFC ? Ça marche pour 100% de l’Internet ce reproche.
3- Mouai. J’ai pas spécialement d’avis là-dessus cela dit, en survolant vite fait le datatracker de la 9000, on voit que le nombre de révision est assez régulier dans le temps et que sans trop de surprise, plus ça avance moins les modifs sont importantes donc je suis pas vraiment convaincu de l’argument.
4- Alors non Google n’a pas pris possession du W3C par contre c’est le WHATWG qui a pris le dessus sur le W3C. Et à sa fondation, bha … Google n’en faisait pas parti.
(c’est fou on va croire que je défend Google mais c’est clairement pas une boîte que j’affectionne hein, mais faut pas non plus déformer l’histoire).
Il semblerait que sur les routeurs domestiques ce ne soit pas une DMZ, mais un hôte DMZ. L’hôte DMZ aurait tous ses ports UDP/TCP ouverts et exposés. Le rôle de cet hôte serait hypothétiquement d’agir comme une DMZ. Il s’agirait en réalité d’un hôte du réseau local exposé sur l’Internet. Sauf que ce n’est pas ce à quoi je m’attendais. La documentation des Livebox est déplorable.
Donc, sans m’en rendre à compte, à cause de cette dénomination trompeuse, j’avais ouvert une grosse faille dans mon réseau domestique, en obtenant l’effet exactement inverse à celui recherché.
Édition : Tout cela est encore flou dans mon esprit.
Hmmm quelques remarques qui me viennent :
QUIC n’est pas spécifique au web. C’est un protocole de transport qui peut bouger n’importe quoi à vrai dire même si ça a été en grande partie pensé pour le web. Donc non cette histoire de brouillon qui a été renouvellé plusieurs fois pour se transformer en http3 c’est juste faux. la RFC de QUIC est indépendante de la RFC de HTTP3.
Concernant DoH : là aussi tu vois une manœuvre de Google mais derrière c’est l’ICANN et Mozilla donc là pour le coup ils n’y sont pour rien. Par contre ils l’ont vite adopter sur Chrome et Android c’est vrai. Comme tu dis, pour eux c’est un moyen d’éviter le blocage des pubs par DNS traditionnel.
Pas besoin d’être pote avec quelqu’un à l’IETF pour publier une RFC. C’est absolument ouvert à tous. Là encore il n’y a pas conspiration de la part de Google pour publier une RFC.
Si un brouillon de l’IETF expire rien n’empêche d’en reposter un autre quasi identique.
La préface du livre « Flask Web Development, de Miguel Grinberg, ISBN 978-1-491-99173-2 » déclare en anglais : Modern Web applications cannot avoid the use of HTML, CSS and JavaScript.
Admettre que le choix se porte entre JavaScript ou Python en développement Web est tendancieux. Non, il faut dire s’il s’agit d’un développement d’application dorsale (back-end), frontale (front-end) ou intégrale (full-stack). D’autant plus que la comparaison entre Python et JavaScript qui est faite dans l’article, c’est du vent.
https://www.cnil.fr/fr/refuser-cookies-doit-etre-aussi-simple-accepter-cnil-poursuit-action-adresse-mises-en-demeure
Le bouton “refuser” ne devrait pas être plus difficile à trouver que le “accepter”. Ce deuxième screen en revanche est beaucoup plus intéressant justement.
Merci pour la réponse. Je pense par contre qu’il serait intéressant que l’article soit mis à jour avec cette capture d’écran (ou les 2 à la limite).
Si Google Search se transforme définitivement en Google Reply, cela pourrait laisser une petite place pour des moteurs de recherche conventionnels qui fournissent des liens vers des site web, des blogs, des fichiers pdf, des cours, …. Le lectorat n’étant pas le même.
Yo ! Pour le coup ce n’est pas la configuration par défaut. J’ai réutilisé le code que j’avais fait pour un client qui voulait un cookie wall un peu agressif, qui est toléré par la CNIL. Par défaut ça ressemble plutôt à ça : https://emmanuelgeorjon.com/blog/gerer-les-cookies-avec-tarteaucitron/images/tarteaucitron_first_screen.png
Je cherche à comprendre le concept de DMZ. L’objectif est d’avoir un serveur Web dans un réseau domestique mais accessible publiquement sur l’Internet. Je débute en réseautique donc je ne comprends pas vraiment les choses. Je ne sais pas ce qu’est une interface réseau (cela me semble trop compliqué à appréhender dans l’instant) ou un sous-réseau. Donc, par sécurité, j’ai tout annulé. Avant, j’avais intégré le serveur Web fonctionnant grâce au SE YunoHost dans la DMZ créée par la Livebox Orange. Le problème est que la documentation en ligne de Orange est inopérante (ou ineffective). En la lisant, on entre en pleine confusion.
Je ne comprends pas pourquoi Orange incite à désactiver le pare-feu de la Livebox afin de créer une DMZ. Orange renvoie vers la configuration de Livebox professionnel pour réseaux d’entreprises mais on peut également créer une DMZ sur une Livebox domestique.
En essayant de rester cohérent, il m’aurait semblé que le pare-feu aurait pu définir des règles différenciées entre chaque « zone » : la DMZ et le réseau local, la DMZ et l’Internet, l’Internet et le réseau local.
Dans mes souvenirs, je n’avais pas eu à modifier le niveau de sécurité du pare-feu de la Livebox domestique pour créer une DMZ. Mais on peut établir une configuration personnalisée en définissant des règles de filtrage.
Sur certains forums, des gens préconisaient des redirections de ports en déconseillant fortement d’employer la DMZ de la Livebox Orange.
Je suis totalement perdu. Le pare-feu de la Livebox 5 semble être un pare-feu applicatif, pour le reste je n’y comprends rien.
Le bouton “Tout refuser” caché en haut à droite ..
Bien
Le lien vers ma chaîne YouTube : https://youtube.com/channel/UCWftacXxXdvOk6MnoggQYug
Je viens de lire ce texte, et j’ai juste envie d’applaudir très fort. Bravo Lionel !
Les versions intermédiaires d’Ubuntu sont maintenues pendant seulement 6 mois et prennent les paquets dans Debian testing / unstable sans même se préoccuper des bogues et de leur résolution. Pour moi c’est de la version bêta inutilisable sur une machine de travail. Le bogue en question avait été corrigé chez Debian un mois avant la sortie d’Ubuntu 23.04 et signalé encore bien avant.
Manque plus qu’il devienne disponible en tant que packet binaire pour *BSD (dont OpenBSD bien sûr) ;)
La 23.04 n’est certes pas une version LTS mais ce n’est en rien une beta. Et le sujet de l’article est juste une solution de contournement pour ceux qui sont sur cette version et qui ont besoin de leur imprimante. :)
On n’est pas assez informé des dérives en tout genre. Le vidéaste anti-cyber-escrocs Sandoz réalise un travail extra…ordinaire en luttant contre ces gens malveillants et sans foi. On est aussi devancé de très loin par le progrès technologique (voir la vidéo de Micode « J’ai infiltré un réseau d’arnaqueurs au SMS »).
Yo,
J’ai pas compris en quoi c’était une version bêta ?
Tcho !