Ephemeral Permissions Considered Beneficial

In last year’s macOS Sequoia release, one change attracted a lot of attention: the new periodic confirmation for apps that use screen recording permissions. Every month, macOS would display a prompt to confirm a user’s intent to continue allowing an app access to their screen when the app is used. This change drew criticism from a lot of macOS users, who accused the feature of being intrusive, unnecessary, or anticompetitive; projects such as Amnesia were even created to solve the singular problem of these permission prompts.

Ephemeral permissions models like these appear to be annoying at first sight. They put more obstacles in users’ ways when they are trying to get their computers to do something, adding yet another frustrating dialog to click through in order to reach their ultimate objective. However, the privacy benefits that ephemeral permissions bring far outweigh the increase in required user interactions that they are associated with. The operating system’s (or browser’s) permissions model is the vital boundary that guards the increasingly powerful capabilities of users’ devices against potential intrusion or misuse, and ephemeral permissions play an important role in protecting users from potentially malicious applications and themselves.

In current systems, most permissions are typically designed to be granted permanently. Once a user presses “Allow”, that permission is granted for the application until the user, for whatever reason, decides to go into settings and revoke that permission. This assumption, that an application should always have access to a specific capability when the user has only granted it once, is a convenient yet dangerous one, especially for more sensitive capabilities such as geolocation, microphone, camera, and screen recording. Permissions systems exist because applications installed by the user are not considered fully trusted; they should only have access to whatever the user currently needs them to access in order to function. For the same reason that applications do not have access to all of a device’s capabilities by default, they should not have access to a capability forever based on a one-time expression of intent. For example, if a user grants Discord access to their microphone for a voice chat on a certain occasion, their ultimate intent is not to allow the app to access their microphone anytime, anywhere, but to allow the app to access their microphone for the duration of the voice chat. Would it not make more sense, then, to have the microphone permission only be granted to the app for a limited timeframe and then revoked, for instance, when the user closes the app, or when the device is locked, or after a week?

Permissions systems sometimes address this problem by providing indicators of access to permissions, especially sensitive ones. For instance, macOS displays privacy indicators in Control Center and in the menu bar when sensitive permissions such as the microphone, camera, location, and system audio are being used by applications (incidentally, a subset of users also consider this to be unnecessary). The App Privacy Report on iOS and iPadOS allows users to see a record of when and how apps access permissions (data & sensors) granted them. These features give users insights into when the permissions that they had granted in the past are being used, and help to surface unauthorized access patterns. However, it is oftentimes far too easy to ignore the signals provided by these privacy features; after all, they do not require user interaction! A small yellow dot showing up in the top right corner of a display is quite easy to ignore, especially if the user is engrossed in a task that demands their full attention elsewhere on the screen.

In addition, the number of apps and websites that an individual uses and the number of permissions and capabilities that devices have are both steadily rising; it is impossible to assume that the average user will be able to keep track of everything they have authorized the applications that they use to access. An iOS user could very well forget that they had given an app access to their calendar, until some day by a fluke they happen to check their App Privacy Report and realize that it has been periodically accessing their calendar data for no apparent reason. Opaque business practices and legalese-filled privacy policies further make it difficult to hold applications accountable for where data goes after it is collected from devices’ capabilities. Thus, it is the increasingly indispensable duty of the operating system/browser, acting as the security boundary, to actively remind the user of these permissions (by making them temporally limited) and give them an opportunity to periodically review them.

Ephemeral permissions ensure that users will have to review their privacy settings on a regular basis through active interactions with the permissions system. Whether implemented through centralized settings or operating system/browser prompts, the fact that an application has authorization to access a specific capability on a device is prominently brought to the user’s attention. The user might want the application to continue having the permission; in that case, a few interactions will confirm such an intent. If the user does not want the application to continue having the permission, however, this will bring the issue to their attention and they will decline to grant the permission or deny it for the application. In any case, the ephemeral nature of these permissions will require active user intent to periodically confirm or deny them, thereby ensuring that the user’s preferences (which might often change) are always reflected in their privacy settings.

Ephemeral permissions systems also automatically revoke permissions or remind users to revoke them when they are no longer needed. In the previously mentioned Discord example, a good ephemeral permissions model will either (a) remove the microphone permission from the app at some point in time after the voice chat or (b) remind the user that the app has access to their microphone, at which point they can choose to grant or deny the permission. This behavior enforces the principle of least privilege for applications; they only have access to the permissions that are required for the function that the user uses them for. If a user gives camera access to a maps app for AR navigation one time but then does not use AR navigation ever again, ephemeral permissions systems will, at some point, revoke camera permissions for the maps app, ensuring that the maps app no longer has access to a permission which it does not need to function. Chromium’s “Automatically remove permissions from unused sites” setting is founded on such a premise; something that a user has not used for a while and perhaps does not even recall using should not have access to sensitive user data. Ephemeral permissions systems give users opportunities to reconsider whether an application currently needs the permission that it is requesting, reminding them of a choice that they can take but may have forgotten about or preemptively protecting them from unauthorized access.

An interactive ephemeral permissions system design, in which permissions are granted and revoked as a user interacts with the application that is requesting the permission, helps to reduce the maintenance burden of privacy settings as well. Instead of having to go into a centralized privacy settings page and toggling permissions for prodigious lists of apps, users will be able to manage these permissions in the course of utilizing the functionalities that require them; the conscious effort that is required for a user to review their privacy settings is significantly reduced. Even for users that, for one reason or another, are regrettably predisposed to impetuously granting permissions to applications without considering their specific use cases or implications, ephemeral permissions systems might provide a significant improvement in privacy protection. Since permissions requests are repeatedly presented to the user over time, there is a greater chance of them actually reviewing the permissions request and making an active decision on it at some point; such an opportunity is not offered to the user in a permanent permissions system.

Ephemeral permissions models provide a level of privacy guarantees and protection that significantly surpass “traditional” permanent permissions models. Any implementations of such systems have to strike a delicate balance between usability and privacy; they must keep the user actively aware of their permissions choices through requiring interaction, while avoiding obstructing the user’s daily usage to the point where they devise strategies to circumvent the very system designed to protect them. In general, ephemeral permissions are definitely a net positive for privacy. macOS Sequoia’s implementation of screen recording permissions was a commendable move in favor of this model, and it would be wonderful to see more ephemeral permissions systems in production across operating systems and browsers.