El Play Store dejó de responderle a Aurora Store y el reporte está abierto en el repositorio del proyecto: Play Store blocks AuroraStore, hurting GrapheneOS users. Aurora es el cliente no oficial que usa mucha gente que corre Android sin servicios de Google —GrapheneOS entre ellos— para bajar aplicaciones del catálogo oficial. El mismo día, el equipo de AnkiDroid reportó que Google ya no le permite conservar el enlace de donaciones a Open Collective en su ficha: AnkiDroid: Google Play no longer allowing Open Collective donation link. Los dos casos son hilos de reporte, no comunicados: el material no explica el mecanismo del bloqueo ni si es permanente.

Por qué importa

La discusión sobre seguridad móvil casi siempre se va al dispositivo: el kernel endurecido, el sandbox, el arranque verificado, los permisos. Todo eso importa, pero es la parte que ya está razonablemente resuelta. El eslabón que nadie modela es el canal por el que llega el software, y ese eslabón no te pertenece.

Un teléfono con GrapheneOS es, técnicamente, más difícil de comprometer que un Android de fábrica. Pero su acceso al catálogo de aplicaciones pasa por un intermediario que depende de que la otra punta lo tolere. Cuando esa tolerancia se termina, el dispositivo no se vuelve inseguro por una falla de código: se vuelve inseguro porque el usuario tiene que conseguir sus apps en otro lado. Y el otro lado, en la práctica, son mirrors de APK sin cadena de custodia, sin verificación de firma y sin actualizaciones automáticas.

Ese es el punto: un bloqueo de distribución no detiene la instalación, la degrada. El caso de AnkiDroid completa el cuadro desde el otro extremo. Un enlace de donaciones no tiene relación con el modelo de amenazas de nadie, y aun así la política de tienda lo alcanza. El criterio que gobierna qué software llega a tu teléfono es el de la plataforma, no el tuyo.

Qué cambia en la práctica

Si mantenés una app Android, el bloqueo de Aurora probablemente no te toca de forma directa. Lo que muestra es que la cadena por la que tus usuarios te reciben tiene un tramo que vos no controlás y que puede cortarse sin aviso previo.

┌───────────┐    ┌──────────────┐    ┌───────────┐
│ GrapheneOS│───►│ Aurora Store │─X─►│ Play Store│
│ (sin GMS) │    │ (no oficial) │    │ (catálogo)│
└───────────┘    └──────┬───────┘    └───────────┘
                        │ bloqueado
                        ▼
                 ┌──────────────┐
                 │ mirrors APK  │
                 │ sin garantía │
                 └──────────────┘

Lo que yo cambiaría en el flujo de trabajo:

  • Publicar el APK firmado en un dominio propio, con el hash publicado al lado y las huellas del certificado documentadas. Que cualquiera pueda correr apksigner verify --print-certs y comparar contra lo que decís vos, no contra lo que dice la tienda.
  • Mantener paridad de versiones entre canales. Un canal alternativo que va tres releases atrás es un canal que distribuye vulnerabilidades ya parcheadas.
  • No atar funcionalidad esencial a servicios propietarios que no existen en un dispositivo de-Googleado. Si tu app sin Play Services no arranca, el usuario ya está fuera de tu alcance antes de cualquier bloqueo.
  • Tratar la distribución como una dependencia de arquitectura, con su propio plan de contingencia, y no como un trámite del final del sprint.

Cuándo NO usarlo

Sería deshonesto cerrar acá con la moraleja fácil de que todos deberíamos salirnos de la tienda. No es lo que yo recomiendo.

No apoyes tu postura de seguridad en un proxy no oficial. Un cliente que consume un catálogo ajeno funciona mientras el dueño del catálogo no lo impida, y este episodio es exactamente eso. Como pieza crítica para que lleguen parches de seguridad, es frágil por diseño. Un parche que no llega a tiempo hace más daño que un canal incómodo pero estable.

No de-Googlees una flota que no vas a poder sostener. Si administrás dispositivos corporativos con MDM, o tus usuarios dependen de aplicaciones que exigen atestación de la plataforma, el camino alternativo termina en gente instalando APKs de cualquier origen para resolver el bloqueo del día. Eso es peor que el punto de partida.

No abras un canal propio sin proceso. Distribuir tu APK exige custodia de claves, plan de rotación, un canal de aviso de vulnerabilidades y actualizaciones que efectivamente lleguen. Sin eso, tu canal propio es una superficie de ataque nueva con menos controles que la tienda que estás evitando.

Y no le atribuyas intención a esto todavía. Con un work item y un issue no sabemos si el bloqueo fue una decisión de política, un cambio técnico o un efecto colateral. Vale sacar conclusiones sobre el riesgo estructural; no vale sacarlas sobre el motivo.

Qué haría hoy

Haría el inventario aburrido: listar por qué canales llega mi software al dispositivo del usuario y marcar cuáles dependen de un tercero que puede cortarlos mañana. Para cada uno, definir qué pasa el día que se corta. Y si sos usuario de GrapheneOS, la peor reacción posible es reemplazar Aurora por el primer mirror que aparezca en una búsqueda: esperá, verificá firmas, y priorizá las apps que publican binarios verificables por su cuenta.