Desbloqueo de SIM y No Lock Home en KitKat

Dejo esto como un apunte rápido de un fallo con un módulo del Xposed Framework que me ha dejado un poco «antontado» por ser la primera vez que me topo con algo así. Parece ser que si tienes un teléfono de boot perezoso (por decirlo amablemente, en otras palabras, que arranca más lento que el caballo del malo), si tienes instalada como mínimo la versión 0.6.4b de No Lock Home vas a tener problemas.

Imagen de andro4all

Imagen de andro4all

El módulo No Lock Home emula en Android 4.4.x una feature de Lollipop llamada Trusted Locations. Bajo la premisa de que un punto de acceso WiFi con un SSID y MAC concretos sólo puede estar en un único sitio (tu casa, tu oficina…) puedes decidir una política de seguridad distinta según donde te encuentres. En resumen, escoger que el teléfono no te pida ser desbloqueado si te encuentras en un sitio donde la seguridad de acceso sea más una molestia que una ventaja. Una localización en la que confíes que no van a husmear en tu dispositivo.

El problema es que parece ser que No Lock Home es un poco bruto y se lleva por delante cualquier pantalla del sistema que pida un código. Así que si enciendes el teléfono con el WiFi activado y este se enlaza al AP de confianza antes de que salte la pantalla de desbloqueo de la tarjeta SIM, No Lock Home evitará que ésta aparezca, no dejándote así conectar a tu red de telefonía.

¿Solución? Desenlazarte de aquellas redes WiFi y/o dispositivos bluetooth de confianza y activar y desactivar el modo avión para que se reintente el desbloqueo de SIM.

Facebook, su SDK y el email sin confirmar

Como sabréis si alguna vez habéis desarrollado una aplicación que requiera login (ya sea de escritorio, móvil o web-app), la autenticación del usuario es una de las cosas que más dolores de cabeza puede provocar. ¿Obligo al usuario a darme equis dato? ¿Cómo lo identifico de manera única? ¿Cómo almaceno en la base de datos toda su información de manera segura? Gracias a $root, en los últimos años han surgido servicios de autenticación ofrecidos por grandes redes sociales que permiten usarlos a ellos como intermediarios en este proceso.

login-facebook-button

Es decir, confiamos en que el usuario A es realmente A porque un tercero, C, garantiza a nuestro servicio, B, que A es quien dice ser. De esta manera eliminamos de nuestra responsabilidad gran parte de la gestión segura de usuarios (no toda) y nos despreocupamos. Enseñamos a nuestros usuarios botones tales como “Login with Google+”, “Login with Twitter” o “Login with Facebook”, añadimos las líneas de código necesarias a nuestra app para comunicarnos con estos servicios y nos sentamos a esperar a que amablemente nos envíen la información del usuario que hemos requerido.

Sigue leyendo