XcodeGhost a profité d'un internet chinois trop lent
« Ignorance et complaisance » c'est par ces deux termes que le PDG d'un éditeur chinois d'apps explique pourquoi des versions d'Xcode trafiquées avec un malware se sont retrouvées entre les mains de développeurs du pays.
« Ignorance de la part d'Apple » explique Andy Tian à Reuters et « complaisance » chez ses homologues où les développeurs ont téléchargé des versions d'Xcode sur des sites situés en dehors du giron d'Apple. Et pour cause, cela revient à prendre l'autoroute au lieu d'un chemin de traverse. C'est la banale et principale explication avancée. Elle figure d'ailleurs dans une FAQ d'Apple sur cette affaire "d'XcodeGhost", publiée à l'entrée de son site en Chine.
D'un côté, il y a Xcode qui pèse pas moins de 3,6 Go. De l'autre, des infrastructures réseau faiblardes, alourdies par le filtrage exercé par le gouvernement, qui rendent ces téléchargement plus fastidieux que partout ailleurs. Selon les mesures d'Akamai (qui assiste des entreprises dans leur distribution de logiciels sur le Net), la vitesse moyenne de connexion en Chine (3,4 Mbps) est trois fois inférieure à celle des États-Unis (la France est entre les deux). Et cela ne va pas en augmentant pour les utilisateurs chinois.
Dès lors, pour couper au plus court, ces développeurs téléchargent leurs outils sur des sites à l'intérieur du pays, puis les partagent parfois sur des supports physiques avec leurs collègues. Si ce n'est qu'il y a le risque de récupérer des logiciels préalablement bidouillés par des malandrins. C'est précisément ce qui s'est passé pour Xcode qui injectait, à l'insu de son utilisateur, un malware dans les logiciels iOS qu'il aidait à fabriquer.
Dave Aitel, directeur de la société de sécurité Immunity, a rebondi sur cette affaire pour raconter son expérience du téléchargement derrière le "Grand Firewall" de Chine :
Nous étions dans le bureau de notre principal revendeur et on ne pouvait pas télécharger les vidéos de présentation de notre logiciel Canvas à plus de 1 ko/s. Notre politique, lorsque nous allons en Chine, est de mettre sur une clef USB toutes les vidéos et fichiers commerciaux dont nous pourrions avoir besoin. Car même récupérer un fichier PDF sur notre site peut être incroyablement lent.
Il cite aussi l'exemple d'un autre de ses logiciels qui avait besoin du player (gratuit) de VMware pour fonctionner. Plutôt que de perdre un temps fou à le télécharger sur le site de VMware, son interlocuteur - dans une très grande entreprise chinoise — est allé sur un site local et a récupéré rapidement un ancien VMware complet et piraté.
S'agissant d'XcodeGhost, il fallait aussi que les développeurs imprudents désactivent l'option dans Sécurité et confidentialité qui évite l'installation de logiciels non signés par l'éditeur original. Ainsi, il y a eu toute une démarche visant à s'affranchir de règles de sécurité élémentaires pour s'épargner des téléchargements interminables.
Cette pratique n'est pas seulement en vigueur chez des éditeurs indépendants disposant d'une connexion internet poussive. Des éditeurs de premier plan, à la tête d'apps iOS énormément populaires, ont utilisé ces Xcode contrefaits.
Hier, Phil Schiller a assuré que les développeurs chinois pourraient à terme obtenir les outils développeurs d'Apple depuis des serveurs installés en Chine : « Aux États-Unis on peut le télécharger en 25 minutes mais ça peut prendre trois fois plus longtemps en Chine ».
D'après le dernier décompte effectué par FireEye, ce sont environ 4 000 apps compilées avec ces Xcode non légitimes qui se sont retrouvées sur l'App Store lestées d'un cheval de Troie. Apple s'en tient à son chiffre de 25 apps touchées — dont elle va bientôt publier la liste — mais tout dépend de la manière de compter.
FireEye semble faire un décompte plus exhaustif. Apple de son côté parle des 25 apps les plus populaire en termes de nombre d'utilisateurs. D'autres que celles-ci sont concernées, cependant leur audience n'atteint pas les mêmes proportions « Après les 25 principales apps concernées, le nombre d'utilisateurs touchés baisse de manière significative », explique la FAQ.
[MàJ] : la liste promise.
Un début de liste d'applications infectées ici :
http://researchcenter.paloaltonetworks.com/2015/09/malware-xcodeghost-infects-39-ios-apps-including-wechat-affecting-hundreds-of-millions-of-users/
Pour les filtrer aux frontières (enfin sur mon firewall chez moi), j'ai cherché les serveurs de Command and Control du bot et j'ai trouvé trois noms de domaine, mais à priori, ces noms de domaine n'existent plus ... Je continue à chercher.
Bon OK :
http://researchcenter.paloaltonetworks.com/2015/09/more-details-on-the-xcodeghost-malware-and-affected-ios-apps/
"Amazon has also taken action, including to shutdown all C2 servers on Amazon Web Services that XcodeGhost was seen to have used to upload privacy information and dispatch controlling commands."
Les malandrins qui sont des bidouilleurs ! Il y a pas a dire c'est les champions du canulars !
Tiens, mais qu'est-ce que j'avançais comme hypothèse dès le premier article ?
https://www.macg.co/logiciels/2015/09/xcodeghost-la-menace-fantome-dans-xcode-91032
Pour avoir été en chine cet été, je peux comprendre vouloir aller un peu plus vite... C'est fou comment tout est bloqué ou lent là bas...
il me semble que sur ce coup j'étais légèrement en avance sur toi.... relis le premier commentaire de l'article.
J'ai pas dis que j'étais le seul ou le premier ;) On a senti que c'était l'explication la plus plausible.
Ha oui, je relance l'autre question que j'avais... Pourquoi Apple ne fait-elle pas de mises à jour incrémentales sur ses propres logiciels... En 2015, il serait un peu temps...
+1
OS X (et iOS par conséquent) sont des logiciels modulaires par definition, il n'y a aucune raison qu'il faille mettre jours l'integralité des modules. Il y a meme des modules qui n'ont pas a changer pendant plusieurs annees: on est sur de l'Unix!
Pareil pour les applications, elle doivent etre conçues de maniere modulaires et seuls certains modules necessitent d'etre modifiés.
Et cela ne date pas de 2015, cette architecture modulaire date de la creation d'Unix, donc les annees 70!
Et pourquoi Apple ne favorise pas la mise en cache local des mise a jour?
Tout ça c'est le probleme de la cloudisation. C'est intéressant pour les éditeurs de pouvoir mettre en captivité l'utilisateur en l'obligeant a se connecter en permanence et passer par le réseau a chaque fois, mais cela a un cout autant énergétique, qu'en temps, en securité et qu'en fonctionnalité!
Rappelons qu'il y a encore quelques années, les logiciels s'installaient a partir de DVD, et que les developpeurs recevaient leurs softs par la poste, et que la situation de l'internet de cette epoque est toujours la réalité dans nombre de pays!
« Aux États-Unis on peut le télécharger en 25 minutes mais ça peut prendre trois fois plus longtemps en Chine ».
Tout ça pour gagner 1h de temps de téléchargement ? Ça choque que moi autant d'incompétence ?
Sauf que depuis que je n'ai plus d'ethernet sur mon ordinateur portable, je ne fais plus les MAJ Apple.
25 min, c'est "possible", 1h je n'ai JAMAIS 1h à consacrer au téléchargement...
Le téléchargement échoue souvent (j'imagine Wifi + mise en veille + Mac OS X = merdouille) et il reprend depuis le début, au lieu de continuer... un enfer !!!
Bref, je ne suis pas en Chine, donc si c'est pire là bas et si c'est un outil pour travailler, je comprends qu'on bidouille (même si de mon côté, je me refuse de le faire).
Les gens ne prennent pas assez en considération que le Wifi (comme tous les reseaux hertzien) ne peut pas assurer un debit et une performance stable. Donc avec le tout Wifi les flux de données peuvent s'alourdir considérablement du fait qu'il faut renvoyer les paquets qui se perdent en route, on a donc un ralentissement et une dépense énergétique supérieure.
Il faut aussi prendre en compte que le WIFI c'est dans les frequences de micro-ondes, donc c'est tres sensible aux interferences (obstables physique - un corps humain, un meuble, de la vapeur d'eau,... et autres emissions sur des frequences proches). Bref ça marche, mais ça marche moins bien qu'un reseau filaire dedié.
Apple a eu l'idée stupide de supprimer le port ethernet de toute ses machines portables. On peut néanmoins utiliser des adaptateurs Thunderbolt - ethernet ou USB-Ethernet.
Apple a aussi la très mauvaise idée de rendre moins facile le déploiement de mise a jours a moins d'avoir OS X server. Il y a la une grosse faille avec les App Store car si l'on considère une famille, et bien on est poussé a charger autant de fois qu'il y a d'appareils les soft...
Avec Yosemite les choses ont même empirées puisque le clonage d'une d'une machine devient rédhibitoire.
Ensuite, lorsque l'on fait une mise a jour il faut la faire en deux phase: téléchargement et sauvegarde du logiciel puis installation. Et pendant ces deux phases il faut que la machine soit relié au secteur et que la mise en veille soit désactivée.
Pour iOS c'est encore plus vrai et l’idéal c'est de passer par iTunes sur son Mac pour les mise a jour, surtout si on a plusieurs machines iOS, comme ça on telecharge une seule fois l'OS...
Il faut aussi comprendre que tres peu de pays offrent un internet illimité, et qu'en amerique, les abonnements sont limités en data: donc 4Go a telecharger ça prend sur l'abonnement!
Mon portable de travail à un port ethernet et j'ai râlé 1000 fois ici sur cette suppression débile sur une machien s'appelant "Pro".
En fait, même mon NAS maison est moins accessible.
Plutôt qu'un adaptateur, je vais plutôt m'achter un hub, mais j'en conclu que le MBP est la moitié de son ancêtre...
Quand à l'écran, j'ai pas eu l'effet whaouhou attendu... Il est "plus beau" mais c'est pas transcendant.
Quand ils disaient que l'Internet était plus lent je m'attendais plusieurs jours pour justifier de prendre Xcode ailleurs, mais même pas ...
Vas en chine, on en reparle...
J'ai fait la mise à jour de iOS 9 : 7 heure d'attente.
Ça ne me gêne pas, je m'y attendais. Je fais la mise à jour de nuit tranquille ...et je suis en France.
Avoir un réseau lent ne devrait pas excuser cette énorme incompétence.
Certaines personnes devraient perdre leur poste, et je doute que ça soit des développeurs de haut niveau.
« S'agissant d'XcodeGhost, il fallait aussi que les développeurs imprudents désactivent l'option dans Sécurité et confidentialité qui évite l'installation de logiciels non signés par l'éditeur original. Ainsi, il y a eu toute une démarche visant à s'affranchir de règles de sécurité élémentaires pour s'épargner des téléchargements interminables. »
Là, il ne s’agit même plus de règles de sécurité élémentaires.
En effet, en voyant que cette version de Xcode n’était pas signée par Apple (d’où la nécessité de signifier explicitement à GateKeeper qu’il fallait l’ouvrir tout de même), ces développeurs savaient donc parfaitement qu’il s’agissait d’une version modifiée.
L’avoir utilisée malgré tout, c’est du foutage de gueule, un manque total de respect envers les utilisateurs de leurs applications.
@BeePotato
+1
Il y a ce que l'on veut que les gens pensent, ce qu'il faut absolument éviter que la population sache et donc ce que l'on veut bien dire...
Le coup de l'internet trop lent, c'est une belle histoire en effet -vraie en partie- et ça arrange pas mal de monde.
Mais il faut considérer que dans les usines de codeurs et entreprises de plus de 10 employés, l’installation des softs se fait en interne (déploiement), par l'administrateur, et le téléchargement des soft originaux se fait donc 1 seule fois en externe...
Ce n'est donc pas chaque développeur sur son poste qui va telecharger les soft depuis le réseau externe...
Affirmer le contraire reviendrait a affirmer que le reseau chinois (ou indien, ou malaisien, ou...) est ultra rapide et performant!
La liste est disponible sur le site chinois d'Apple!
Jamais entendu parlé de ces apps, sans d'outre propre au marché chinois.
Vous n'aviez pas mentionné Angry birds 2?
Sacrifier sa propre sécurité et celle des utilisateurs pour gagner quelques minutes de chargement...
C'est stupide et non professionnel.
La mise à jour des outils de production est une phase délicate qui se planifie un minimum.
«La mise à jour des outils de production est une phase délicate qui se planifie un minimum.»
+1
Mais il faut aussi regarder la responsabilité d'Apple.
Apple cultive le secret et a des secrets industriels qui ne transpirent pas. Cela est renforcé par l'ampleur de l'entreprise et de sa croissance: d'ici noël Apple devrait écouler plus de 100 millions d'iPhone 6,... c'est pas aussi facile a sécuriser que 3.5 millions de machines.
Je vais prendre 2 exemples.
Le premier c'est le passage au PowerPC.
Le travail a ete fait avec IBM et Motorola.
plus de 2 ans avant l'annonce des machines les premiers développeurs tiers ont eu acces au systeme de développement sur des prototypes pour tester en conditions réelles leurs soft. Puis le secret a ete divulgué aux développeurs référencés Apple a peu prés un an avant la disponibilité du matériel a la vente, les dev pouvant s’équiper avant cette date.
Le second c'est l'Apple Watch. Apple a mis un énorme secret sur tout ce qui est technique, au point que les développeurs ont decouvert la tocante lors de sa mise officielle sur le marché et ont du se contenter d'un simulateur logiciel quelques temps avant l'annonce du matériel. Et encore l'OS était loin d’être finalisé.
Il est probable que les bureaux de marketing et les annonceurs aient été informés mieux et plus tôt que les développeurs.
La conséquence c'est que lorsque l'Apple watch a été officiellement mis en vente, les developpeurs ont du se jeter dessus pour tester reellement leurs applications...
Et la pression qu'ils ont eu a été très forte vu les sommes extraordinaires qu'Apple a investit en marketing sur ce produit. Pour un dev iOS c'etait donc incontournable.
En conséquence, il y a une pression aujourd'hui pour le développeur de produire toujours plus vite malgré des moyens et des informations toujours plus limités. Et les éditeurs sous-traitent de plus en plus en Chine, ce qui empire la situation.
Aucun pression ne justifie de prendre de tels risques : il est question de quelques minutes voir d'une poignée d'heures pour obtenir l'outil de développement qui est la pièce centrale du dispositif.
Ensuite une fois l'application soumise la date de sortie dépend de la validation d'Apple dont la durée est une inconnue.
La responsabilité est entièrement du côté des développeurs.
@Domsware :
Et non les responsables c'est bien Apple
De plus, Apple dit avoir fait en sorte que le téléchargement de Xcode (version officielle) soit plus rapide en installant des serveurs sur le sol chinois – permettant aux développeurs d’y accéder plus facilement.
Merde Hymalaya FM est touché, qu'est-ce que je vais pouvoir écouter maintenant ?!!
Après réflexions, cette histoire sent plus la proof of concept qu'autre chose.
Si les développeurs de ce malware avaient voulus faire plus de mal, ils y seraient arrivés sans problèmes.
Les prochains mois risquent d'être très drôles ...
@oupsman
«proof of concept»...
Difficile d'y croire.
La démonstration d'une nouvelle technique d'exploitation de hacking se fait de manière académique et par des chercheurs en sécurité. Aucun n'aurait ete assez inconscient pour faire ce a quoi on assiste.
On pourrait penser qu'il s'agit d'une evalutation de la propagation d'une version vérolée en amont. Mais cette evaluation aurait du se faire en mode furtif, la c'est pas le cas.
Reste le cas de la decouverte d'une porte derobée installé par ou pour la NSA qui a été exploité par des hackers. Et la on peut penser qu'il sagit d'une des trois possibilités suivante:
-c'est un coup des anonymous ou groupe equivalents pour démontrer les danger des portes dérobées.
-c'est le travail d'amateurs qui ont exploité un truc qui les dépasse et qui n'avaient pas de faille complémentaire pour faire un truc vraiment méchant.
-c'est le travail d'un groupe qui veut uniquement nuire a Apple.
Le second cas est assez intéressant parce qu'il démontre que même si on peut injecter un troyen dans une applications "officielle" il reste limité a ce qu'une applications peut faire, - donc ce que l'OS permet et ce que l'utilisateur permet - et qu'Apple a bien cloisonné et sécurisé iOS de ce point de vue.
Apple pourrait faire comme Microsoft dans ces cas la et financer massivement une enquete dirigée par le FBI. Mais si derriere cette histoire il y a les doigts crochus de la NSA, alors l'histoire sera simplement ettoufée et la version officielle restera qu'il s'agit la juste d'un faille humaine et limitée a la Chine
Et voilà le retour de la bonne vieille théorie du complot :(
Par contre :
"Le second cas est assez intéressant parce qu'il démontre que même si on peut injecter un troyen dans une applications "officielle" il reste limité a ce qu'une applications peut faire, - donc ce que l'OS permet et ce que l'utilisateur permet - et qu'Apple a bien cloisonné et sécurisé iOS de ce point de vue."
(re)lis les liens que j'ai donné dans le premier commentaire (en anglais, my bad). L'infection a été découverte parce que l'iPhone persistait à demander les identifiants iCloud, alors que l'application active n'était pas censée y accéder. Cette attaque prouve (encore et toujours) que la principale faille de sécurité sur un système, est l'utilisateur.
ça prouve d'abord ce que je dis -> sur iOS l'application est bien cloisonnée et qu'elle ne peut pas accéder a n'importe quoi sans la validation de l'utilisateur...
Cela prouve aussi que la volonté du programmeur était d’accéder a iCloud mais qu'il ne disposait pas d'une faille pour contourner la protection de l'OS.
Cela prouve aussi qu'iOS étant très sécurisé le nouvelle cible de prédilection c'est le cloud, car il est évident que lui est moins sécurisé que l'OS et les informations internes. Donc on peut s'attendre a l'avenir a des attaques de plus en plus pernicieuses et massives des cloud...
Quant a la théorie du complot, ce n'est pas une theorie, le principe du verolage de Xcode est un projet dénoncé par Snowden. La probabilité est chaque jour plus forte que ce système ait été mis en place et qu'il ait été découvert et exploité par des hacker, et que ce que l'on voit ici c'est juste la conséquence de cela.
La volonté du programmeur de ce malware est voler des données personnelles. Imagine un framework verrolée qui se greffe sur une app quand elle propose des achats inapp et qui t'envoie sur une fausse interface pour saisir ton numéro de CB ?
C'est bon, tu saisis la portée du problème ?
Je ne parle pas ici que de Xcode mais de framework de jeux par exemple (Unity est une cible potentielle)
Concernant ton dernier paragraphe ... je m'attache aux faits et j'essaye de rester réaliste dans ce que cela peut impliquer. Toi, tu extrapoles vers des probabilités qui sont ... irréalistes et qui relèvent des fantasmes des partisans de la théorie du complot, ou tous les états nous espionnent. Comme si ils avaient besoin de cela pour le faire. C'est juste risible.
@ oupsman : « Imagine un framework verrolée qui se greffe sur une app quand elle propose des achats inapp et qui t'envoie sur une fausse interface pour saisir ton numéro de CB ? »
Notons que cet exemple ne bernerait que des utilisateurs n’ayant aucune connaissance du fonctionnement normal des achats in-app. L’expérience prouve qu’il y a bien du monde qui tomberait dans le panneau, mais ce ne serait tout de même pas une menace à grande échelle.
« C'est bon, tu saisis la portée du problème ? »
Juste un conseil : tu devrais arrêter avec la forme « c’est bon, tu saisis/compris ? ». Ça donne une très forte impression d’arrogance et de mépris envers ton interlocuteur, impression qui n’incite pas à poursuivre la conversation. M’enfin, ce n’est qu’un conseil. :-)
@ C1rc3@0rc : « Quant a la théorie du complot, ce n'est pas une theorie, le principe du verolage de Xcode est un projet dénoncé par Snowden. La probabilité est chaque jour plus forte que ce système ait été mis en place et qu'il ait été découvert et exploité par des hacker, et que ce que l'on voit ici c'est juste la conséquence de cela. »
Euh, non, là ce n’est pas ça. Il n’y a eu aucune porte dérobée ni aucun programme secret de découvert.
Ce qui a été fait s’apparente bien plus à une variante de ce qu’on appelle d’habitude l’ingénierie sociale. Quelqu’un a juste profité de la naïveté/cupidité/stupidité de certains utilisateurs de Xcode pour les conduire à en télécharger une version modifiée par ses soins. Pas besoin d’être la NSA pour ça — en revanche, pour arriver à le faire à grande échelle comme ça a été fait, il fallait le concours de circonstances un peu spéciales qu’on ne trouve qu’en Chine.
Le projet que tu évoques, pour se réaliser de manière efficace, aurait besoin d’être bien plus sophistiqué, puisqu’il faudrait soit modifier Xcode avant sa distribution par Apple, soit le modifier ensuite (mais tout aussi discrètement) sur toutes les machines des développeurs. C’est bien plus difficile que ce qui a été fait là.
@ oupsman : « Les prochains mois risquent d'être très drôles ... »
Ah ? Pourquoi ?
Parce que si ce machin était réellement un « proof of concept », ses auteurs ont grillé bêtement leur meilleure cartouche. Maintenant que tout le monde a été sensibilisé à ce risque, il me semble difficile de frapper à une aussi large échelle avec cette approche avant au moins quelques années (et encore, c’est en imaginant que les conditions de réalisation soient encore là — si le téléchargement depuis les serveurs d’Apple s’accélère vraiment pour les Chinois, il n’y aura vraiment plus grand monde à qui faire télécharger facilement un Xcode trafiqué).
@BeePotato :
Le malware court depuis avril ... Qui te dis qu'entre temps, les développeurs n'ont pas créés un truc plus furtif ?
@ oupsman : Un truc plus furtif qui ne reposerait pas sur la même approche, donc ?
Mais du coup, ça ne serait plus lié à ce « proof of concept ».
Si ce n’est pas ça, j’avoue que je ne comprends pas bien l’idée du truc plus furtif auquel tu fais référence. :-(
Bon ben on va expliquer le concept de POC :
les développeurs de ce malware créé leur attaque et la publie. On est en Avril. Puis, ils observent pendant 1 mois ce qui se passe. Ca c'est leur POC.
Constatant avec plaisir que ça marche, ils injectent une autre attaque dans leur version de Xcode, attaque plus méchante mais aussi plus furtive.
C'est bon, t'as compris là ?
On a détecté la première attaque qui n'était pas bien méchante, mais ça m'inspire plus un truc de type "arbre qui cache la forêt" qu'autre chose.
@ oupsman : « C'est bon, t'as compris là ? »
Non, parce que ton explication est bien gentille mais ne répond nullement à ma question, qui portait sur la nature de cette autre attaque « plus méchante mais aussi plus furtive ».
Parce que vu que le mode de déploiement du malware a été éventé et que les applications infectées ont été remplacées par des versions compilées avec une version saine de Xcode, je ne vois pas quelle est cette attaque furtive qui peut encore être réalisée de cette façon.
Attention, je ne dis pas qu’il ne peut pas y avoir d’autres types d’attaques — juste que, comme elles seront justement d’un type différent, on ne peut pas trop voir XcodeGhost comme un « proof of concept » pour elles (à moins qu’on ne considère qu’il ne prouve que le concept très large d’attaque par infection de logiciels, mais on ne l’a pas attendu pour prouver la viabilité de ce concept-là ;-) ).
Ben un autre malware injecté de la même manière dans d'autres versions de Xcode qui n'ont pas encore été auditées.
Je suis surpris que Xcode 7 ne soit pas infecté, par exemple.
Et je suis surpris que les applications OS X ne soient pas concernées non plus.
@ oupsman : « Ben un autre malware injecté de la même manière dans d'autres versions de Xcode qui n'ont pas encore été auditées. »
Ah, ok. En fait, tu parles d’une attaque qui aurait déjà été réalisée (mais pas encore découverte), donc, et pas d’un truc à venir, c’est bien ça ?
Jusque là je pensais que tu parlais d’une future attaque suivant le même mode, et c’est ça qui me paraissait bien peu probable. Maintenant, je vois (ou crois voir) ce que tu veux dire.
Et dans ce cas, effectivement, les auteurs auraient disposé de quelques mois pendant lesquels ils auraient pu profiter de ce que ce second malware aurait récupéré comme données.
Cependant, on peut au moins se dire que, si ce second malware existe bien, il aura probablement fini sa vie en même temps que le premier, à l’occasion d’un retour de ces développeurs à l’usage de la version officielle de Xcode.
Comment garantir que les développeurs utiliseront uniquement la version officielle de Xcode ?
@ oupsman : « Comment garantir que les développeurs utiliseront uniquement la version officielle de Xcode ? »
On ne le peut pas, mais après cet épisode on peut espérer qu’il y en ait beaucoup moins qui passent par une autre version. Au moins pour quelque temps, avant peut-être que les mauvaises habitudes ne reviennent.
Mais Apple peut beaucoup aider en mettant en place un moyen de le télécharger réellement rapidement depuis la Chine. Dans ce cas, la motivation d’utiliser une version récupérée ailleurs disparaîtra, et le parc installé se nettoiera au fur et à mesure des mises à jour.
@ oupsman
J’ai oublié de répondre à cette partie : « Et je suis surpris que les applications OS X ne soient pas concernées non plus. »
À mon avis, la raison est simplement qu’il n’y avait pas de gros gain à attendre de ce côté-là.
D’une part, parce qu’il y a énormément moins d’utilisateurs de Mac OS que d’utilisateurs d’iOS, avec, de plus, une proportion d’utilisateurs « informatiquement incultes » (donc plus susceptibles d’autoriser une application à faire ce qu’elle n’aurait normalement pas besoin de faire) plus faible sur Mac.
D’autre part, parce qu’il y a beaucoup moins d’applications pour Mac OS qui accèdent aux données personnelles de type contacts ou autre trucs de ce genre — ça, c’est quelque chose qui se rencontre naturellement beaucoup plus dans l’usage d’un smartphone que celui d’un ordinateur.
Pour en revenir à la situation d'Internet en Chine, pas mal de sites n'ont même pas besoin d'être filtrés par la Grande Muraille Pare-feu, ils ne chargent tout simplement pas (timeout).
D'ailleurs, ça marche aussi dans les 2 sens, beaucoup de sites chinois mettent un temps délirant à charger quand ils sont accédés depuis l'étranger.
Voici les apps en question mises en lumière par Apple :
WeChat
58 Classified
Angry Birds 2
Baidu Music
Battle of Freedom
Call Me MT 2
CarrotFantasy
CarrotFantasy 2
China Unicom Customer Service
Dark Dawn
DiDi Taxi
DuoDuo Ringtone
Encounter
Flush
Flush HD
Foreign Harbor
Gaode Map
Heroes of Order & Chaos
Himalaya FM
I Like Being With You
Let’s Cook
Miraculous Warmth
NetEase Music
One Piece
Railroad 12306
Désormais, ces apps ne sont plus disponibles au téléchargement, le temps pour Apple et les développeurs de trouver une solution qui convienne à tout le monde. Sans aucun doute, les devs vont devoir retravailler leurs apps avant qu’Apple ne les valide rapidement.