Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ajouter une colonne avec les codes de retour HTTP #6

Closed
bzg opened this issue Oct 14, 2020 · 13 comments
Closed

Ajouter une colonne avec les codes de retour HTTP #6

bzg opened this issue Oct 14, 2020 · 13 comments
Assignees
@bzg

Comments

@bzg
Copy link
Member

bzg commented Oct 14, 2020

A discuter: comment éviter d'ouvrir la porte à trop d'informations supplémentaires pour ces listes ?
@bzg bzg self-assigned this Oct 14, 2020
@bzg bzg mentioned this issue Oct 14, 2020
Merged
@JulienPalard
Copy link
Collaborator

Plus généralement on se posait la question : « Quel schéma de données ? »

Un "besoin" pourrait être d'identifier qui paye le domaine (public ou privé), cf. #26 où des noms de services d'organismes publiques sont sur des domaines privés, àla dommartin25.github.io.

Parmis les données on pourrait plus ou moins facilement ajouter :

  • Via DNS
    • Adresses IPv4 (résolution A), adresses IPv6 (AAAA)
    • Adresses MX
    • Enregistrements TXT
    • NS faisant autorité
  • Via whois
    • AS netname (de chaque adresses IP ?)
    • Date d'expiration du domaine
  • Le contenu de la balise <title>
  • TLS subject organization name
  • TLS validity not after (change environ tous les trois mois pour chaque domaine, ça fait ~300 modifications par jour si on a 30k domaines)
  • trackers : Une liste des trackers, à la exodus-privacy
  • Bureau d'enregistrement (pays, département, ville, nom)

D'un côté j'ai tendance à penser que plus on est exhaustif plus les réutilisations sont faciles, de l'autre je pense qu'il ne faut pas "empièter" sur le travail de wikidata ou des potentielles réutilisations.

@bzg
Copy link
Member Author

bzg commented Mar 25, 2022

Pour l'instant, nous n'avons pas décidé d'un schéma de données particulier.

Du coup, chaque ajout de données en plus du nom de domaine peut être considéré comme une "réutilisation": urls.txt est l'une de ces premières réutilisations, ajoutant de la valeur aux données du répertoire sources (car indiquant une requête HTTP retournant un 200.)

Toutes les infos que tu mentionnes sont peut-être utiles à ajouter, mais je serais prudent avant d'y mettre de l'énergie: pour chaque réutilisation, je propose de se poser ces questions:

  1. Est-ce que la réutilisation (l'ajout de données en plus des noms de domaine) intéresse un acteur (public ou non) ?
  2. Est-ce que la réutilisation (et les scripts qui la permettent) a vocation à être hébergée dans ce dépôt ?
  3. Est-ce que la réutilisation exige que nous fassions évoluer le schéma de donnée du jeu que nous construisons ?

Je donne un exemple pour (3) : je serais pour qu'il y ait, pour chaque nom de domaine, un timestamp indiquant la date à laquelle son existence a été vérifiée et je répondrais "oui" à la troisième question, ce timestamp doit pour moi faire partie du schéma de données pour notre jeu de données.

Pour le bureau d'enregistrement, c'est une réutilisation dont je ne sais pas si elle intéresse un acteur public ou un acteur privé.

Pour le suivi des trackers, je pense que c'est une "réutilisation" qui pourrait justement être confiée à Exodus Privacy ou à la CNIL, s'ils veulent s'en emparer, et qui n'a pas forcément vocation à être hébergée sur ce dépôt.

En clair, je restreindrais ce dépôt à ceci :

  • un jeu de données avec un schéma de données clair (à construire encore) ;
  • des réutilisations (ce jdd avec des infos supplémentaires) dont on sait qu'elles sont directement utiles à des acteurs publics identifiés, en les invitant à contribuer dans ce dépôt ;
  • des liens vers les réutilisations d'autres acteurs, privés ou publics.

@kuczynski
Copy link

kuczynski commented Mar 25, 2022 via email

@villesinternet
Copy link
Contributor

villesinternet commented Mar 25, 2022 •
edited

Je suis d'accord pour rester parcimonieux dans la collecte de données (responsabilité des réutilisateurs) et ne faire entrer dans le schéma que les éléments essentiels.

Ces éléments essentiels sont à mon sens ceux qui contribuent à la définition du corpus, surtout lorsqu'ils sont complexes à "deviner" a posteriori sur la seule base du nom de domaine, alors que l'élément d'information était connu à une étape du processus. L'url de "point d'entrée" est un bon exemple.

Quelque chose est à creuser du côté de la description du domaine pour expliquer sa présence dans le corpus. Aujourd'hui nous faisons confiance aux contributeurs pour placer des fichiers de "sources" pertinentes, cela sera insuffisant dans l'avenir.
La traçabilité de la source sera par ailleurs utile pour des questions de licence (réutilisation de jeux de données ouverts existant) et d'actualisation. À ce stade nous pouvons nous limiter à documenter les fichiers "sources" dans le readme ou un fichier ad hoc, je veux bien faire l'exercice pour proposer un format.

En clair, je restreindrais ce dépôt à ceci :

  • un jeu de données avec un schéma de données clair (à construire encore) ;
  • des réutilisations (ce jdd avec des infos supplémentaires) dont on sait qu'elles sont directement utiles à des acteurs publics identifiés, en les invitant à contribuer dans ce dépôt ;
  • des liens vers les réutilisations d'autres acteurs, privés ou publics.

OK avec ça !
Manque juste le point que j'évoque sur une documentation des sources d'alimentation du repo en noms de domaines, qui sera la base de réflexion pour établir un schéma structuré.

@JulienPalard
Copy link
Collaborator

La traçabilité de la source

Le git log pourrait-il suffire ? Chaque commit commente la source, et indique l'auteur, cf. :

  • f0d83ca Import cities from DILA open data. 2022-03-13 17:44:47 +0100 Julien Palard
  • 40da196 Import from CT logs up to id 6303122465. 2022-03-08 11:29:51 +0100 Julien Palard
  • 2f3b1ed Import cities from Wikidata. 2022-02-15 22:50:31 +0100 Julien Palard

@mfaure
Copy link
Collaborator

mfaure commented Mar 25, 2022

(merci @bzg de m'avoir ajouté ici ! N'hésitez pas à me dire si des points ont déjà été abordé dans une précédente réunion :) )

