Status

Under Review/Discussion

Related pages

The following page requires authorization. When the issue is public, you will be able to see the full messages.

• Issue 1352800: Security: Vulnerabilities Related to Web Browser Permissions

https://bugs.chromium.org/p/chromium/issues/detail?id=1352800

Timelines

We have summarized some messages in terms of copyright.

2022/08/14

We submitted our report.

2022/08/26

Google responded to the concerns raised in our paper.

About the Clear Browsing Data mechanism

The Clear Browsing Data function is meant as a tool to delete only normal mode data. On desktop platforms, when visiting chrome://settings/clearBrowserData in Incognito, a dialog pops up suggesting that Incognito be closed.

About sharing permission status beyond browsing mode

This is an intentional privacy-preserving behavior. Denied permissions are carried over to reflect user preferences and may be carried over to incognito mode. The Chrome team recognizes that it is possible to fingerprint users based on denied permissions. The Chrome team is actively working on fingerprinting prevention solutions as part of our Privacy Sandbox: https://web.dev/digging-into-the-privacy-sandbox/#combat-fingerprinting. The Chrome team considers this to be the right tradeoff between respecting the preferences of users and increasing the risk of already existing fingerprints.

About the persistence of permission status

The permission status persists, but the user can change that decision at any time. In general, Chrome team considers it to be a sound approach to design of privacy features to let users make a decision, and respect that decision, while giving users an easy way to reverse it at any time.

About iOS-related issues

Chrome on iOS uses Apple’s renderer WKWebView, as required by the iOS policy. Chrome team is currently inheriting our permissions framework from it.

2022/08/29

We mentioned our perspective on Google’s response.

About the Clear Browsing Data mechanism

You appear to be referring to the feature that prompts the user to close the Private Browsing window when the user accesses “chrome://settings/clearBrowserData” in Private Browsing mode, by typing directly into the URL bar. We will add this implementation to the paper.

However, when a user opens “Settings” from the “three dot menu” in Private Browsing mode, the settings page opens in the Normal Browsing mode window. Users can use the “Clear browsing data” feature by selecting “Privacy and security”. The user opens the settings page from the “Settings” button in Private Browsing mode. Therefore, users would expect the “clear browsing data” mechanism on the settings page to affect Private Browsing mode.

We assume that you believe that the use of Chrome’s incognito mode is temporary and that users can clear their data by closing the browser, so there is no particular problem.
However, there may be use cases where users use incognito mode for relatively long periods of time without closing their browsers. Although the percentage of such users may not be high, it is not hard to imagine that such users may actually exist, given the huge number of Chrome users. In such a case, the user would not have the option to close the browser, but would expect to clear browsing data by pressing clear browsing data.

We conducted a user survey in the revised version of the paper to determine user perceptions of the effect of the “clear browsing data” mechanism on the permission state in Private Browsing mode. The results show that more than 70% of the users recognized that the use of the “clear browsing data” mechanism would erase their permission state in Private Browsing mode. This result suggests that many users expect the “clear browsing data” mechanism to also affect the permission state of the Private Browsing mode.

We think it is necessary to consider a mechanism to close the Private Browsing window when the “clear browsing data” mechanism is used while the user has the Private Browsing window open, and to design a UI that is easy for users to understand.

About sharing permission status beyond browsing mode

We agree with your idea that if a user is denying permissions in Normal Browsing modes, then the user would want to deny them in incognito mode as well. On the other hand, an incognito user wouldn’t want the website to know that he/she has accessed the same site in the past.

Also, our proposed Permission-based User Tracking Attack is a powerful tracking that can deterministically identify users. This problem threatens the anonymity of the incognito mode.

For example, the following implementation could take both usability and risk into account.
1. When permissions denied in Normal Browsing mode are requested in Private Browsing mode, the permission request prompt is not displayed to the user. The web browser does not immediately set the permission status to denied, but automatically sets it to denied after a random period of time.
2. When permissions denied in Normal Browsing mode are requested in Private Browsing mode, the permission request prompt is not displayed to the user. On the other hand, the permission status that can be obtained from the website is not “denied” but “prompt”.
3. The incognito mode does not carry over the denied state of permissions set by repeated ignoring of prompts.

In addition, we conducted a user survey in a revised version of the paper to determine users’ perceptions of how browsers handle denied permissions set in Normal Browsing mode in incognito mode. The results showed that 72% of users who were familiar with the incognito mode recognized that the denied permission status set in Normal Browsing modes does not carry over to the incognito mode.

Considering these results, we believe that further discussion is necessary.

About the persistence of permission status

We agree with you about your idea. We also think that this implementation is not always a problem.

About iOS-related issues

We have been aware of the fact that web browsers offered as iOS apps are restricted by WKWebView; so, third-party browser venders on iOS may have intrinsic difficulties in fixing the problems. Do you have any plans to contact Apple to request fixes for the current problems with the Chrome browser on iOS?

About an implementation that automatically denies permission requests and a Permission-based user tracking attack

What do you think about this implementation and Permission-based user tracking attack?