Overview

A research team of Waseda University and NTT Social Informatics Laboratories conducted a systematic analysis of the permission mechanisms of 5 different Operating Systems (both mobile and desktop OS) and 22 major browsers running on each OS. The results show that they have multiple problems including lack of consistency in implementations of permission mechanisms and flaws that can result in privacy risks. These problems can cause browser users to make bad decisions and create security threats. The below contents are presented by the research team at NDSS 2023.

Products Affected

Web browser application

Description

Permission mechanisms of browsers

Most major web browsers have permission mechanisms. This is to control each web service’s access to the user device’s hardware resources, such as camera and GPS, based on the user’s consent. For example, online meeting services use cameras and microphones while search engines use location information. In this way, dynamic and advanced web services are provided. Websites first request specific permissions from users and then use them to access devices’ cameras and other features.

For example, a website that uses camera, microphone, and GPS requests permissions from the user to access each of them. When a permission is requested, the browser displays a permission request dialog as shown in Figure 1. The user is prompted to allow/block the request to control the website’s access to each feature of the device.
 
Figure 1. Permission request dialog.
The sequence of events from the website requesting permission to the user allowing the request is as follows:

1. The website requests permission to access the device using Web API such as MediaDevices API (for camera and microphone) and/or Geolocation API (for location information).
2. The browser displays the permission request dialog (Figure 1).
3. The user allows/blocks the request or ignores it by closing the dialog.
4. If the permission request is allowed, the web browser gives the website permission to access the device accordingly.

 
Figure 2. The system of permission mechanisms.
In general, web browsers distinguish a website from another based on its origin, and permission setting is configured and saved for each origin. Therefore, browsers refer to the user’s permission setting to automatically allow/deny a permission request from the second time.
 
Figure 3. Managing permissions by origin.
The permission setting has 3 types: prompt, granted, and denied. The permission setting is “prompt” when the user has not chosen one, and thus this is the default value. “Granted” means the permission request is allowed, while “denied” means it is blocked. The origin is permitted to access the device only when the corresponding permission setting is “granted.”
 

Problems in browsers’ permission mechanisms

The problems identified by the research team are listed below. Individually or in combination, these problems could pose a variety of threats.
 

Problem 1. The user's choice of permission is not properly reflected sometimes in certain combinations of OS and browser.

 
Figure 4. Configuration of permission by user.
In certain combinations of OS and browser, when a user chooses allow/block in a permission request dialog, this choice is not properly reflected sometimes.
 

Problem 2. The condition to make the permission setting persistent varies depending on the combination of OS and browser.

 
Figure 5. Making permission setting persistent.
User’s permission settings are persistent in normal browsing mode in many browsers even after the application is closed. However, the condition for the persistence is inconsistent and rather varies depending on the combination of OS and browser. Moreover, in some browsers, after a user configures a permission twice, the permissions are made persistent, and the setting will not be deleted even in private browsing mode.
 

Problem 3. The condition to share permission settings across browsing mode (normal/private) varies depending on the combination of OS and browser.

 
Figure 6. Sharing permission setting across browsing mode.
In multiple combinations of OS and browser, user’s permission setting is shared across browsing mode (normal/private). Many browsers apply the “denied” permission setting in normal browsing mode to their private browsing mode as well, and some browsers also apply the permission setting in private browsing mode to their normal browsing mode.
 

Problem 4. Permission settings are not properly deleted.

 
Figure 7. Deleting permission setting.
When a user deletes their browsing history and cookies from the browser’s settings menu, many browsers keep the permission settings configured in private browsing mode without deleting them. At least one permission setting configured in normal browsing mode is also kept in many cases.
 

Problem 5. When a permission request is ignored, it is automatically configured as “denied.”

 
Figure 8. Ignoring permission request.
In many browsers, when a permission request is ignored multiple times, it is automatically configured as “denied.”
 

Problem 6. Behavior of displaying a permission request from a tab in the background varies depending on the browser.

 
Figure 9. Permission request from background tab.
Many browsers do not display permission request dialog when the request is made from a tab in the background. On the other hand, some browsers show the dialog as an overlay on the foreground tab.
 

Impact

Inconsistencies in permission mechanisms among browsers can cause confusion and wrong decisions to web browser users. Furthermore, inconsistencies between permission mechanisms and important features for protecting user privacy, such as private browsing mode, can result in leaking information that should be protected.

