J'avais constaté ce bridage sur une clé 3G+ SFR fin 2012.
Le proxy transparent utilisé est celui conçu par l'entreprise ByteMobile, il est également utilisé par de nombreux opérateurs à l'international (Vodafone, O2...).
Quelques une des modifications effectuées sur les pages web :
- Remplacement des retours à la ligne par des espaces. J'avais trouvé ça complètement stupide, dans les deux cas ça fait un octet...
- Modification des headers HTTP liés au cache. Résultat : comportements non-voulus sur de nombreux sites lors de l'utilisation de la touche F5, ou de l'envoi de formulaires.
- Modification des balises <img> pour faire passer les images par un proxy transparent correspondant à une adresse IP SFR. Sale.
- Injection d'un fichier JS hébergé sur http://1.2.3.4/. Il modifiait notamment les paramètres des lecteurs vidéo YouTube.
- Fusion du code JavaScript des fichiers .js avec les .html, ce qui au final alourdissait les pages et augmentait la bande passante à partir du moment où on chargeait plusieurs pages sur le site web, complètement stupide ici aussi car l'effet inverse de ce qui était recherché était produit.
- Il y avait aussi probablement de la recompression d'images, je n'avais pas vérifié.
Pour contourner cette immondice, j'avais trouvé une solution : ajouter le header
Cache-Control: no-transform aux requêtes HTTP, en utilisant une extension navigateur ou bien un proxy local. Cela permettait d'être ignoré par le proxy ByteMobile.
De mémoire, cela fonctionnait aussi bien si le header était envoyé côté client, que s'il l'était client serveur, donc webmasters, si vous souhaitez que votre site ne soit pas souillé par ce genre de proxy, la première chose à faire est d'ajouter une ligne à votre .htaccess (ou équivalent si vous êtes sous nginx/lighttpd/autre) pour que ce header soit envoyé dans chaque réponse.