Los que somos desarrolladores tenemos una grandiosa oportunidad con las plataformas móviles, creo que no se le escapa a nadie. El gran problema es que dependendemos de los proveedores de dichas plataformas, aunque en el caso de Android sea realmente laxo y, en pocas palabras, podamos hacer de todo lo que nos plazca, incluso colar los permisos que queramos en las apps. Una vez marcado este punto, imaginemos que nos llamamos Joaquim Vergès, entonces, es cuando decidimos hacer una aplicación para Twitter, un cliente donde podamos hacer casi de todo lo que la plataforma nos ofrece y, por nuestro trabajo, resulta que nos sale el mejor cliente de Twitter para Android. Ahora ya sabemos de qué hablamos, de la piratería de Falcon Pro...o tal vez no es ese todo el problema.
Los límites en la API de Twitter son malos, pero no son todo el problema.
Empecemos por el principio, ya que el caso de la piratería de Falcon Pro no es, ni de lejos, nuevo. El que algunos consideran como el mejor cliente de Android lleva ya una larga historia de cierres parciales, o de reinicios, mejor dicho. Todo esto debido a las limitaciones de la API de Twitter, que no le deja tener más de 100.000 usuarios al mismo tiempo, ya que llegó cuando la API 1.1 estaba desplegada (de haber sido al contrario y tener más de 100.000 usuarios al momento del cambio, le habrían dejado tener el 200% del número de usuarios que tuviese). El caso es que por la piratería de Falcon Pro, no todos los usuarios habían pagado por la app, sino que había mucha piratería, obligándole a hacer dichos reinicios. De hecho, aquí en Celularis ya intenté analizar quién era el culpable de estos reinicios de tokens, hoy no vamos a ahondar en esto, sino en ¿qué podría haber hecho el desarrollador para evitarlo?, desde un punto de vista más frío hacia él. Todos será un análisis a posteriori, debido a que, de momento, Falcon Pro ya no estará más en Google Play.
Piratería de Falcon Pro, un mal anunciado, cúbrete las espaldas
Si alguna vez habéis programado algo en una empresa, la premisa es siempre muy simple: teme lo peor. En el caso de Android: teme que te vayan a piratear, que encuentren la forma de falsificar la compra de Google Play, o, más fácil aún, teme que cojan tu APK y lo destripen hasta el extremo, decompilándolo. Todo por no querer pagar 1.50 dólares.
Esta parte es precisamente en la que falló Vergès, aunque para verlo, primero debemos explicar, a grandes rasgos, oAuth, o el protocolo que usan Twitter, Facebook y demás para poder darle acceso a nuestra cuenta e información a las diferentes aplicaciones cliente sin tener que compartir con ellos la clave de nuestra cuenta, aunque de manera muy simple.
Toma todas las medidas para evitar lo impensable.
En el proceso de autenticación de Twitter hay 3 factores implicados, a grandes rasgos. Estos son: la API key, API Secret y el user token. Las dos primeras cosas son proveídas por Twitter cuando registras tu aplicación, la API key se usará para generar un user token, de esta manera es como Twitter controla qué aplicaciones han usado cuántos user tokens. Y el API secret es como la contraseña de tu aplicación (no del usuario), es lo que nunca debería ser público para evitar que alguien las use y autentique usuarios como si fuera tu aplicación para fines maliciosos. O más simple: robarte user tokens.
Y en esto último es donde las medidas contra la piratería de Falcon Pro fallaron: ya que distribuía el API Key y Secret con la aplicación del cliente. Pero es que, además, no validaban las compras antes de entregar un user token, por lo que daba igual si era algo pirateado o no. Como desarrollador, en cuanto tienes un token limit lo primero que debes hacer es deshacerte del API secret en la app de cliente y, en su lugar, guardarla en un servidor que verifique de dónde viene esa petición, si la app es original (con LVL o IAP) y luego, si todo es correcto, devolver un user token a la aplicación que envió la petición, que será la tuya, si implementas buenos sistemas de control.
Si vas a una paltaforma conocida por la piratería...
Con todo esto, la culpa no es sólo del desarrollador, pero sí que una buena parte de esto no hubiera pasado ni hubiese habido tanto drama con esta aplicación. En resumen: si creas una app que depende del servicio de terceros y has de tener cuidado con ciertos límites en una plataforma que ya se conoce por su piratería, hazlo bien, si quieres comer de ello.
