301 private links
List of Atom (Web syndication) links to monitor a repository and more on Github.
Just replace the variables ${…} by there corresponding content.
Repository releases:
Repository tags:
Repository commits:
Private feed (you can find Subscribe to your news feed in dashboard page after login):
User activity:
Google vient (de nouveau…) de franchir une ligne rouge. Et c’est grave, très grave, pour l’avenir du Web.
Je cite :
Any developers using links built with the Google URL Shortener in the form https://goo.gl/* will be impacted, and these URLs will no longer return a response after August 25th, 2025.
En résumé, tous les liens sous la forme https://goo.gl/* ne fonctionneront plus après le 25 août 2025.
Note : je n’ai jamais utilisé aucun service de création de raccourci de liens.
EDIT : je retrouve une info, l’arrêt progressif de ce service a été annoncé en 2018, après neuf ans de création.
https://next.ink/brief_article/google-met-fin-a-son-raccourcisseur-durl-goo-gl-remplace-par-un-outil-firebase/
Pour moi, les services de raccourcis de liens ou les intermédiaires (pour suivi marketing, "protection", etc) sont de monumentales erreurs qui n’auraient jamais dû exister, ou plutôt qui ne devraient pas être utilisées sans mettre le véritable lien juste à côté.
EDIT : j’aime le terme de « obscurcisseurs », de « brouilleurs » de liens. :D
Des gens qui tapent des URL à la main, depuis des années, jamais vu.
Je ne dis pas qu’il n’existent pas des cas pratiques, même si de nos jours les QR-Codes remplacent ça avec leurs défauts et avantages ; je pense aux cas des supports non-numériques (magazines et affiches), mais à la condition que le lien non raccourci soit à côté.
Là où c’est grave, comme j’introduisais, c’est qu’ici, il s’agit de Google.
Google, acteur incontesté du Web, une entreprise aux billions de dollars (billion en français, donc mille milliards, voire annexe plus bas), se prépare à créer un gigantesque cimetière dans le Web.
Le jour où Google a décidé d’ouvrir ce service, Une règle auraient dû imposée, à ne jamais enfreindre : ce service ne doit jamais disparaître.
Note : je tiens à préciser que ça doit être pareil pour tout acteur fournissant ce même service.
Les liens créés ne doivent jamais être modifiés, supprimés (même ceux créés par ses utilisateurs, mais ça c’est un point de vue (sauf exception comme de façon non exhaustive atteinte à la dignité d’une personne, bien entendu)).
Comment Google avec toute sa force, toute sa trésorerie, peut ne pas maintenir un service aussi simple ? Comment peuvent-ils se permettre d’avoir un tel choix sans conséquence ? (réponse : ils font ce qu’ils veulent) Pourquoi ne pas alors transmettre à un tiers ? (Haha, Google ne laissera jamais un tiers contrôler leur nom)
Qu’ils arrêtent la création de nouveaux liens, aucun problème, tant mieux même (les QR-Codes répondent très bien à ça) ; mais ça, décider de faire tout disparaître, c’est grave, très grave.
C’est pour tout ça que Google devrait être condamné de façon très importante,
Le Web est devenu une machine à liens brisés, un cimetière, alors que le numérique permet de rendre immortel n’importe quelle information, donnée, contenu.
Merci Google 🖤 (crève plutôt 😘)
Annexe :
Capitalisation de Alphabet, le nom de la maison mère de Google
Juste par curiosité, je suis allé me renseigner, et d’après ce lien :
As of July 2024 Alphabet (Google) has a market cap of $2.225 Trillion. This makes Alphabet (Google) the world's 4th most valuable company by market cap according to [companiesmarketcap.com’s] data.
https://companiesmarketcap.com/alphabet-google/marketcap/
Juillet 2024, 2,225 billions de dollars, quatrième capitalisation boursière au monde.
Pour remettre aussi dans le contexte (toujours d’après cette source), le premier billion a été atteint en juillet 2020 (frôlé en janvier 2020), a doublé en frôlant le second billion 1 an et quatre mois plus tard, en novembre 2021 (merci la pandémie), chuté a 1,12 billion en novembre 2022, et a atteint son record à 2,36 billion au début de ce mois, juillet 2024.
Qu’on ne dise pas qu’ils n’ont pas les moyens de maintenir en lecture seule ce service, c’est factuellement faux.
Liste des fonctions utilisées dans les « scripts » proxy, scripts souvent utilisés dans les entreprises pour gérer les connexions.
Je garde le lien pour m’aider dans des projets de ma longue liste de développement.
about:config:
-
network.http.sendRefererHeader
0 - never send the referring URL.
1 - send only when links are clicked.
2 - send for links and images (default). -
network.http.referer.XOriginPolicy
0 - always send referrer (default).
1 - only send if base domains match.
2 - only send if hosts match. -
network.http.referer.spoofSource
false - send the referrer (default).
true - spoof the referrer and use the target URI instead. -
network.http.referer.trimmingPolicy
0 - send full URI (default).
1 - scheme, host, port and path.
2 - scheme, host and port.
(Article en anglais)
Et voilà, une seule erreur, et c’est la catastrophe pour tout le monde ! Pourquoi ? parce que c’est le genre de risques qu’il y a avec tous ces services super centralisés.
Aujourd’hui, la flemme de décrire la faille (j’écris surtout pour garder les liens), mais en gros, ça s’appelle "CloudBleed", car ça a le même soucis que HeartBleed, c’est une zone mémoire prise aléatoirement.
En français, sur NextINpact : https://www.nextinpact.com/news/103421-cloudbleed-importante-fuite-donnees-chez-cloudflare-changez-vos-mots-passe.htm
En français, sur LinuxFR : https://linuxfr.org/users/pied/journaux/ho-la-belle-prise-chez-cloudflare
En anglais : https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
Les nouveaux propriétaires de SourceForge ont semble-t-il de bonnes intentions pour remettre la plateforme sur le bon chemin :
- suppression des publicités abusives,
- retrait des publicités dans les installateurs,
- redéveloppement du site web avec HTML5.
Oh que ça donne le tournis tout ça.
Oh chic ! La dernière version du navigateur Web de Mozilla, la version 42, sortie récemment, fonctionne enfin en 64 bits pour Windows.
Voici donc le lien pour télécharger les binaires dans la langue que vous souhaitez, j'ai toutefois pris la liberté de donner le lien pour la version sans EME (Encrypted Media Extensions), appelée "win64-EME-free", des modules à sources fermées pour lire du contenu sous DRM (Digital rights management), nécessaire pour ceux qui souhaitent utiliser des services de VOD (comme Netflix par exemple). Du coup, il suffit de remonter dans l’arborescence pour aller dans le dossier "win64" au lieu de "win64-EME-free".
https://en.wikipedia.org/wiki/Encrypted_Media_Extensions
https://en.wikipedia.org/wiki/Digital_rights_management
Un bon article sur le rapport de la "neutralité des plateformes" du Conseil National du Numérique (CNNum).
Voir aussi le résumé sur Numérama : http://www.numerama.com/magazine/29690-la-neutralite-des-plateformes-qu-est-ce-que-c-est.html
Ah, mauvaise nouvelle pour un web libre.
Mais comme ils disent, ils n'ont pas vraiment le choix, c'est la dictature du marché : "Marche ou crève".
Ainsi Mozilla mettra au sein de Firefox les EME (pour Encrypted Media Extensions), standards définis par le W3C (World Wide Web Consentium), standards qui feront appel donc à des extensions. Toutefois, Mozilla fait un bon choix en décidant de ne pas coder cette fonctionnalité, et de laisser quelqu'un d'autre (Adobe en l'occurrence) s'en charger, grâce à un module externe ; ainsi, sous GNU/Linux, on aura toujours le choix d'installer Firefox/Iceweasel sans ce module.
Mais en attendant, c'est un combat perdu sur le plan d'un web ouvert, et c'est même une porte ouverte à d'autres modules : qu'est-ce qui empêchera chacun des fournisseurs de contenus d'avoir leur propre module, à "télécharger" dans le navigateur, pour pouvoir lire des musiques, des ebooks, ou simplement des pages web ? Ainsi, ce sera de nouveau une fragmentation du web.
Et vu que ce seront des modules à sources fermées, car tels définis par les normes du W3C (sic), on ne pourra pas savoir ce que traficotent ces modules ; c'est bien pour ça, heureusement, que Mozilla a mis en place une sandbox. Toutefois, il peut toujours y avoir des failles, ou simplement des bugs.
Source depuis le blog de Mozilla, par Mitchell Baker
https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
Voir aussi sur Next INpact :
https://www.nextinpact.com/news/87553-mozilla-jette-eponge-firefox-gerera-drm-des-cette-annee.htm
Citation Numerama :
"Les EME risquent d'empêcher l'enregistrement de vidéos vues depuis un navigateur sans l'utilisation d'un module propriétaire, d'exposer les internautes à des règles potentiellement abusives édictées par les fournisseurs de médias, de nuire à l'interopérabilité, d'entériner l'intégration de logiciels non-libres au sein des standards du web et de pérenniser des modèles économiques oppressants."
Mon avis sur ce sujet :
Personnellement, je suis de leur avis, ce n'est pas leur rôle de bloquer des 4 fers, contrairement à l'EFF qui elle se doit de le faire.
Car à l'état actuel des choses, Chrome (de Google), Saphari (d'Apple) et Internet Explorer (de Microsoft), et sûrement Opéra, intégreront volontiers ce type de fonctionnalités, car chacune de ces entreprises à la tête de ces navigateurs vendent du contenu multimédia sur le web (Youtube de Google et iTunes d'Apple) ; et vous pouvez être sûr que les sites web vendeurs de contenus vont vouloir cette fonctionnalité, pour « protéger » leur marché.
Lorsque Mozilla avec son navigateur Firefox se retrouvera seul à ne pas mettre en place ce système, vous pouvez être sûr que les utilisateurs finaux ne vont pas se priver de changer de navigateur web, réduisant ainsi la part « de marché » du navigateur. Déjà que la concurrence est rude, ça serait vraiment se mettre une balle dans le pied de ne pas suivre.
Ainsi, comme je le disais en entrée, ce n'est donc pas à Mozilla de bloquer complètement, le problème aurait dû être réglé à la source, le W3C n'aurait pas dû imposer cette technologie comme un standard pour HTML5. Mais toutefois, Mozilla fait le bon choix en utilisant un module externe au navigateur, c'est ainsi le meilleur contre-poids à cette mesure.
Merci Mozilla, de penser pour un véritable web ouvert.
Google a récemment été sanctionné par la CNIL française, et doit donc, comme l'indique le site de la CNIL elle-même, afficher le message suivant en page d'accueil (https://www.google.fr/), mais seulement pour 48 heures (début 8 février 2014 UTC) :
Communiqué: la formation restreinte de la Commission nationale de l'informatique et des libertés a condamné la société Google à 150 000 euros d'amende pour manquements à la loi « informatique et libertés ». Décision accessible à l'adresse suivante: http://www.cnil.fr/linstitution/missions/sanctionner/Google/
Diffusons bien plus ce message !
Copie sous forme d'image : http://i.imgur.com/I4EHvwx.png
Plus d'infos : http://www.numerama.com/magazine/28339-google-affiche-sa-condamnation-sur-sa-page-d-accueil.html
Tiens tiens, un avis intéressant sur le mode de développement MVC (Model View Controllers).
Logiciel RandoAmis.Secours (R.A.S) est un service web du type "dead man switch" : avant de partir en randonnée, vous indiquez sur ce service une date d'alerte ; si vous n'avez pas indiqué votre retour sur le service à l'heure de l'alerte, un message d'alerte est envoyé à vos destinataires pour prévenir que quelque chose s'est peut-être mal passé.
C'est plutôt bien comme service, car il permet de prévenir des personnes si vous ne pouvait pas le faire.
Lien direct : http://ivoire.dinauz.org/ras/
Quelques astuces en CSS, en fin de compte très simple, pour centrer correctement des blocks en CSS.
Intéressant, une extension pour Firefox qui permet à sa guise d'activer le "http referer".
Pour info, le "http referer" est une donnée contenant l'url de la page actuelle, envoyée par défaut dans les en-têtes HTTP (les requêtes web), et qui a donc pour principale but d'indiquer la page de provenance, pour tracer ou pour éviter certains accès.
(via Mistukarenai http://root.suumitsu.eu/links/?6HSeuA)
Suite à mon petit article (https://links.thican.net/?OIlYuQ) sur le même principe (des requêtes HTTP), mais en utilisant telnet, voici donc une autre version bien plus propre, avec curl.
Pour rappel :
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Requête GET : curl --include http://${host}:{port:-80}/${url}?{getVars}
Requête POST : curl --include --data ${postVars} http://${host}:{port:-80}/${url}?{getVars}
That's it!
Concrètement, la différence entre telnet et curl, elle se réside uniquement dans votre démarche d'apprentissage et de compréhension.
Si vous voulez apprendre, modifier des données pour faire des tests, avoir un contrôle un peu plus poussé sur vos données, utilisez donc telnet.
Par contre, si vous voulez quelque chose qui fasse son boulot, simplement, avec le moins d'erreurs possible car maintenu à jour, sans prise de tête, tournez donc vers curl.
EDIT: une méthode, plus simple et plus "propre" à utiliser, avec curl : http://links.thican.net/?wGhHkw
Si vous avez besoin de tester un serveur web sans utiliser un navigateur web (pour ainsi mieux voir ce qui est concrètement reçu et envoyé), voici un début d'aide :
On va donc utiliser telnet, un logiciel qui permet simplement de se connecter à une machine distant, sur le port souhaité, et d'envoyer simplement des paquets TCP.
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Pour les requêtes GET, voici donc :
{ echo -n -e "GET /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\n\n"; sleep 0.5 } | telnet ${host} ${port:-80}
Pour les requêtes POST, il faut rajouter l'info de la variable "Content-Type: application/x-www-form-urlencoded" (attention, d'après cette page http://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart-form-data s'il s'agit d'autres formes de données, mieux vaut modifier le contenu de cette variable), voici donc :
{ length=$(echo -n ${postVars} | wc -c --); echo -n -e "POST /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\nContent-Type: application/x-www-form-urlencoded\nContent-Length: ${length}\n\n${postVars}"; sleep 0.5 } | telnet ${host} ${port:-80}
Voilà, c'est tout, simple non ? ;-)
Remarques :
- "Pourquoi le temps de pause dans telnet (sleep 0.5) ?"
Pour des raisons qui m'échappent, telnet va semble-t-il trop vite, et il envoit donc un paquet TCP avec le flag "RST" (Reset), ce qui coupe court le serveur distant, ainsi que l'affichage (même si le serveur distant a envoyé les données, telnet ne les affichera pas). Du coup, il se peut que vous tomber sur ce problème, si le serveur distant est long à répondre (grosse requête, trop de trafic, etc.), il faut donc augmenter le temps de pause. - "Pourquoi mettre un '/' en plus au début dans l'URL ("GET /${url}") ?"
Les '/' en doublon ne sont normalement pas gênants pour accéder à une ressource (essayez donc des URL avec une suite de '/', ça ne devrait pas poser problème). Effectivement, si le serveur distant ne gère pas correctement ces '/' doublons, il risque de râler, mais en tout cas, si le premier '/' est manquant (exemple "GET index.html"), là, c'est sûr, la requête est mauvaise. Donc, autant en mettre trop que pas assez. ;-)