Afin d'avoir le bon contexte pour les réponses plus spécifiques à votre question, il est important de comprendre quel est le but réel des "API privées" :
Pour le comprendre, nous devons savoir ce qu'est une API (Application Programming Interface) : Une API est quelque chose qui permet au développeur d'applications d'invoquer une fonctionnalité mise en œuvre par quelqu'un d'autre. Historiquement, il y avait les programmeurs système qui créaient le système d'exploitation et les bibliothèques système, et les programmeurs d'application qui créaient l'application que les utilisateurs finaux allaient utiliser. Le lien entre eux était l'API.
Aujourd'hui, les API existent sous de nombreuses formes différentes qui servent des objectifs différents :
-
API du système d'exploitation : Par exemple, l'utilisation d'"appels système" qui permettent aux programmeurs qui ne font pas partie du système d'exploitation (c'est-à-dire les programmes de l'espace utilisateur) d'invoquer des fonctionnalités du noyau du système d'exploitation. Sur la plupart des systèmes d'exploitation courants, il s'agit également d'une limite de sécurité (c'est-à-dire qu'il s'agit de l'endroit où les vérifications et les contrôles sont en place pour garantir que seules les fonctionnalités autorisées sont invoquées).
-
Bibliothèque système/API de cadre : Par exemple, le vendeur du système fournit un cadre pour la création d'interfaces utilisateur afin que l'ensemble du système puisse disposer d'un ensemble de widgets reconnaissables (tels que des boutons, des listes, etc.) qui sont dessinés de la même manière dans toutes les applications. Il n'y a généralement pas de limite de sécurité ici.
-
API internes de l'application : Certaines applications sont divisées en bibliothèques/frameworks et possèdent leurs propres API. Il peut s'agir, par exemple, d'une application développée par plusieurs équipes qui se répartissent leurs domaines de responsabilité par le biais de bibliothèques/frameworks. Il se peut aussi qu'une bibliothèque soit créée une fois et utilisée pour de nombreuses applications différentes alors que le développeur souhaite que le code reste séparé pour des raisons de maintenabilité. La bibliothèque peut être développée en interne ou être une bibliothèque open-source partagée par des milliers de personnes. Il n'y a généralement pas de frontière de sécurité dans ce cas.
-
API réseau / Web : Certains systèmes exposent des API par le biais de réseaux, ou plus précisément par le web. Par exemple, Amazon expose une API qui permet aux développeurs d'envoyer une photo de leur application aux serveurs d'Amazon et de recevoir en retour une version OCR (c'est-à-dire du texte extrait de la photo). Il y a généralement une limite de sécurité ici, car ces API Web nécessitent généralement une certaine forme d'authentification pour garantir le paiement ou protéger les informations privées.
Maintenant que nous connaissons les principes de base des API, il s'agit de savoir ce que signifie une "API privée" :
En fait, Apple ne fait pas référence aux "API privées" en tant que telles. Au lieu de cela, elle publie une documentation pour les développeurs qui inclut des références d'API et des fichiers d'en-tête, et elle recommande ensuite aux développeurs de n'utiliser que ces API documentées publiquement. Les soi-disant "API privées" sont en fait ce qu'Apple appelle des "API non publiques".
Il ne s'agit pas d'une invention d'Apple, mais plutôt d'API privées/publiques utilisées dans l'industrie depuis des décennies. Par exemple, historiquement, Microsoft publiait une documentation détaillée à l'intention des développeurs sur la façon d'utiliser son API Windows USER pour créer une interface utilisateur graphique avec divers contrôles, mais son produit Office avait des contrôles privés qui n'étaient disponibles que dans Office, même s'ils existaient dans une API que les développeurs tiers auraient techniquement pu utiliser.
Et nous en arrivons maintenant à l'objectif des "API privées" :
Traditionnellement, les API publiques s'accompagnent d'une promesse (parfois implicite, parfois explicite) selon laquelle ces API ne disparaîtront pas ou ne seront pas modifiées par les développeurs d'applications pendant une longue période. Un développeur pouvait utiliser une API publique et s'attendre à ce qu'elle fonctionne comme indiqué dans la documentation - et qu'elle continue à le faire lorsque le fournisseur publiait des mises à jour mineures et majeures. En général, le développeur pouvait également s'attendre à recevoir un avertissement (appelé avis de dépréciation) lorsque l'API publique qu'il utilisait allait changer ou disparaître dans les années suivantes. De même, les développeurs s'attendaient à pouvoir signaler les bogues de ces API au fournisseur.
En revanche, les API privées ne bénéficiaient pas de ces avantages. Une API privée pouvait disparaître lors d'une mise à jour du système, elle pouvait soudainement commencer à fonctionner différemment (ou pas du tout) - et les développeurs ne pouvaient pas se plaindre auprès du fournisseur des bogues ou des fonctionnalités manquantes.
C'est également de cette manière que les API publiques/privées fonctionnaient sur l'iPhone au début. La raison pour laquelle beaucoup pensent à iOS lorsque vous mentionnez les "API privées" est qu'Apple a ensuite introduit une nouvelle exigence pour la publication d'une application sur son App Store - à savoir que l'application ne doit utiliser que des API publiques. De cette façon, Apple peut mieux s'assurer qu'une application qui a fonctionné l'année dernière continuera à fonctionner l'année prochaine pour les clients qui l'ont achetée sur l'App Store.
Vous pourriez penser que la distinction entre les API "publiques" et "privées" a quelque chose à voir avec la sécurité du système. Ce n'est presque jamais le cas. Dans de nombreux cas, les API se présentent sous la forme d'un exécutable situé dans un fichier de bibliothèque/framework sur le système. Rien n'empêche techniquement le développeur de copier le code de la bibliothèque "privée" dans sa propre application, ce qui en fait une partie de son application et n'est donc plus une API. En fonction de la quantité de code copié, le développeur enfreindrait les droits de copie et éventuellement un accord de licence entre lui et le fournisseur.
En réalité, les API privées sont souvent rendues privées parce qu'elles sont toujours en train de changer. Par exemple, Apple peut avoir une API privée pour une nouvelle pièce de matériel ou un nouvel ensemble de fonctionnalités sur son appareil. À chaque version, cette API change un peu, car les développeurs d'Apple apprennent de leurs erreurs et découvrent la façon dont les utilisateurs interagissent avec leurs propres applications qui utilisent ces fonctionnalités. Plus tard, lorsque l'API a cessé de changer (autant que possible), Apple rend cette même API publique, car elle pense maintenant qu'elle est prête à être utilisée par des développeurs tiers.
Nous en venons maintenant à vos questions plus spécifiques :
-
C'est en partie pour cette raison qu'Apple (et d'autres fournisseurs) n'élimine pas l'élément les symboles des API privées de leurs bibliothèques est principalement qu'alors ils eux-mêmes, ou les partenaires qu'ils ont autorisés à utiliser des API privées, ne pourraient ne seraient pas en mesure d'utiliser facilement ces API dans leurs applications. Apple devrait alors dupliquer toutes les bibliothèques - avoir une version pour eux-mêmes et une autre pour les non partenaires, et s'assurer que la que la bonne version soit mise à disposition dans chaque cas.
Un moyen plus logique pour Apple de restreindre l'utilisation des API privées privée serait de changer le linker dynamique et le système de messagerie entre les objets utilisés en Objective-C et Swift afin de garantir que pour s'assurer que les applications non habilitées ne puissent pas appeler les API privées. Cependant, en plus d'ajouter beaucoup de complexité vraiment inutile, cela s'accompagnerait d'une pénalité de performance non négligeable.
En fait, Apple n'est probablement pas si préoccupée par une développeur qui utilise une API privée - et donc ils s'en tiennent à avoir simplement une directive, en essayant de détecter les utilisations les plus évidentes pour éduquer les les plus évidentes pour éduquer les développeurs, et ensuite ne faire quelque chose publiquement qu'une API privée a été utilisée.
Dans presque tous les cas, l'utilisation d'une API privée aurait pu être remplacée par le développeur d'applications en copiant simplement le code exécutable de la bibliothèque dans sa propre application. de la bibliothèque dans sa propre application - rendant ainsi tout le point de discorde point de discorde. La raison pour laquelle les développeurs utilisent des API privées est souvent pour pour accéder à des fonctionnalités construites par Apple qu'ils n'ont pas le temps de de recréer eux-mêmes, ou pour accéder à une fonctionnalité qu'ils espèrent seront bientôt publiques de toute façon. Il devient alors de la responsabilité du le développeur de s'assurer qu'il n'utilise cette API privée que pour certaines versions du système qui possède effectivement cette API privée - et ils risquent de voir leur application se casser avec les mises à jour du système.
-
Concernant l'affaire Uber : Le vrai problème ici n'est pas l'utilisation d'APIs privées. C'est en fait un bug de sécurité dans le système d'exploitation qui fait que des informations privées ont été exposées à l'application. Le développeur de l'application aurait pu faire la même chose dans son code que l'API privée et il aurait pu avoir accès aux mêmes informations privées. Ce n'est pas bon.
-
Oui, l'analyse automatisée est un jeu de "chat et de souris" - où il est généralement beaucoup plus facile pour le développeur d'applications de faire quelque chose qui obscurcit son utilisation des API privées, et beaucoup plus difficile pour Apple de construire un détecteur. Je ne pense pas que l'utilisation d'API privées soit vraiment un "problème" pour Apple.
