Mon blog

L'Internet est aujourd'hui un service indispensable à toutes les activités humaines. Un accès correct à ce réseau est donc crucial. Mais plusieurs problèmes limitent l'accès à l'Internet ou à plusieurs de ses services. L'IAB avait organisé en janvier 2024 un atelier sur cette question, atelier dont ce RFC est le compte-rendu.

Trois thèmes principaux étaient à l'agenda de cet atelier, qui s'est tenu entièrement en ligne : l'état de la fracture numérique, le rôle des réseaux communautaires et la question de la censure. Oui, il y aurait eu plein d'autres thèmes possibles (comme les difficultés d'accès aux services en ligne, par exemple parce que leur utilisation est anormalement difficile) mais en trois jours d'atelier, ce n'est déjà pas mal.

Comme tous les ateliers de l'IAB, celui-ci a fonctionné en demandant aux participants des position papers expliquant leur point de vue. Ne participent à l'atelier que des gens ayant écrit un de ces articles, ce qui garantit que tout le monde a dû travailler le sujet. Ces articles sont disponibles en ligne.

Le RFC commence en rappelant que, dans une société où tout se fait via l'Internet, ne pas avoir accès à l'Internet, ou bien n'avoir un accès que dans de mauvaises conditions, est une discrimination inacceptable. Le RFC insiste sur ce deuxième point : aujourd'hui, le problème n'est plus uniquement l'absence totale d'accès Internet, c'est souvent l'accès de mauvaise qualité (liaison trop lente, intermittente, ordinateur trop lent pour les sites Web modernes surchargés de gadgets, censure, etc). L'atelier de l'IAB visait à :

• récolter des informations sur les diverses inégalités d'accès,
• mieux comprendre les différentes façons dont les gens accèdent à l'Internet (et pas uniquement dans les pays riches),
• et ce que veut dire « être connecté à l'Internet » pour les utilisateurs, quels sont leurs usages et leurs exigences.

Le premier jour, l'atelier a surtout travaillé sur les réseaux dits « communautaires » (terminologie très étatsunienne, je m'excuse mais c'est celle du RFC). Ces réseaux bâtis localement par leurs utilisateurices, sans but lucratif, sont décrits plus en détail dans le RFC 7962 et un groupe de recherche IRTF existe, GAIA. Le plus connu et le plus souvent cité est Guifi. Ces réseaux communautaires souffrent de divers problèmes, dont bien sûr le coût élevé du transit, qui est nécessaire pour joindre le reste de l'Internet. Une des pistes évoquées était l'installation des CDN dans ces réseaux communautaires, pour limiter l'utilisation du transit. Cette piste était par exemple citée dans cette intervention, dont on notera qu'un des auteurs travaille pour un CDN, qui a par ailleurs un projet caritatif pour les réseaux communautaires. Opinion personnelle : c'est très discutable, les CDN ne servent qu'à la consommation passive de contenu et, pire, renforcent le contenu déjà très populaire.

L'accès au transit peut se faire par liaison terrestre fixe mais aussi par satellite, les satellites en orbite basse (LEO) étant actuellement en plein développement. Notez que cela ne résout pas les problèmes de contrôle, comme l'a montré la coupure de l'Ukraine par Starlink.

Le RFC note aussi un problème social : les opérateurs des réseaux communautaires sont peu présents à l'IETF et donc leurs questions et problèmes ne sont pas forcément bien pris en compte dans la normalisation technique.

Autre sujet, le deuxième jour, la fameuse fracture numérique. Comme dit plus haut, elle ne se réduit pas au fait de ne pas avoir d'accès du tout, problème qu'on pourrait régler en posant de la fibre optique. Il y a aussi une fracture entre celleux qui accèdent à l'Internet dans de bonnes conditions et celleux qui sont du mauvais côté de la fracture. Des bonnes conditions, cela concerne à la fois la technique (liaison rapide et fiable) mais aussi la maitrise de son activité en ligne (ne pas être dépendant des GAFA, par exemple, ce que le RFC ne mentionne guère).

À l'atelier, Holz a par exemple étudié les serveurs DNS faisant autorité pour divers domaines australiens et montré que les organisations indigènes étaient nettement moins bien servies.

Les différentes personnes vivant sur Terre parlant de nombreuses langues différentes, la question de la possibilité de chacun·e d'utiliser sa langue a toute sa place dans toute discussion sur les inégalités d'accès. D'où l'exposé de Hussain sur le projet Universal Acceptance de l'ICANN, qui vise à faire en sorte que, par exemple, les noms de domaine en Unicode soient acceptés partout. Actuellement, si le travail de normalisation est largement fini, le déploiement effectif est loin d'être complet. (Opinion personnelle : cette question de l'acceptation universelle des TLD ICANN en Unicode n'est qu'une toute petite partie de la question des langues sur l'Internet.)

Il y a aussi le problème des performances : bien des sites Web modernes sont développées par une personne riche et bien connectée, munie d'un ordinateur rapide. Ils sont souvent pénibles à utiliser lorsque la liaison est lente et/ou la machine de l'utilisateur un peu ancienne. (Et, dans mon expérience, les remarques aux développeurs Web sur ce point sont souvent accueillies par des remarques méprisantes.) L'étude de Habib et al. analyse très bien ce problème, notamment pour les pays « du Sud » (et propose une solution technique mais, quoi qu'on pense de cette solution, l'étude reste très pertinente). Sinon, le RFC n'en parle pas, mais ce problème est une des motivations du projet Gemini.

Gros morceau pour la troisième session, la censure. C'est évidemment un des principaux obstacles sur la route des utilisateurices. Ainsi, le projet iMAP (rien à voir avec IMAP) a documenté la censure dans plusieurs pays asiatiques, notamment en utilisant les sondes OONI. De nombreuses techniques différentes sont utilisées, par exemple des résolveurs DNS menteurs, ou bien, plus sophistiqué, une interférence avec les connexions HTTPS, utilisant le SNI pour repérer le site visité. Parfois, l'utilisateurice est redirigé·e vers une page expliquant le blocage (comme je l'avais vu il y a déjà seize ans à Dubaï, la censure n'est pas une invention récente). Parfois, la censure est plus hypocrite et ne s'avoue pas comme telle.

Une autre étude détaillée est celle de Grover, portant notamment sur l'Inde et le Pakistan. Il insiste notamment sur le caractère inégal de la mise en œuvre de la censure, bien des ressources n'étant bloquées que par certains FAI.

Évidemment, en Russie, la guerre avec l'Ukraine est le prétexte pour un durcissement considérable de la censure. Basso l'a étudié avec OONI. Notez que son étude montre des domaines bloqués sans être pour autant sur la liste officielle de blocage.

Comme la censure, comme dans ce cas russe, est souvent hypocrite, voire dissimulée, il y a beaucoup de travail à faire du point de vue technique pour l'analyser. C'est ainsi que Wang et al ont présenté les solutions utilisables pour cela. (Et le problème est complexe !)

Tous les intervenants sur la question de la censure ont insisté sur l'importance de l'information des utilisateurices, souvent laissé·es délibèrement dans le noir sur les raisons d'un blocage ou même sur sa simple existence. Les solutions normalisées existantes pour cela incluent le code de retour 451 de HTTP (normalisé dans le RFC 7725) ou les codes EDE, notamment le code 16, pour le DNS (normalisés dans le RFC 8914). Voici deux exemples, respectivement par Google et par Cloudflare, vus en juillet 2024, à propos de la censure en France de sites qui diffusent des spectacles sportifs en violation des intérêts financiers des entreprises comme Canal+ :

% dig @8.8.8.8 tarjetarojatvlive.net
…
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7912
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41939614.)
…
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Jul 03 10:34:44 CEST 2024

  

