Para tener el contexto adecuado para las respuestas más específicas a su pregunta, es importante entender cuál es realmente el propósito de las "APIs privadas":
Para entenderlo debemos saber qué es una API (Application Programming Interface): Una API es algo que permite al desarrollador de aplicaciones invocar una funcionalidad implementada por otro. Históricamente, había programadores de sistemas que creaban el sistema operativo y las bibliotecas del sistema, y había programadores de aplicaciones que creaban la aplicación que usarían los usuarios finales. El vínculo entre ambos sería la API.
Hoy en día, las APIs existen en muchas formas diferentes que sirven para diferentes propósitos:
-
APIs del sistema operativo: Por ejemplo, el uso de "llamadas al sistema" que permiten a los programadores que no pertenecen al sistema operativo (es decir, a los programas del espacio de usuario) invocar funciones dentro del núcleo del sistema operativo. En la mayoría de los sistemas operativos comunes, este es también un límite de seguridad (es decir, es el lugar donde se realizan las comprobaciones y los controles para garantizar que sólo se invoca la funcionalidad permitida)
-
Biblioteca del sistema/Apis del marco: Por ejemplo, el proveedor del sistema suministra un marco de trabajo para crear interfaces de usuario de manera que todo el sistema pueda tener un conjunto de widgets reconocibles (como botones, listas, etc.) que se dibujan de la misma manera en todas las aplicaciones. Aquí no suele haber límites de seguridad.
-
APIs internas de la aplicación: Algunas aplicaciones se dividen internamente en bibliotecas/marcos y cuentan con sus propias API. Puede tratarse, por ejemplo, de una aplicación desarrollada por varios equipos que dividen sus áreas de responsabilidad a través de bibliotecas/marcos, o puede ser que una biblioteca se cree una vez y se utilice para muchas aplicaciones diferentes, mientras que el desarrollador desea que ese código permanezca separado por razones de mantenimiento. La biblioteca puede ser desarrollada internamente o puede ser una biblioteca de código abierto compartida por miles de personas. Aquí no suele haber límites de seguridad.
-
Red / Web APIs: Algunos sistemas exponen APIs a través de redes, o más concretamente a través de la web. Por ejemplo, Amazon expone una API que permite a los desarrolladores enviar una foto desde su aplicación a los servidores de Amazon y recibir de vuelta una versión con reconocimiento óptico de caracteres (es decir, texto extraído de la foto). En este caso suele haber un límite de seguridad, ya que estas API web suelen requerir algún tipo de autenticación para garantizar el pago o proteger la información privada.
Ahora que ya tenemos los fundamentos de las APIs, lo siguiente es saber qué significa una "API privada":
De hecho, Apple no se refiere a las "API privadas" como tales. En su lugar, publican documentación para desarrolladores que incluye referencias a las API y archivos de cabecera, y luego recomiendan a los desarrolladores que sólo utilicen esas APIs documentadas públicamente. Las llamadas "API privadas" son lo que Apple denomina en realidad "API no públicas".
No es un invento de Apple, sino que las APIs privadas/públicas se utilizan en la industria desde hace décadas. Por ejemplo, históricamente Microsoft publicaba una amplia documentación para desarrolladores sobre cómo utilizar su API de Windows USER para crear una interfaz gráfica de usuario con diversos controles, pero su producto Office tenía controles privados que sólo estaban disponibles en Office, aunque existían en una API que los desarrolladores de terceros podían utilizar técnicamente.
Y ahora llegamos al propósito de las "APIs privadas":
Tradicionalmente las APIs públicas vienen con una promesa (a veces implícita, a veces explícita) de que estas APIs no desaparecerán o cambiarán por debajo de los desarrolladores de aplicaciones durante mucho tiempo. Un desarrollador podía utilizar una API pública y esperar que funcionara tal y como estaba documentada, y que siguiera haciéndolo cuando el proveedor lanzara actualizaciones menores y mayores. Por lo general, el desarrollador también podía esperar recibir una advertencia (un llamado aviso de depreciación) cuando la API pública que estaba utilizando cambiara o desapareciera en los años siguientes. Del mismo modo, los desarrolladores esperaban poder informar al proveedor de los errores de estas APIs.
En cambio, las API privadas no gozaban de estas comodidades. Una API privada podía desaparecer en una actualización del sistema, su funcionamiento podía empezar de repente a ser diferente (o no funcionar en absoluto), y los desarrolladores no podían quejarse al proveedor sobre los errores o las características que faltaban.
Así es también como funcionaban las API públicas/privadas en el iPhone al principio. La razón por la que muchos piensan en iOS cuando se menciona "APIs privadas" es que Apple introdujo más tarde un nuevo requisito para publicar una aplicación en su App Store, a saber, que la aplicación sólo debe utilizar APIs públicas. De este modo, Apple puede asegurarse de que una aplicación que funcionó el año pasado seguirá funcionando el año que viene para los clientes que la compraron en la App Store.
Se podría suponer que la distinción entre APIs "públicas" y "privadas" tiene algo que ver con la seguridad del sistema. Casi nunca es así. En muchos casos, las API se encuentran en forma de ejecutables ubicados en un archivo de biblioteca/marco en el sistema. No hay nada que impida técnicamente al desarrollador copiar el código de la biblioteca "privada" en su propia aplicación, convirtiéndola en parte de su aplicación y, por tanto, dejando de ser una API. Dependiendo de la cantidad de código que se copie, el desarrollador estaría infringiendo los derechos de copia y posiblemente un acuerdo de licencia entre él y el proveedor.
En realidad, las API privadas suelen serlo porque siguen cambiando. Por ejemplo, Apple puede tener una API privada para una nueva pieza de hardware o un nuevo conjunto de funcionalidades en su dispositivo. Con cada lanzamiento, esa API cambia un poco a medida que los desarrolladores de Apple aprenden de los errores y descubren la forma en que los usuarios interactúan con sus propias aplicaciones que utilizan estas funcionalidades. Más tarde, cuando la API ha dejado de cambiar (tanto), Apple hace pública esa misma API ya que ahora creen que está lista para ser consumida por terceros desarrolladores.
Ahora llegamos a sus preguntas más específicas:
-
Parte de la razón por la que Apple (y otros proveedores) no eliminan los símbolos símbolos de la API privada de sus bibliotecas es principalmente porque entonces ellos ellos mismos, o los socios a los que han permitido usar APIs privadas, tampoco no podrían utilizar fácilmente estas APIs en sus aplicaciones. Apple tendría entonces que duplicar todas las bibliotecas - teniendo una versión para ellos y otra para los que no son socios, y asegurarse de que la versión correcta estuviera disponible en cada caso.
Una forma más lógica de que Apple restrinja el uso de APIs privadas sería cambiar el enlazador dinámico y el sistema de mensajería entre los objetos utilizados en Objective-C y Swift para asegurar que que las aplicaciones no autorizadas no puedan llamar a las APIs privadas. Sin embargo, además de añadir un montón de complejidad realmente innecesaria, esto conllevaría una penalización de rendimiento no trivial.
En realidad, es probable que a Apple no le preocupe tanto que un desarrollador utilice una API privada - y por lo tanto se limitan a tener una guía, tratando de detectar los usos más obvios para educar a los educar a los desarrolladores, y luego sólo hacer algo al respecto si se públicamente que se ha utilizado una API privada.
En casi todos los casos, el uso de una API privada podría haber sido el desarrollador de la aplicación simplemente copiando el código ejecutable de la biblioteca en su propia aplicación, con lo que todo el punto de de la controversia. La razón por la que los desarrolladores utilizan APIs privadas es a menudo para acceso a la funcionalidad que Apple construyó que no tienen el tiempo para recrear ellos mismos, o para acceder a la funcionalidad que esperan será pública de todos modos pronto. Entonces se convierte en la responsabilidad del el desarrollador asegurarse de que sólo utilizan esa API privada para ciertas versiones del sistema que realmente tiene esa API privada - y que soporten el riesgo de que su aplicación se rompa con las actualizaciones del sistema. actualizaciones del sistema.
-
En cuanto al caso de Uber: El verdadero problema aquí no es en realidad el uso de APIs privadas. En realidad se trata de un error de seguridad en el sistema operativo que expuso información privada a la aplicación. El desarrollador de la aplicación podría haber hecho lo mismo en su código que la API privada y podría haber tenido acceso a la misma información privada. Eso no es bueno.
-
Sí, el escaneo automatizado es un juego del "gato y el ratón", en el que suele ser mucho más fácil para el desarrollador de la aplicación hacer algo que ofusque su uso de las API privadas, y mucho más difícil para Apple construir un detector. No creo que el uso de APIs privadas sea realmente un "problema" para Apple.
