Je sais bien ! c’est bien pour ça que je dis : “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”. Google MàJ son draft pendant presque 10 ans et là bim, un gars qui a bossé dessus se retrouve à la tête de l’IETF et le draft passe RFC. Ça me plait pas.
“Google n’est pas une moteur de recherche avant tout” dans l’esprit des gens “lambda”, bien sûr que si. Pour nous autres geeks non, évidemment. Et d’ailleurs ça abonde en ce que je voulais dire : “Tous les services autour ont pour but ultime de vendre des utilisateurs pour de la pub” alors justement, qu’ils fassent de la pub et pas des nouveaux protocoles qui vont servir à faciliter la diffusion de la pub !
3- Le but de l’IETF et des RFC c’est que ça ne soit justement pas une technologie “Made in Google” mais une technologie de l’Internet.
C’est une norme ouverte publiée par l’IETF avant tout.
Par contre, non Google n’est pas une moteur de recherche avant tout. Pour savoir ce que c’est faut voir ce qui leur génère du pognon : la pub. C’est une boite de pub. Tous les services autour ont pour but ultime de vendre des utilisateurs pour de la pub. ;-)
Pourquoi faut-il toujours que, quand j’ai un sursaut d’espérance pour l’humanité, on finisse par me dire qu’elle l’a bien cherché… ;-)
Google, c’est avant tout un moteur de recherche. Leurs incursions dans la publication de contenu ne sont pas innocentes. Ils sont à tous les étages du modèle OSI, et c’est dangereux. Le jour où Google fera des propositions pour la protection de la vie privée, la confidentialité des contenus, et plus généralement aura un discours éthique (et pas seulement en surface avec des yeux de biches plein de promesses), je considèrerai peut-être que leurs propositions ne sont pas intrinsèquement néfastes.
Peut-être que je me trompe, peut-être qu’il n’y a pas de grand dessein de contrôler le monde, ou peut-être que c’est déjà le cas et qu’on ergote sur des platitudes. Dans le fond, je ne suis pas en total désaccord avec toi quand tu dis : “C’est d’ailleurs une bonne chose qu’ils aient poussé ça en temps que standard ouvert”, mais je réponds : “Il faut toujours se méfier du monsieur qui t’attire avec des bonbons dans son van sans fenêtres”. Le passif de Google ne joue pas en sa faveur pour une acceptation aveugle de ses technos, aussi cools soient-elles.
2- Mouai je suis plus pessimiste que toi. Google n’a pas imposé grand-chose. Les gens sont venus manger dans sa main. Ils “offrent” des produits compétitifs gratuitement. Les geeks se ruent dessus (gmail, google reader, google maps…). Ça fini par déborder ensuite dans le grand public et hop c’est bon. Mais personne n’a été forcé, ils ont juste proposé un truc qui répond à une demande sans avoir besoin de débourser un centime. Les gens y trouvent leur intéret.
Les rares personnes qui s’y opposent ne sont que très rarement écoutés et sont d’ailleurs assez souvent ridiculisés.
3- J’ai tendance à penser que ce n’est pas parceque c’est une techno issue de chez eux que c’est intrinsèquement néfaste.
D’autant plus quand ce n’est pas un produit fini mais une techno d’infrastructure comme l’est QUIC.
Dans ce cas, ça apporte de réels avantages par rapport à TCP et UDP.
Si nginx (par exemple) pense que HTTP3 et QUIC peuvent être un atout pour leur serveur web et qu’ils l’implémentent, c’est leur choix, ce n’est pas Google qui leur impose quoi que ce soit.
Google a poussé le truc car ils y voient un intéret pour eux, mais cet intéret ne leur est pas exclusif.
C’est d’ailleurs une bonne chose qu’ils aient poussé ça en temps que standard ouvert plutôt que de garder la techno rien que pour eux dans leur coin ou alors soumis à licence.
Pareil pour la domotique, je suis assez fasciné par la quantité d’électronique qu’on peut mettre chez soi. Heureusement qu’il y a l’isoloir pour se déculpabiliser.
Ok, admettons que ça se soit fait dans les règles de l’art. Et pour le reste ? TOUT le reste de ce que Google a imposé au monde ? Il n’y a que deux possibilités : soit les utilisateurs/développeurs/pseudo-geeks sont très cons d’avoir laissé faire, voire encouragé à l’adoption de tous les produits et services de Google, malgré les avertissements répétés et soutenus de tout “informaticien” qui se respecte de ces 20 dernières années, soit Google a forcé, pas en mettant un flingue sur la tempe mais politiquement, sémantiquement, linguistiquement. Je préfère croire cette hypothèse plutôt qu’en la stupidité des gens.
Je suis d’accord sur le principe. Appelle ça une intuition, de la paranoïa, ce que tu veux, mais moi j’y vois une insistance de Google pour légitimer l’imposition massive de leurs propres technologies. À l’époque, AMP c’était trop gros, trop évident. L’approche employée pour QUIC, plus subtile, est passée plus inaperçu. Et ils ont réussi. Encore une fois, moi je n’y vois rien de bon, ni de normal, j’y vois quelque chose d’inquiétant. Et tant qu’il y aura des gens pour s’inquiéter, il ne sera pas trop tard.
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.
“Google n’est pas une moteur de recherche avant tout” dans l’esprit des gens “lambda”, bien sûr que si. Pour nous autres geeks non, évidemment. Et d’ailleurs ça abonde en ce que je voulais dire : “Tous les services autour ont pour but ultime de vendre des utilisateurs pour de la pub” alors justement, qu’ils fassent de la pub et pas des nouveaux protocoles qui vont servir à faciliter la diffusion de la pub !
3- Le but de l’IETF et des RFC c’est que ça ne soit justement pas une technologie “Made in Google” mais une technologie de l’Internet. C’est une norme ouverte publiée par l’IETF avant tout.
Par contre, non Google n’est pas une moteur de recherche avant tout. Pour savoir ce que c’est faut voir ce qui leur génère du pognon : la pub. C’est une boite de pub. Tous les services autour ont pour but ultime de vendre des utilisateurs pour de la pub. ;-)
Pourquoi faut-il toujours que, quand j’ai un sursaut d’espérance pour l’humanité, on finisse par me dire qu’elle l’a bien cherché… ;-)
Google, c’est avant tout un moteur de recherche. Leurs incursions dans la publication de contenu ne sont pas innocentes. Ils sont à tous les étages du modèle OSI, et c’est dangereux. Le jour où Google fera des propositions pour la protection de la vie privée, la confidentialité des contenus, et plus généralement aura un discours éthique (et pas seulement en surface avec des yeux de biches plein de promesses), je considèrerai peut-être que leurs propositions ne sont pas intrinsèquement néfastes.
Peut-être que je me trompe, peut-être qu’il n’y a pas de grand dessein de contrôler le monde, ou peut-être que c’est déjà le cas et qu’on ergote sur des platitudes. Dans le fond, je ne suis pas en total désaccord avec toi quand tu dis : “C’est d’ailleurs une bonne chose qu’ils aient poussé ça en temps que standard ouvert”, mais je réponds : “Il faut toujours se méfier du monsieur qui t’attire avec des bonbons dans son van sans fenêtres”. Le passif de Google ne joue pas en sa faveur pour une acceptation aveugle de ses technos, aussi cools soient-elles.
2- Mouai je suis plus pessimiste que toi. Google n’a pas imposé grand-chose. Les gens sont venus manger dans sa main. Ils “offrent” des produits compétitifs gratuitement. Les geeks se ruent dessus (gmail, google reader, google maps…). Ça fini par déborder ensuite dans le grand public et hop c’est bon. Mais personne n’a été forcé, ils ont juste proposé un truc qui répond à une demande sans avoir besoin de débourser un centime. Les gens y trouvent leur intéret. Les rares personnes qui s’y opposent ne sont que très rarement écoutés et sont d’ailleurs assez souvent ridiculisés.
3- J’ai tendance à penser que ce n’est pas parceque c’est une techno issue de chez eux que c’est intrinsèquement néfaste. D’autant plus quand ce n’est pas un produit fini mais une techno d’infrastructure comme l’est QUIC. Dans ce cas, ça apporte de réels avantages par rapport à TCP et UDP. Si nginx (par exemple) pense que HTTP3 et QUIC peuvent être un atout pour leur serveur web et qu’ils l’implémentent, c’est leur choix, ce n’est pas Google qui leur impose quoi que ce soit.
Google a poussé le truc car ils y voient un intéret pour eux, mais cet intéret ne leur est pas exclusif. C’est d’ailleurs une bonne chose qu’ils aient poussé ça en temps que standard ouvert plutôt que de garder la techno rien que pour eux dans leur coin ou alors soumis à licence.
Quel type de pare-feu ?
Pareil pour la domotique, je suis assez fasciné par la quantité d’électronique qu’on peut mettre chez soi. Heureusement qu’il y a l’isoloir pour se déculpabiliser.
C’est pas le journal du noob ici.
Ok, admettons que ça se soit fait dans les règles de l’art. Et pour le reste ? TOUT le reste de ce que Google a imposé au monde ? Il n’y a que deux possibilités : soit les utilisateurs/développeurs/pseudo-geeks sont très cons d’avoir laissé faire, voire encouragé à l’adoption de tous les produits et services de Google, malgré les avertissements répétés et soutenus de tout “informaticien” qui se respecte de ces 20 dernières années, soit Google a forcé, pas en mettant un flingue sur la tempe mais politiquement, sémantiquement, linguistiquement. Je préfère croire cette hypothèse plutôt qu’en la stupidité des gens.
Je suis d’accord sur le principe. Appelle ça une intuition, de la paranoïa, ce que tu veux, mais moi j’y vois une insistance de Google pour légitimer l’imposition massive de leurs propres technologies. À l’époque, AMP c’était trop gros, trop évident. L’approche employée pour QUIC, plus subtile, est passée plus inaperçu. Et ils ont réussi. Encore une fois, moi je n’y vois rien de bon, ni de normal, j’y vois quelque chose d’inquiétant. Et tant qu’il y aura des gens pour s’inquiéter, il ne sera pas trop tard.
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 ..