C'est le problème du minitel 2.0. Avant il y avait les pages perso fournies par les fai, la plupart du trafic restait local ou national, et on arrivait a peu près a l'équilibre en sortie de réseau. Maintenant on fait appel a un hébergeur spécialisé (ovh, 1&1, ...), on met ses photos et vidéos sur youtube, facebook, flickr, ou autre, et on héberge son blog chez blogspot, wordpress, ...
On a une séparation très nette entre fournisseurs et consommateurs de contenu, je ne vois pas comment les échanges entre réseau pourraient être équilibrés ...

Il ne faut pas confondre le peering, ou 2 AS (en gros une entité légale) interconnectent leurs propres réseaux, sans permettre d'accéder au reste d'internet, et le transit, qui est un genre d'accès internet (IBP). Un fournisseur de transit sert à interconnecter les AS quand il n'ont pas de peering entre eux. Le schéma de wikipedia montre bien la différence : http://en.wikipedia..../Tier_1_network

Concernant youtube/blogspot (alias google), c'est pas trop dans l'intérêt des FAIs d'essayer de leur faire payer le peering. Tels qu'on connait google, ils risquent de claquer la porte en leur disant "bah passez par les fournisseurs de transit si vous pensez que gratuit c'est trop cher". Et hop retour chez cogent, level3 ou autre, et ça risque de faire du bruit ...
Et ils ont déjà essayé : http://morse.colorad.../cogent-ft.html

http://ovh.fr/adsl/

Je suis abonné OVH depuis qu'ils ont lancé leur offre ADSL.

En collecte SFR, donc avant que OVH installent leur propres DSLAM, je constatait des ralentissements en soirée, et quasiment que youtube aussi. En collecte, le traffic est acheminé du modem jusqu'au LNS (concentrateur de sessions PPP) par SFR, et ensuite c'est OVH qui route le traffic. Je ne vois qu'une solution pour ralentir un seul site avec ce genre de configuration : le DPI. Ya pas que free, c'est (presque) tous les opérateurs qui brident.

Par contre, depuis que je suis dégroupé total OVH (ça fait 1 mois), je n'ai constaté aucun ralentissement ...

Le DICOM (le format des images médicales, qui est celui proposé sur son site) est un format ouvert, sans DRM, dont la norme est téléchargeable gratuitement : http://medical.nema.org/ . Le cryptage RSA optionnel décrit dans la norme ne sert qu'a protéger l'identité du patient. La raison de la création de cette norme était de remplacer les dizaines de formats propriétaires utilisés afin de faciliter l'interopérabilité. Tous les imageurs médicaux sont capables d'exporter en DICOM depuis plusieurs dizaines d'années (je travaille chez un fabriquant de dispositifs médicaux). Je l'accorde, la norme est très conséquente, mais traite de beaucoup de domaines médicaux différents.

Il n'a donc pas du avoir trop de problème pour "craquer" les fichiers, car on trouve de grosses quantités de lecteurs DICOM gratuits (et libres) sur internet : OsiriX, xmedcon, aeskulap, ImageMagick ... Et il y a aussi des bibliothèques libres : DCMTK, gdcm, ... Les png ou jpeg sont inexploitables par un médecin, les fichiers originaux sont sur 16 bits et offrent donc une bien meilleure dynamique, et contiennent également de grosses quantités d'informations utiles à l'exploitation des images, encodées dans des "tags".

Et du côté opendata, ce n'est pas non plus une idée nouvelle, on trouve déjà des bases de données d'images patient, comme par exemple http://www.pcir.org/ , et certains hôpitaux ou institutions de recherche offrent des cas cliniques anonymes déjà commentés et annotés par des spécialistes.

Ce qu'il y a de bien aussi, c'est que c'est marqué explicitement dans la norme 3gpp que ça peut être exploité et qu'il est très recommandé d'avertir l'utilisateur si c'est pas le même numéro que l'expéditeur :

3GPP TS 23.040 V6.7.0 Section 9.2.3.24.10.1.17 Reply Address Element :
(MMI=Man-Machine Interface, ME=Mobile Equipment, TP-OA=Originating Address/expéditeur, SM=Short Message)
Despite the fact that MMI aspects of the ME are out of the scope of the present document, it must be mentioned that this mechanism might open the door to potential abuse. It is desirable that the user is made aware in some way that the reply address of the incoming message is different from the originator’s one, and that the user is presented with the original TP-OA address to identify the sender of the SM .

Mais bon apple et les normes, hein ...

Mais effectivement (comme le dit Antwan), pas besoin de ce champ pour spoofer l'expéditeur :
http://www.ovh.fr/sms_et_fax/personnalisation_expediteur.xml

Les opérateurs
honnêtes
demandent la validation du numéro, mais ce n'est pas forcément le cas de tout le monde.

Par contre, pour faire ça en changeant l'expéditeur, il faut avoir un accès direct au SMSC (le serveur mail pour les sms, en gros), car les opérateurs grand public n'autorisent pas n'importe quoi sur le réseau grand public, et l'expéditeur est donc validé. Et ils n'autorisent pas non plus n'importe qui a communiquer directement avec leurs serveurs.
Alors que n'importe qui peut renseigner le champ Reply-Address ...

C'est sur, ca va tout changer :
- chrome : moteur html Webkit + moteur javascript V8
- navigateur android : moteur html Webkit + moteur javascript V8

"le fait que Google puisse croiser ces données avec les adresses MAC collectées par ses services en ligne accroît les craintes"

Il va falloir réviser le fonctionnement des réseaux : les addresses MAC ne circulent pas sur Internet, c'est uniquement sur les réseaux ethernet (802.3 / 802.11), et même si elles circulaient, l'adresse MAC de la carte wifi n'est jamais la même que celle de la carte reliée au réseau du FAI ...