% curl -v jokersportshd.net         
…
* Connected to jokersportshd.net (2606:4700:3034::6815:5b9) port 80 (#0)
> GET / HTTP/1.1
> Host: jokersportshd.net
> User-Agent: curl/7.81.0
> Accept: */*
…
< HTTP/1.1 451 
< Date: Wed, 03 Jul 2024 08:36:59 GMT
< Content-Type: text/html
…
<!DOCTYPE html><html class="no-js" lang="en-US"> <head>
<title>Unavailable For Legal Reasons</title> 
…
<p>This website is unavailable for legal reasons.</p><p>Please see <a
rel="noopener noreferrer"
href="https://lumendatabase.org/notices/42038946"
target="_blank">https://lumendatabase.org/notices/42038946</a> for
more details.</p>
..

  

(Il y aurait aussi le RFC 6108, mais il est aujourd'hui techniquement dépassé.) Les mécanismes standardisés pour signaler une censure sont peu utilisés aujourd'hui, et les explications sont rares.

Notons que rediriger les utilisateurs vers une page Web d'information leur annonçant qu'ils ont été bloqués (comme le fait en France la Main Rouge) est dangereux : cela permet au gestionnaire de la page en question de voir l'adresse IP (et d'autres informations envoyées par le navigateur) du visiteur ou de la visiteuse. En France, le ministère de l'Intérieur avait ainsi supprimé les données récoltées… après avoir juré qu'il n'en récoltait pas !

Qui dit censure dit évidemment contournement, car les utilisateurices ne vont pas rester les bras ballants face aux mesures de blocage. Ont été discutés à l'atelier les VPN, par exemple, y compris leurs problèmes actuels (cf. l'excellente étude de Ramesh sur les VPN et leurs limites, à lire la prochaine fois qu'un youtubeur vous fera la pub de NordVPN).

Voilà, maintenant, il y a du travail pour des groupes IRTF comme GAIA, HRPC, PEARG, et MAPRG (section 2.4 du RFC, sur le travail à faire).