Mac OS 10.14 Mojave: a vueltas con AppleEvents, el escenario final

Toda la información acerca del acceso a los permisos al respecto se almacena en Preferencias del Sistema > Seguridad y privacidad > Privacidad > Automatización. Allí encontrarás las aplicaciones que han solicitado permiso para controlar otras aplicaciones y podrás gestionarlas, aunque solo se mostrarán aquellas aplicaciones a las que has dado permiso… ¿y a las que no has dado permiso?.

Esto es un problema porque si en un momento determinado no diste permiso para gestionar una aplicación, ahora no tienes un interfaz para poder trabajar con esa opción y cancelar esa acción. Lo cual es un problema. Esto se complica especialmente cuando se trata, también, de aplicaciones o elementos del sistema que además operan en segundo plano, como por ejemplo, AppleEvents.

Los que usamos Applescript o Automator nos vamos a encontrar frecuentemente con esto, cuadros de diálogo que solicitan que esa aplicación pueda controlar otra aplicación, o incluso aplicaciones que utilizan estas mismas tácticas como Xcode para mostrar archivos en el Finder. Como digas en primera instancia “no” luego está aparentemente complicado recuperar estas opciones.

tccutil

tccutil es la herramienta que Apple pone a nuestra disposición para poder gestionar los ajustes de privacidad de las aplicaciones. Cuando una aplicación intenta acceder a datos personales, por ejemplo la Agenda, el Mac nos hará una pregunta inicial al respecto del acceso a través de un cuadro de diálogo enviándonos a la gestión de estos datos en Preferencias del Sistema. Esto ya está disponible en macOS 10.13 High Sierra.

Esta sección está disponible a través de Preferencias del Sistema > Seguridad y Privacidad en la pestaña privacidad, mostrando en la barra lateral una serie de aplicaciones y servicios que disponen de una lista de las aplicaciones que han solicitado acceso y casillas para poder marcar nuestra aprobación y por lo tanto, acceso a esas aplicaciones por parte de aplicaciones de terceros.

La eliminación de esos privilegios, de forma general, pueden eliminarse desde el Terminal, automatizando así el trabajo con esta sección de las preferencias. El comando que se encarga de esto es tccutil.

Si accedemos al manual de tccutil veremos que solo hay una opción disponible, reset. Así, el único comando que podemos utilizar es reset asociado a la aplicación a la que queremos quitar los privilegios, por ejemplo, la Agenda:

tccutil reset AddressBook

Lo que ocurrirá al introducir este comando[note]Hay que utilizar el nombre en inglés de las aplicaciones[/note] es que de la Agenda desaparecerán todas las autorizaciones hechas en el panel de control en Preferencias del Sistema, y ahora será necesario reautorizar todas las aplicaciones que quieren acceso a la Agenda.

¿Qué pasa cuando se trata de automatización?

En la sesión WWDC 2018 “Your Apps and the Future of macOS Security”, Apple anunció grandes cambios en la seguridad de macOS. Una de ellas, descrita en la sesión de Apple, y posiblemente la de mayor impacto: las aplicaciones ya no pueden enviar eventos de Apple a otras aplicaciones sin autorización del usuario.

Apple argumenta que los Eventos de Apple (que AppleScript utiliza bajo el capó) pueden utilizarse para obtener acceso a datos de usuario protegidos en otras aplicaciones, por lo que se debe solicitar autorización al usuario. Esta medida de seguridad es perfecta para la protección de los datos de usuario.

Sin embargo, la implementación actual resulta problemática para muchas aplicaciones legítimas que respetan la privacidad en (al menos) las categorías de automatización, accesibilidad, administración de dispositivos, utilidades y control remoto.

La implementación actual

La primera vez que Sender.app envía un evento de Apple a Recipient.app:

• El hilo Remitente.app que envía el evento de Apple está bloqueado
• Recepción.app se lanza, si aún no se está ejecutando
• Se pide al usuario que autorice co un cuadro de diálogo para introducir el nombre de usuario y contraseña de un usuario administrador

El usuario puede entonces elegir entre estas dos opciones:

• Don’t Allow: el hilo continúa su ejecución. El código de error errAEEventNotPermitted (-1743) se devuelve a Remitente.app para que éste y otros eventos de Apple se envíen a Recepción.app en el futuro.
• OK: el hilo continúa la ejecución. Esto – y futuros eventos de Apple desde Remitente.app hasta Recepción.app – se entregan sin necesidad de que el usuario lo solicite de nuevo.

Sin embargo, Recepción.app se lanza cada vez que se envía un Evento de Apple en su dirección, incluso si el usuario ha elegido “No permitir” anteriormente y el Evento de Apple no se entrega. El usuario sólo es consultado una vez por cada par remitente/recibidor.

Esta metodología de trabajo está siendo reevaluada y desarrollada a través de las diferentes betas de Mac OS 10.14 Mojave. En un primer momento se ha descubierto que puede causar problemas con algunas aplicaciones que deberán ser actualizadas para poder utilizar la nueva metodología de trabajo y no causar un error por el que la aplicación dejará de ofrecer al usuario las características incluidas debido a que no puede comunicarse con el sistema.

¿Y si ya has dicho que no?

Entonces, en el caso específico de Apple Events hay que reiniciar toda la base de datos al respecto de las referencias hechas a cada aplicación (automatización/script, etc) hechas con el comando:

tccutil reset AppleEvents

Hay que tener en cuenta que tccutil es una herramienta con muy poca flexibilidad y solo hay un comando soportado: reset así que tampoco hay mucha granularidad al respecto, por lo que un fallo a la hora de permitir o no permitir la ejecución de acceso a Apple Events forzará el reinicio de la base de datos y por lo tanto volver a autorizar todas las aplicaciones que hacen referencia además de aquella a la que dijimos que no.