Journal Google se marre dans son coin

Posté par . Licence CC by-sa.
Tags :
28
18
avr.
2019

Via HackerNews, on tombe sur ça : https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html

Extrait choisi :

we had to make trade-offs; namely, the URLs displayed in browser address bars begin with google.com/amp, as a consequence of being shown in the Google AMP Viewer, rather than display the domain of the publisher. We heard both user and publisher feedback over this, and last year we identified a web platform innovation that provides a solution that shows the content’s original URL while still retaining AMP's instant loading.
[…]
Your page appears under your URL instead of the google.com/amp URL.

Ah. OK. Donc, visiblement, si le site web que je souhaite consulter rempli tout un tas de conditions (décrites dans le blog), alors hop, le navigateur m’affiche une fausse URI. C’est tellement hype de mentir aux gens pour leur faire croire que tout va bien, que Google ne semble même pas se rendre compte de ce qu’il fait.

Ça me fait un peu penser à l’Internet de AOL, sauf qu’à cette époque, on savait qu’on était sur un monde différent. Là, la confusion va devenir très grande pour les utilisateurs, et donner des conseils de sécurité pour naviguer sur le Web va devenir… ardu.

  • # CloudFlare est à fond

    Posté par . Évalué à 9.

    Un des plus gros fournisseurs de CDN trouve ça vraiment trop bien : https://blog.cloudflare.com/announcing-amp-real-url/

    AMP Real URL is only supported in the Chrome browser at this time, but we are optimistic it will be supported more widely as its benefit to Internet users becomes clear.

    Ahlala.

    • [^] # Re: CloudFlare est à fond

      Posté par . Évalué à 10.

      j'ai récemment installé deux extensions dans mon firefox pour me rendre compte de l'étendue de cloudflare:

      • bmca pour rediriger toutes requêtes vers un site utilisant cloudflare vers son équivalent potentiel chez archive.org
      • detect-cloudflare pour avoir un indicateur visuel des sites utilisant cloudflare

      L'idéal, à mes yeux, serait une fusion de ces deux extensions avec le choix du proxy (archive.org ou autre) ou de l'action à réaliser (ouverture dans torbrowser par exemple)

      Je suis effaré par le nombre de sites m'obligeant à transiter par cloudflare, y compris HackerNews.

      Je suppose qu'avec AMP on se dirige vers la même chose…

      • [^] # Re: CloudFlare est à fond

        Posté par . Évalué à 6.

        Euh. Cloudflare, c'est un peu plus qu'un simple "proxy": en fonction des choix du webmaster, ça peut être l'unique chemin d'accès au contenu.

        Rediriger les requêtes vers archive.org (qui de mémoire, bein archive, donc n'est pas sur le concept de "être à jour") me parait un tantinet risqué.

        Sinon, ouais … je suis d'accord, c'est désolant.

        Après, j'ai été puni au travail récemment et j'ai du me taper une petite immersion totale dans ce joli monde d'AWS. Le but: y déployer pour un client une appli basée sur une API Rest et un frontend angular.

        Entre CloudFlare, AWS Lambda (scripting, entre autre pour Cloudflare pour rewrite d'URL & co), Elastic Beanstalk (Serveur applicatif Python/Node/… pour l'API Rest), Elastic File System (partage NFS entre instances), S3 (stockage de statique) et RDS (Database) et bien en fait, t'as tout ce qu'il faut pour héberger un service à grosse volumétrie sans avoir le moindre serveur en ta possession.

        Ca te coute ce que ça consomme, c'est quand même bien foutu (ça me desespère, mais vraiment).

        C'est désolant pour le côté décentralisation et monopole, mais ça permet à pas mal de boite de petite envergure de lancer du service sur le web sans avoir d'admin système, d'admin réseau, de salle blanche et tout le tralala.

        • [^] # Re: CloudFlare est à fond

          Posté par . Évalué à 2.

          Oups… réponse à côté de la plaque.

          s/cloudflare/cloudfront/g et là, ça se comprend mieux.

          C'est ma punition pro qui m'a monté à la tête … désolé !

  • # se marre dans son coin ???

    Posté par . Évalué à 10.

    Je n'arrive pas à voir le rapport entre le titre du journal et son contenu. Quelqu'un peut m'expliquer ?

    C'est une vraie question, je n'ai pas compris. Alors qu'un titre du genre "Google nous enfume", j'aurais plus compris (indépendamment d'être d'accord ou pas).

    • [^] # Re: se marre dans son coin ???

      Posté par . Évalué à 10.

      mare… coin… c'est pourtant évident, l'allusion à la tribune est évident.

      _o<

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: se marre dans son coin ???

      Posté par . Évalué à 10.

      Il n'y avait pas de jeu de mot volontaire.

      Google est devenu suffisamment hégémonique pour pouvoir modifier les fondements d'Internet (l'affichage d'une URI) quand ça l'arrange. Il devient donc en mesure de faire des modifications dans son coin. Et d'après l'article de blog, c'est vraiment mieux. Ce ne sera disponible que pour Chrome, mais il n'y a plus que Mozilla pour s'y opposer, ça ne va pas aller loin. Donc, Google fait des modifications importantes, dans son coin, mais il se marre, parce que ça peut marcher.

      Une URI, c'est sensé être unique. Point.

      • [^] # Re: se marre dans son coin ???

        Posté par (page perso) . Évalué à -10.

        Une URI, c'est sensé être unique. Point.

        En vertu de quelle règle ?

        modifier les fondements d'Internet (l'affichage d'une URI)

        Oh la la le gloubiboulga. Par exemple les fondements d'internet ça serait pas plutôt IP ?

        • [^] # Re: se marre dans son coin ???

          Posté par . Évalué à 10.

          En vertu de quelle règle ?

          Bah, pour commencer, le W3C :

          Axiom 1: Global scope
          It doesn't matter to whom or where you specify that URI, it will have the same meaning.
          So, this means that there is no scope within which a URI must be placed for it to hold. All you need say is that something is "on the Web" and that is enough. Anyone can follow that hypertext link, anyone can look up that URI.
          […]
          The same identifier string is expected from one day to the next to point to, in some sense, the same object. That is a very important axiom, and it leaves open the "in some sense" behind which is a very complicated discussion of the concept of identity. When are two things "in some sense" the same.

          La section suivante, concernant l'identité et "l'identity abuse" est aussi pertinente dans ce cas ci.

          Oh la la le gloubiboulga. Par exemple les fondements d'internet ça serait pas plutôt IP ?

          Oh non! Quelqu'un a osé écrire "Internet" au lieu de "web". Discréditons complètement son propos sur cette différence sémantique reprise ad nauseam depuis 20 ans!

          • [^] # Re: se marre dans son coin ???

            Posté par (page perso) . Évalué à -7.

            So, this means that there is no scope within which a URI must be placed for it to hold.

            Oui et l'URL dé-AMPisée sera accessible, et servira le même article (sans les optimisations AMP). Donc ?

            Anyone can follow that hypertext link, anyone can look up that URI.

            Bah oui. Après si tu la suis avec un navigateur qui n'implémente que HTTP 1.0 ptêtre que ça marchera pas si le serveur est en 1.1 mini. Quoi de neuf ?

            The same identifier string is expected from one day to the next to point to, in some sense, the same object.

            Qu'est-ce qui dans l'optimisation AMP viole ça ???

            Oh non! Quelqu'un a osé écrire "Internet" au lieu de "web". Discréditons complètement son propos sur cette différence sémantique reprise ad nauseam depuis 20 ans!

            Putain cette mauvaise foi de compèt' :-D La moitié des commentaires des journaux qui parlent de "web" sont là dessus, c'est vrai que ça doit être peu important.

            Mais bon peut-être que Google te les a cachés à ton insu ?

            • [^] # Re: se marre dans son coin ???

              Posté par . Évalué à 10.

              Oui et l'URL dé-AMPisée sera accessible

              Où? Si ça ne fait aucune différence dans la barre d'adresse, pour moi, du point de vue de l'utilisateur, c'est la même URL (pareil que d'omettre le http:// par exemple).

              The same identifier string is expected from one day to the next to point to, in some sense, the same object.
              Qu'est-ce qui dans l'optimisation AMP viole ça ???

              Voici deux URL :

              Sont-ce les mêmes? Si, demain, archive.org prenait le contrôle des DNS de linuxfr, est-ce que tu considèrerais qu'ils servent encore la même ressource? Aurais-tu encore confiance que qu'ils servent la même ressource? Parce que oui, comme indiqué dans d'autres sections du document que je n'ai pas citées, tout est une question de confiance…

              Putain cette mauvaise foi de compèt' :-D La moitié des commentaires des journaux qui parlent de "web" sont là dessus, c'est vrai que ça doit être peu important.

              Oui, et tant qu'à moi c'est un problème. Il y a une différence entre les "classiques" du site (e.g. parler de son clavier qui se blo sans arrêt) dans les threads de commentaires humoristiques et invalider le point de vue d'un interlocuteur sur une broutille qui n'a causé de confusion pour personne. À la limite, je ne suis pas contre le mentionner, mais si ça devient, comme dans ton message précédent, l'argument central, pour moi c'est un problème.

              • [^] # Re: se marre dans son coin ???

                Posté par (page perso) . Évalué à 3.

                Mais en l'occurrence, la confiance est aidée par la signature de linuxfr qui te certifie que le contenu servi par archive.org est identique à celui de linuxfr.

          • [^] # Re: se marre dans son coin ???

            Posté par . Évalué à -1.

            Oh non! Quelqu'un a osé écrire "Internet" au lieu de "web". Discréditons complètement son propos sur cette différence sémantique reprise ad nauseam depuis 20 ans!

            Ça remet juste en perspective les grands chevaux sur les quels tu monte.

            En quoi le contenu du journal viole l'axiome de ta citation ? Il est dit qu'une URI est un identifiant de ressource pas qu'il doit être le seul identifiant de la ressource. http://google.com/toto.amp et http://exemple.org/toto peuvent pointer la même ressource et heureusement. C'est tout ce que fais chrome de ce que j'ai compris remplacer l'identifiant amp par celui du site d'origine, mais ça reste une url valide qui pointe la même ressource.

            • [^] # Re: se marre dans son coin ???

              Posté par . Évalué à 10.

              Ça remet juste en perspective les grands chevaux sur les quels tu monte.

              Les grands chevaux? Désolé si c'est comme ça que ça a été interprété. Mais oui, ça devient lassant de voir un propos se faire démolir seulement parce que "web" et "Internet" ont été confondus. C'est comme si ma seule réponse à votre message était ceci :

              C'est tout ce que fais chrome

              Oh la la le gloubiboulga. Avertissez l'académie, maintenant les verbes en -re se terminent en "s" à la 3e personne du singulier!

              C'est juste hors de propos.

              En quoi le contenu du journal viole l'axiome de ta citation ? Il est dit qu'une URI est un identifiant de ressource pas qu'il doit être le seul identifiant de la ressource.

              Le problème n'est pas que http://google.com/toto.amp existe (en fait il y a d'autres problèmes avec AMP, mais c'est une autre histoire). Le problème qu'il soit indiscernable de http://exemple.org/toto Qu'ils pointent vers la même ressource est une "promesse" que te fait Google. Tu es libre de faire confiance à Google ou pas dans le cas où les URI sont différentes, mais lorsque les deux sont les mêmes, tu n'as plus le choix.

              Pour donner un exemple plus concret, supposons que quelqu'un réussisse par un quelconque moyen à corrompre le AMP pour un certain moment. Dans le cas où le navigateur le remplace de manière invisible à l'utilisateur, c'est exactement la même chose que si le site original avait une faille. Il n'y a aucun moyen à l'utilisateur de faire la différence. Ça me paraît être un problème.

              Et là, je ne vais même pas dans les arguments plus génériques : accepter cela revient à donner à Google un contrôle invisible sur ce que vous visitez, même lorsque vous n'utilisez pas leurs sites ou leurs services. C'est quand même gros…

              • [^] # Re: se marre dans son coin ???

                Posté par . Évalué à 4.

                Voilà un argument bien plus précis et intéressant et qui n'a rien à voir avec avec les URI sont uniques.

                En effet même si tu peux accéder au site sans AMP, il devient plus difficile de s'en assurer.

                • [^] # Re: se marre dans son coin ???

                  Posté par . Évalué à 1.

                  Si j'ai bien compris la page au format AMP est une version simplifiée pour être plus rapide à charger et à afficher que la page au format "normal" mais les deux versions coexistent simultanément (un peu comme il y aussi une version mobile de certains sites). Les deux versions sont normalement hébergées chez l'éditeur du contenu mais il y a une option pour que la version AMP soit hébergée chez Google (j'imagine que cette option sera le plus souvent souscrite).

                  Si on tape http://www.unsite.com, même depuis Chrome sous Android, on va tomber sur la page "normale", je me trompe ?

                  C'est seulement si on fait une recherche Google de "unsite" et qu'on clique sur le lien résultat http://www.unsite.com précédé d'un symbole 'éclair' qu'il va s'afficher au format AMP (avec l'URL http://www.unsite.com même si la page AMP est hébergée chez Google). NB. Le symbole 'éclair' renseigne juste sur la version, il ne dit pas où est hébergée la page.

                  On critique quoi en fait ? AMP lui-même (qui n'implique pas nécessairement un cache) ou le fait que dans certains cas la page affichée ne provienne pas du serveur dont l'URI s'affiche dans le navigateur parce qu'elle est en cache quelque part ?

                  Si c'est l'aspect cache, ce n'est pas le même problème avec Cloudflare ?

  • # Proxy?

    Posté par (page perso) . Évalué à 4.

    Donc une extension IETF permet à Google de faire proxy pour prétélécharger le contenu que son IA a deviné que tu allais vouloir?

    … effectivement, c'est à vomir.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Proxy?

      Posté par . Évalué à 8.

      Ce n'est pas du tout ce que j'ai compris.

      Il n'y pas de pré-téléchargement d'un contenu par rapport à une prédiction d'IA sur le site sur lequel tu vas prochainement surfer. Il y a pré-téléchargement systématique sur les serveurs de Google d'un ensemble de contenus (en accord avec les éditeurs de ces contenus) qui sont ensuite affichés plus rapidement grâce à des technos Google sur les navigateurs/OS compatibles (actuellement Chrome sous Android). La "nouveauté" citée par ce journal consiste à ne plus afficher dans la barre d'adresse un préfixe indiquant que la page affichée est en fait hébergée chez Google et pas sur le site "original", ce qui viole un principe de base du web même si plein de précautions semblent implémentées pour contrer le risque d'usurpation.

      Où-ce que tu vois une IA dans cette affaire ?

      • [^] # Re: Proxy?

        Posté par (page perso) . Évalué à 2. Dernière modification le 18/04/19 à 16:30.

        Dans cette phrase : "Near-instant loading works by requesting content ahead of time, balancing the likelihood of a user clicking on a result with device and network constraints".

        C'est bien de l'IA qui évalue les chances qu'on clique, non?

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Proxy?

          Posté par . Évalué à 7.

          Je n'avais pas vu cette partie-là.

          Je ne sais pas comment ça marche mais a priori c'est à la charge du navigateur. Du coup, j'ai plutôt l'impression que ça doit être un algorithme prenant en compte la taille des pages référencées dans la page courante et la vitesse de la connexion du device. Si tel est le cas, c'est pas de l'IA, loin s'en faut.

          De toutes façons, quand bien même, ce n'est pas cette partie qui seraient "à vomir" : Google utilise ici les données qu'il a déjà sur toi et il les utilise pour accélérer l'affichage d'une page (c'est quand même toujours toi qui décide du lien que tu vas cliquer in fine).

          Le problème, à mon sens, c'est que cette technologie est un nouveau moyen pour Google d'en savoir encore plus sur toi. En effet, quand on va sur un site directement (i.e. sans passer par une recherche) Google ne le sait pas (ou moins bien). Il a bien essayé de pallier à ce problème en proposant ses DNS (c'était astucieux) mais l'adoption n'a pas dû être aussi généralisée qu'espérée. Alors un autre moyen consiste à héberger carrément le contenu sur ses serveurs. Mais pour le justifier - tant auprès des éditeurs de contenus qu'auprès des lecteurs qui pourraient se demander "what the fuck ?" - il faut offrir quelque chose en échange : la vitesse d'affichage d'une page (aux éditeurs de contenus on vend l'idée que si c'est trop long, les lecteurs vont cliquer sur un autre lien).

          C'est un peu bidon comme prétexte à l'époque de la 4G et bientôt 5G. Si encore Google avait proposé ça dans les pays où internet est encore lent, on aurait pu y croire.

          • [^] # Re: Proxy?

            Posté par . Évalué à 3.

            Pour ta dernière remarque Google est vraiment intéressé par la vitesse du web (probablement parce que ça implique entre autre de la charge sur leur serveur). Outre AMP, c'est eux qui sont à l'origine de HTTP/2 et HTTP/3. Techno standardisé par l'IETF et qui ne font rien à ta vie privée.

            On les voit aussi contribuer à la pile réseau de linux, ils proposent des solutions comme tfo,… Remettre en cause leur volonté là dessus c'est assez mal placé.

            Ils ne le font pas pour rien, mais améliorer la performance du réseau fait parti de leurs objectifs

            • [^] # Re: Proxy?

              Posté par (page perso) . Évalué à 2.

              C'est un peu bidon comme prétexte à l'époque de la 4G et bientôt 5G. Si encore Google avait proposé ça dans les pays où internet est encore lent, on aurait pu y croire.

              Je pense qu'il ne faut pas confondre vitesse de connexion et temps d'accès. Un serveur qui n'a pas une bonne connexion, ou un bon cache de rendu va être très lent à chaque visite, même avec de la fibre optique. Le 'standard' proposé par Google implique de s'obliger à créer un cache, et à laisser google s'occuper de la bande passante réseau.

              On est vraiment trop habitués aux sites instantanés… c'est comme l'habitude de la vidéo HD qui tue les vieux films. L'humain est décidément trop exigeant!

              ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

              • [^] # Re: Proxy?

                Posté par . Évalué à 3.

                Il est largement communément admit que l'impression de vitesse vient plus de la latence que du débit et justement toutes les techniques de mon précédent commentaire cherchent à résoudre les problèmes de latence (mais c'est aussi le cas d'un paquet d'autres techno comme le bundling fait par webpack par exemple). Évidement le téléchargement le plus rapide est celui que l'on ne fait pas et les CDN travaillent à cela en poussant les temps de validité des contenu au maximum.

                Je suis allé sur le site de uber (c'est le premier lien sur hackernews). Je vois dans les requêtes passer un certains nombre qui vont vers le CDN de facebook (genre : https://static.xx.fbcdn.net/rsrc.php/v3/yv/r/uFHIwLkg_qw.js) et il donne une expiration au "Wed, 15 Apr 2020 21:00:29 GMT" soit le maximum si on veut respecter les normes. Les CDN (très souvent décriés ici) ne cherchent pas particulièrement à tracker et l'utilisation massive d'un même domaine améliore l'effet de cache du navigateur (si une police vient toujours de chez cloudflare par exemple, elle ne sera téléchargée qu'une seule fois). Les CDN ont tout intérêt à réduire au maximum le nombre de requêtes qu'on leur envoie.

                On est vraiment trop habitués aux sites instantanés… c'est comme l'habitude de la vidéo HD qui tue les vieux films. L'humain est décidément trop exigeant!

                Je ne comprends pas ? TFO/ALPN et HTTP/2 c'est mal ? Le rendu statique du contenu mis en cache par ton serveur web non plus ? 90% des techniques ne font aucun débat sur la vie privée. C'est logique de vouloir améliorer l'existant. Ça ne veut pas dire que tout est bien (je ne connais pas AMP). Avoir voulu améliorer l'exécution du js tu le place où dans ta morale par exemple ?

            • [^] # Re: Proxy?

              Posté par (page perso) . Évalué à 8.

              Pour ta dernière remarque Google est vraiment intéressé par la vitesse du web

              Google est motivé par la publicité.

              Hors la publicité est le principal ralentisseur du web.

              Incubez l'excellence sur https://linuxfr.org/board/

              • [^] # Re: Proxy?

                Posté par . Évalué à 5.

                L'un n'empêche pas l'autre : on peut vouloir un web plus rapide afin que la publicité s'affiche plus vite et qu'on ait le temps d'en voir plus sur le trajet maison-boulot.

              • [^] # Re: Proxy?

                Posté par . Évalué à 1.

                Et alors ? C'est peut-être l'entité qui a le plus contribué à l'accélération d'Internet dans le monde ces 10 dernières années. Non ils ne font pas ça pour tes beaux yeux mais ça ne remet pas en cause leur boulot.

                • [^] # Re: Proxy?

                  Posté par (page perso) . Évalué à 3.

                  Je ne vois pas comment: Google c'est surtout de la charge inutile (tracking & pub).

                  Incubez l'excellence sur https://linuxfr.org/board/

                  • [^] # Re: Proxy?

                    Posté par . Évalué à 3.

                    TFO, ALPN, HTTP/2, HTTP/3, leurs contributions à la pile réseau de linux, brotli, webm, webp,…

                    On en fait pas beaucoup de publicité, mais tu n'a pas besoin de le savoir pour en tirer partie.

                    C'est difficile de dire que Google ne fait pas que tuer des koala ?

                    • [^] # Re: Proxy?

                      Posté par (page perso) . Évalué à 6. Dernière modification le 22/04/19 à 15:33.

                      Ce sont les ingénieurs qu'il faut féliciter pour les apports techniques et l'entreprise qu'il faut honnir pour leur mauvais usage.

                      Après on peut débattre de l'utilité de HTTP3 pour servir des sites bourrés de pubs en webm, de popup RGPD webp et de trackers sécurisés par ALPN par rapport à un bon vieux site HTTP1 qui s'affichera 42 fois plus vite en consommant 67 fois moins de bande passant parce qu'il ne propose que du contenu pertinent.

                      Incubez l'excellence sur https://linuxfr.org/board/

                      • [^] # Re: Proxy?

                        Posté par . Évalué à 3.

                        Tu essaie de te raccrocher aux branches que tu veux. Ces ingénieurs ont pu faire ce travail parce qu'une entreprise les payait pour faire ce travail. Donc cette entreprise a décidé de payer des gens pour que ces ingénieurs super héros puissent non seulement construire des techno qui soient accessible à tous.

                        Tu peux utiliser toutes les techno que j'ai listé sans jamais à aucun moment ne faire même qu'une seule requête vers l'un de leur serveur. Donc oui Google a investi des sommes conséquentes avec comme résultats que toi tu puisse naviguer plus vite.

                        Tu peux aller plus loin avec AMP et 8.8.8.8, mais là ça te demande de leur faire confiance alors que les techno dont j'ai parlé précédemment sont soient des standards soient implémentés dans les projets upstream.

                        Dire Google fait croire qu'ils veulent améliorer la performance des réseaux, c'est soit ne pas savoir ce que fait Google depuis pas mal d'années, soit de la mauvaise foie. J'aurais tendance à te croire suffisamment informé pour te classer dans la seconde partie vu que tu n'a pas d'autres arguments que "c'est des méchants".


                        Vu que je connais un peu tes techno comment vie tu le fais d'utiliser playn, guice ou gwt ? Dissonance cognitive ? Tu sais qu'ils n'ont fait ça que pour la pub, te voler tes informations personnelles et tuer les bébés phoques ?

                        • [^] # Re: Proxy?

                          Posté par (page perso) . Évalué à 1.

                          Tu es du genre à penser que Google c'est comme Mao? 70% de bon, 30% de mauvais?

                          Incubez l'excellence sur https://linuxfr.org/board/

                          • [^] # Re: Proxy?

                            Posté par . Évalué à 3.

                            J'ai tendance à ne pas tout mélanger des faits logiquement objectif avec mon sentiment par essence subjectif.

                            Je pense qu'il serait bon de découper les GAFAM, Google en premier, et ce même si je sais que Google a énormément bosser sur la qualité d'Internet.

                            J'ai l'impression que pour que tu puisse assumer ton mécontentement face à quelque chose, il faut que tu retire toute qualité et intérêt à cette chose. C'est le propre du manichéisme, soit c'est tout noir, soit c'est tout blanc.

                            Sincèrement l'hégémonie de Google, notamment en matière de pub, sa position en mesure de créer des bulles d'internet autour de nous et les velléités d'Alphabet sont amha suffisamment dangereux pour mettre un terme à ce projet de fin d'étude.

  • # Ils veulent faire comme Xiaomi ?

    Posté par (page perso) . Évalué à 7.

    Un article sur un navigateur qui a aussi choisi d'utiliser la barre d'url pour autre chose :
    https://www.nextinpact.com/brief/xiaomi-corrige-une-etrange-et-importante-faille-sur-ses-navigateurs-web-8395.htm

    Je résume : Ils ont voulu qu'après une recherche, la barre affiche le contenu de la recherche plutôt que l'url du site. Pour faire ça, ils affichent le contenu de l'argument "q" quand il est présent dans l'url.
    Ça marche avec n'importe quel site, donc gros_fisheur.com?q=tabanque.com affiche sans sourciller un site, avec le nom d'un autre dans la barre. Bravo…

    • [^] # Re: Ils veulent faire comme Xiaomi ?

      Posté par . Évalué à 2. Dernière modification le 18/04/19 à 17:55.

      Je connais pas le cas avec Xiaomi mais il me semble que Google impose un système de "DRM" (peut-être pas le terme exact) mis en place avec les sites partenaires pour éviter une usurpation de site. Après je ne suis pas compétent pour juger de la "solidité" de cette protection.

      • [^] # Re: Ils veulent faire comme Xiaomi ?

        Posté par (page perso) . Évalué à 4.

        Si j'ai bien compris, c'est un système de signatures.

        En gros, le site d'origine (toto.com) publie une page web 'http://toto.com/index.amp' et la publie (dans une archive 'index.amp.zip' qui contient toutes les ressources), puis signe cette archive avec son certificat toto.com.

        Comme l'archive est autosuffisante, google (ou un autre CDN) va pouvoir télécharger cette archive pour être en mesure d'afficher la page web.
        Quand tu feras une recherche Google pour trouver 'http://toto.com/index.amp', Google (ou un CDN) te renverra en pratique vers la page 'http://google.com/toto.com/index.amp.zip'.
        Cependant, comme l'archive est signée, Chrome affichera uniquement 'toto.com/index.amp'.

  • # Pour les néophytes

    Posté par . Évalué à 10.

    AMP : Accelerated Mobile Pages
    Selon wikipedia:

    Fonctionnement

    AMP est une méthode de création de pages Web pour du contenu statique permettant un rendu rapide. AMP se compose de trois parties :

    • AMP HTML : HTML avec des restrictions pour assurer une performance fiable. Des extensions permettent de créer du contenu enrichi plus élaboré qu'avec le HTML de base
    • AMP JS : bibliothèque JavaScript qui garantit un rendu rapide des pages AMP HTML.
    • Un système de cache : comme Google AMP Cache (en option) qui permet de fournir les pages AMP HTML.

    Critiques

    Selon Plusieurs média dont The Register ont critiqué l'AMP: Je pense qu'il faut clairement dire: l'AMP de Google est une mauvaise chose - mauvaise chose dans le sens où il peut potentiellement détruire le web. L'AMP de Google est une mauvaise nouvelle sur la façon dont on construit le web, c'est une mauvaise nouvelle pour les éditeurs de contenus en ligne et c'est une mauvaise nouvelle pour les consommateurs du dit contenu. L'AMP de Google est une bonne nouvelle pour une seule partie: Google. Google, et potentiellement, les pourvoyeurs de fausses informations… Le fondateur de Pinboard.in Maciej Cegłowski a recréé la page de démonstration de Google AMP sans utiliser le javascript AMP écrit par Google et, étonnamment, elle est plus rapide que la version de Google… N'importe qui peut fourrer une idée illégitime dans une page web et - aussi longtemps qu'elle est encodée en AMP - on aura l'impression qu'elle émane d'une organisation légitime validé par Google.

    Chris Coyier, cofondateur de CodePen, a écrit que l'AMP serait meilleur s'il n'était pas utilisé comme critère de classement (ou n'importe quoi qui puisse être interprété comme tel) par qui-que ce soit" et s'il "devenait un standard W3C" .

    • [^] # Re: Pour les néophytes

      Posté par . Évalué à 3. Dernière modification le 18/04/19 à 19:06.

      Merci pour ces explications.

      N'importe qui peut fourrer une idée illégitime dans une page web et - aussi longtemps qu'elle est encodée en AMP - on aura l'impression qu'elle émane d'une organisation légitime validé par Google.

      Je ne comprends pas cette partie : avec la modification décrite dans ce journal, on n'a plus le préfixe amp dans l'URL mais l'URL du site d'origine même si ce site utilise Google AMP Cache. Comme par ailleurs je ne pense pas que l'utilisateur lambda se pose la question de savoir si la page qu'il regarde est encodée en AMP, de quelle façon il peut avoir l'impression qu'elle émane d'une organisation légitime validée par Google ?

      Est-ce que les critiques de The Register sont toujours pertinentes après la modification dont on parle ici ?

  • # AMP cache la réelle provenance de l'info

    Posté par . Évalué à 2. Dernière modification le 18/04/19 à 23:58.

    pour moi c'est le premier problème d'AMP, alors google essaye de corriger ceci en affichant l'URL de provenance avec un mécanisme dit sécurisé.

    bref le gros méchant c'est toujours Google, j'aimerais bien voir comment Apple va réagir a cette montée en puissance d'AMP…
    ha bien tiens :
    http://iphoneaddict.fr/post/news-213882-ios-11-supprime-liens-amp-google-moment-partager

    J'aime pas Google, ils font souvent des conneries, attention AMP vas aussi débarquer dans les emails !!!!

    https://venturebeat.com/2019/03/26/google-brings-amp-powered-dynamic-emails-to-gmail/

    Couldflare n'est qu'un CDN qui permet de mieux distribuer du contenu à travers le monde, de protéger ces sites, même à ceux qui ne saurait le faire eux-mêmes… il en existe d'autres Incapsula par exemple…
    Cloudflare participe a un internet plus rapide et plus sécurisé DNS : 1.1.1.1 et requêtes sur HTTPS

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.