Je rejoins le souhait de simplicitié pour le schéma.

D'un point de vue technique, et afin de faciliter les réutilisations au sens large, il me semblerait pertinent de poser un identifiant unique sur chaque URL ; et idéalement avec une valeur croissante pour programmatiquement savoir rapidement s'il y eu des ajouts ou pas.

Le timestamp notant la date d'ajout dans le dépôt me semble intéressant. Cela amène à une autre question : organise-t-on à intervalle de temps régulier une vérification de la validatité du jeu de donnée ? Si oui sur quels critères (répond 200 ? répond 30x ? ne répond pas 40x. Quid d'une erreur 500 perdurant dans le temps ? etc).

Plus tard, on pourrait imaginer du SQL pour stocker ces données et faciliter l'application des règles de gestions que nous aurons posées.

Ne ferait-on pas une issue dédiée à la conception du modèle de donnée ? :)

@JulienPalard
Copy link
Collaborator

D'un point de vue technique, et afin de faciliter les réutilisations au sens large, il me semblerait pertinent de poser un identifiant unique sur chaque URL

Une URL étant une URI, par définition c'est déjà un identifiant unique, j'émet un doute sur l'utilité d'ajouter un identifiant unique de substitution à un identifiant unique.

pour programmatiquement savoir rapidement s'il y eu des ajouts ou pas.

git log --stat et wc -l que j'utilise régulièrement sur ce repo me semblent faire le boulot pour savoir rapidement s'il y a eu des ajouts ou des retraits, mais je rate peut-être un cas d'usage ?

Le timestamp notant la date d'ajout dans le dépôt me semble intéressant.

Là aussi, git log ne pourrait-il pas suffire ? Par exemple :

$ git log -S chefdebande.inclusion.beta.gouv.fr
commit 578c2bb52f984de42e00b0197d4731666d94767d
Author: Julien Palard <julien@palard.fr>
Date:   Mon Jan 3 14:03:33 2022 +0100

    A few gouv.fr from certificate transparency logs.

Cela amène à une autre question : organise-t-on à intervalle de temps régulier une vérification de la validatité du jeu de donnée ? Si oui sur quels critères (répond 200 ? répond 30x ? ne répond pas 40x. Quid d'une erreur 500 perdurant dans le temps ? etc).

Pour le moment, non, ce n'est pas organisé. Il m'est arrivé plusieurs fois de supprimer le fichier consolidé puis de le régénérer "from scratch", ce qui élimine les domaines qui ne répondent plus, mais c'est anecdotique.

Le critère actuel d'inclusion dans sources/*.txt est "le domaine est un domaine d'organisme public", et le critère d'inclusion dans urls.txt est "l'URL forgée à partir de ce domaine répond 200 OK en HTTP ou HTTPS".

Plus tard, on pourrait imaginer du SQL pour stocker ces données et faciliter l'application des règles de gestions que nous aurons posées.

En effet, exposer un psql public me semble une solution particulièrement élégante, àla psql -h crt.sh certwatch guest : une API complète en 0 ligne de code.

Ne ferait-on pas une issue dédiée à la conception du modèle de donnée ? :)

Si tu veux (et une autre, dédiée à la routine de re-vérification des domaines ? Et une dernière pour le SQL public ?)

@bzg
Copy link
Member Author

bzg commented Mar 26, 2022 via email

@bzg
Copy link
Member Author

bzg commented Mar 26, 2022 via email

@bzg
Copy link
Member Author

bzg commented Mar 26, 2022 via email

@JulienPalard JulienPalard mentioned this issue Mar 26, 2022
Closed
@villesinternet
Copy link
Contributor

villesinternet commented Mar 26, 2022 •
edited

Le git log pourrait-il suffire ? Chaque commit commente la source, et indique l'auteur, cf. :

C'est un premier niveau qui est effectivement suffisant pour retrouver l'historique.
Par ailleurs les scripts de moissonnage/collecte des domaines depuis certains jeux de données ou API contiennent de facto des informations sur la source (url du jeu de donnée / de l'api) et des mécanismes utilisés pour la collecte (sélections, traitements...).

Sans créer une usine à gaz, un modèle de donnée permettrait idéalement de décrire les sources et méthodes prévalant à la constitution du corpus, pour avoir simplement une vision globale. OK pour creuser ça dans une issue dédiée !

@JulienPalard JulienPalard mentioned this issue Apr 4, 2022
Merged
@bzg
Copy link
Member Author

bzg commented Oct 11, 2022 via email

@JulienPalard JulienPalard mentioned this issue Oct 11, 2022
Open
@JulienPalard
Copy link
Collaborator

Je ferme cette issue : le code de retour HTTP est maintenant stocké dans domains.csv à la racine du repo (à ne pas confondre avec urls.csv qui liste en une seule colonne les URL accessibles (200 OK)).

J'ai ouvert une issue spécifique pour la recherche de la définition de « Noms de domaine d'organismes publics ».

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bzg bzg

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@bzg @JulienPalard @mfaure @villesinternet @kuczynski