Specific threats that can be caused by the abovementioned problems (1 to 6) individually or in combination are as follows:
 

Tracking by exploiting permission request

By exploiting the permission mechanism, attackers can identify/track a user based on the permission setting saved in the browser. The attacker first generates a different ID for each user when they access the prepared website for the first time. After that, permissions are requested from multiple origins, and the web page gets reloaded repeatedly. In this way, the permission settings for multiple origins are made associated with the user ID. When the user accesses the site next time and later, they get redirected to the multiple websites that associated permission settings with the user ID to refer to the permission settings. By doing so, the attacker can restore the user ID and identify the user who accessed the website.

This attack is made possible when combining Problem 5 (When a permission request is ignored, it is automatically configured as “denied”) and Problem 2 or 3 (High persistence of permission setting in many browsers).

This attack is named Permission-based User Tracking Attack by the research team, and in the published paper, attack feasibility is evaluated, including time required for the attack and target browsers.
 

Figure 10. Tracking by exploiting permission settings.

 

Misidentification of permission request dialog

By exploiting permission mechanisms, attackers can cause users to misidentify which website (origin) made a permission request.

Due to Problem 6, when a permission request is made from a tab in the background, the permission request dialog may appear as an overlay on the website opened in the foreground tab. Since users check the domain of the website to determine whether to allow or block the permission, they might misunderstand that the website they are viewing requested the permission. The attacks that exploit such problems are named Permission-based Phishing Attack by the research group, and in the published paper, attack feasibility is evaluated based on user studies.
 

Figure 11. Misidentifying a permission request dialog. 
 

Misunderstanding in the persistency of permission setting in private browsing mode

Many browsers have problems holding permission settings in private browsing mode without deleting them properly. Private browsing mode is originally designed to delete browsing and search history, cookies, and other information each time the users end the mode so that no information related to user privacy is retained. Failure to delete permission requests in private browsing mode can cause users’ misidentification, and it may result in violating user privacy, which should be protected.

• Due to Problem 2, permission settings configured in private browsing mode are made persistent in some browsers. However, users misunderstand that the sessions in private browsing mode are temporary and expect that the settings are not retained persistently.
• Due to Problem 3, permission settings are shared across browsing mode (normal/private). However, users expect that each of them are independent sessions, which do not share the settings.
• Due to problem 4, in some browsers, permission settings configured in private browsing mode are not deleted even when the browsers’ data delete function is used. However, users expect that the function deletes the permission settings configured in any browsing mode.

These problems can cause permissions to be granted to websites against the users’ will. As a result, information and functions that should be restricted are provided to the website, and the user's privacy may be violated.
 

Figure 12. Misunderstandings about retainment of permission setting in private browsing mode.
In the published paper, an assessment of users’ understandings and expectations of permission setting is conducted based on user studies.
 

Solution

Countermeasures on browser vendor side

For browser implementation, the research team recommends the following countermeasures:

• Do not share permission settings across browsing mode (normal/private).
• Explicitly delete configured permission settings at the end of private browsing mode session.
• Do not display the dialog of permission request by background tab as an overlay.

In their published paper, the research team also recommends that web standards organizations should standardize the following points and share best practices among browser vendors:

• Create an option to delete permission settings periodically instead of making them consistent.
• Do not automatically set permissions to “denied” when the website is reloaded multiple times from “prompt”.
• Restrict permission requests from web pages in iframe.
• Provide users with clear visualization of their permission settings so that they can easily configure the settings.

 

Countermeasures on user side

Use guest mode

Browser users can reduce threats by using guest mode, which is available in many browsers, instead of private browsing mode. Since guest mode operates with a temporary guest user profile, which is different from the normal one, browsing in guest mode is not affected by normal profile settings. In addition, the permission setting configured for the guest user does not affect the normal profile.
 

Check the permission request dialog carefully

It is important to check permission request dialog carefully when using a browser. The research suggests that the websites that users are browsing may not always be the same as those making permission requests. Users need to check the domain of the website making a permission request, which is displayed on the permission request dialog, and properly judge the website. In addition, it is also important to carefully check what types of permission are requested, which is also displayed on the permission request dialog, and avoid granting unnecessary permissions to websites.