Status
Under Discussion / Fixed
Some fixes have already been implemented and will be released in the Brave browser update.
Related pages
Some pages require authorization.
- HackerOne | #1668796 Vulnerabilities Related to Web Browser Permissions
https://hackerone.com/reports/1668796
- Don’t inherit permissions in private windows #24720
https://github.com/brave/brave-browser/issues/24720
- Don’t inherit privacy-sensitive content settings in incognito. #14765
https://github.com/brave/brave-core/pull/14765
- Inform users that they need to close private windows to clear data in them #25046
https://github.com/brave/brave-browser/issues/25046
- Release Channel 1.45.113
https://community.brave.com/t/release-channel-1-45-113/440674
Timelines
We have summarized some messages in terms of copyright.
2022/08/14
We submitted our report on HackerOne.
2022/08/17
The issue opened to fix the issue we reported.
https://github.com/brave/brave-browser/issues/24720
2022/08/19
The brave team summarized the claims and sent the response.
Desktop and Android
### 1. Private windows can learn if a non-private window rejected the geolocation permission.
This is a policy we inherited from Chromium / Chrome, but we will fix it regardless of what upstream does. Here is the relevant issue: https://github.com/brave/brave-browser/issues/24720### 2. Clearing all data doesn’t clear permission state in a private window
We believe this is a measurement error in the paper. The clearing of all states in each session only affects that session. This implementation was inherited from upstream. I think this is the correct behavior, but we are exploring ways to improve the UI / UX here to avoid possible confusion. However, we have no immediate plans to change this.
### 3. Background windows can cause the geo location permission to be rejected if they request too many times
This is also policy we’ve picked up from upstream. Since there is not a privacy risk. We do not plan on changing this either.### 4. On Android, sites can do the same as the above for all measured permissions (not just geolocation).
We were not able to replicate this in our own testing. We believe its user benefiting and not a privacy harm, and so will leave the behavior as is.iOS
We believe that all reported problems are due to WKWebView. We believe there are harmful limitations imposed by WKWebView, but our ability to address them is limited. We are exploring possible interventions and mitigations we can apply on top of WKWebView.
We will request from Apple, greater flexibility in WKWebView to more easily fix these issues, but have no immediate plans to address.
2022/08/23
We replied to the response with a Proof-of-Concept code.
Thank you for your investigation of our report. Our motivation is to pursue the improvement of browser security by sharing and discussing the problems found and their solutions with browser vendors, regardless of whether they are covered by Hacker One or not.Desktop and Android
1. Private windows can learn if a non-private window rejected the geolocation permission.
We look forward to fixing this issue.
### 2. Clearing all data doesn’t clear permission state in a private window
We think you are referring to the feature to reset the permission status from the key symbol displayed in the URL bar. The issue we reported is related to “brave://settings/clearBrowserData”.When the user clicks on “Settings” in a private session, the settings page of a normal session is automatically opened. The user would expect that settings and actions on the settings page would affect the state of the private session. However, even if the user uses the “Clear browsing data” feature (brave://settings/clearBrowserData) under “Privacy and security” from the settings page, the private session status is not cleared.The browser versions we investigated did not implement the feature to reset the permission status in bulk from the key symbol displayed in the URL bar. This feature seems to have been implemented in the Chrome 97 version. We will add to our paper about this feature.### 3. Background windows can cause the geo location permission to be rejected if they request too many times
We agree with you that “rejecting permissions for pages that request the permission to often can be a user benefiting intervention”. In our paper, we propose an attack called the Permission-based User Tracking Attack that exploits this implementation to track users. The key factor realizing this attack is the feature that automatically denies permissions when multiple permission requests are received. We consider this attack to be a privacy-related issue. What are your views on this?### 4. On Android, sites can do the same as the above for all measured permissions (not just geolocation).
As shown in Table VII, this problem exists in Android only for Notification permission. We reconfirm the existence of this problem. You can reproduce this problem using the Proof-of-Concept (PoC) we have prepared.PoC (zip file) : https[:]//drive.google.com/drive/folders/1Y9hSXcl0C0hMEI5F8K6bNWxkg1zZMVnQ?usp=sharingPoC (URL) : https[:]//pocforshare.com/k23nPoC (Movie) : https[:]//drive.google.com/file/d/1GFIw9m8v-d3TIY7RFFCHN90C3YvaZ4RO/view?usp=sharingiOS
We look forward to implementing mitigation and encouraging Apple.
2022/08/23
A pull request to fix the implementation is opened
https://github.com/brave/brave-core/pull/14765
2022/08/30
The Brave team sent a reply to our response.
### 2. Clearing all data doesn’t clear permission state in a private window
We plan to update the UX/UI to make this more obvious to users. We are discussing best practices with the design team on the following issue. https://github.com/brave/brave-browser/issues/25046
### 3. Background windows can cause the geo location permission to be rejected if they request too many times
This is not a privacy risk in Brave. A.com embedded in b.com and a.com embedded in c.com get different permissions. This prevents the permissions from being used for cross-site tracking.
### 4. On Android, sites can do the same as the above for all measured permissions (not just geolocation).
Our fix in https://github.com/brave/brave-browser/issues/24720 will also fix this issue
2022/08/30
The issue opened to discuss the issue we reported on.
https://github.com/brave/brave-browser/issues/25046
2022/08/31
The fixes were merged into Brave Nightly.
https://github.com/brave/brave-core/milestone/231?closed=1
2022/08/31
We provided an additional explanation of permission-based user tracking.
We sincerely appreciate your kind attention to our report. We hope that our discussion will contribute to improving the quality of security/privacy for Brave browser users.### 2 and 4.
We look forward to fixing this issue.### 3. Background windows can cause the geo location permission to be rejected if they request too many times
Permission-based user tracking attack is feasible with Brave. We propose a tracking method using redirection as the main method of this attack. Therefore, this attack is feasible without relying on the browser’s handling of the permission state of the embedded page. This attack changes the Top Level Navigation by redirects or new tabs instead of embedding as a website. This means that this attack is also feasible on Brave browsers. Specifically, the attacker performs Step 2. encoding and Step 3. decoding in Section V in our paper by using JavaScript to instantly and continuously transition pages from a.com, b.com, c.com, … to the user’s web browser. The attacker can set the permission status of each origin to deny (Step 2. encoding) or get the permission status of each origin (Step 3. decoding). The attacker can perform the attack in less than 5 seconds when tracking approximately 10^4 users. The attack can also be performed in secret by inducing the user to open a new tab and executing each step in a background tab.
2022/09/01
Brave explained their stance on the proposed attack.
We do not think the attack presented poses a privacy risk to users. Brave’s goal is to prevent passive cross-site recognition. Brave does not attempt to prevent first parties from re-identifying users. The attack you described represents another way for a first party site to re-identify a user.
2022/09/02
We agree that the threat of permission-based user tracking has been mitigated.
With your explanation, we agree that the threat of the permission-based user tracking attack is not significantly different from other tracking methods that use a combination of redirect chains and cookies or DOM storage. We believe that your remediation to make the private window not inherit permissions (issue #24720) will mitigate the threat of this attack.We sincerely appreciate your cooperation and insightful discussion to make the permission mechanism in web browsers more secure.