morgan pushed to branch base-browser-140.0a1-15.0-1 at The Tor Project / Applications / Tor Browser Commits: 24890f9d by Morgan at 2025-06-18T10:01:44+00:00 fixup! BB 43615: Add Gitlab Issue and Merge Request templates add fingerprinting issue template - - - - - 2 changed files: - + .gitlab/issue_templates/031 Fingerprinting.md - .gitlab/issue_templates/Default.md Changes: ===================================== .gitlab/issue_templates/031 Fingerprinting.md ===================================== @@ -0,0 +1,149 @@ +# 👣 Fingerprinting +<!-- +Use this template to track a browser fingerprinting vector. Such vectors +allow for stateless cross-site tracking (i.e. across somehow collaborating +but otherwise unrelated 1st party domains like foo.com and bar.com) + +For the purposes of developing a fix, this template is meant to define all of the things +we want to think about and analyze before implementing a fix. It's totally fine to leave +parts of this template empty on initial report! The the issue description can be updated +and edited as we learn things. + +This template is also meant to serve as documentation/explanation about how we think +about fingerprinting vectors and minimising their utility. +--> + +## Problem Statement +<!-- +Please give an overview of the problem you think we should address. + e.g. system fonts (`font: caption`) might expose desktop + environment/distribution/language/customization because Firefox uses OS + settings. +--> + +## Documentation +<!-- +Please provide a links to the relevant standards or documentation for the affected web +platform features. Additionally, please provide links to relevant academic research, +upstream Bugzilla issues, etc (if available). +--> + +## Repro Steps +<!-- +Please provide any proof of concept which can help us under how this feature +can be used for fingerprinting and that we can use as a test for our patches. +--> + +## Analysis + +### Metric Distribution +<!-- +- How many different possible buckets of values exist without fingerprinting +mitigations? +- How are users distributed between these buckets? +- Do any group of users stand-out by default? +- Do users in each of these buckets likely have different risk profiles? +--> + +### Metric Stability +<!-- +- How does the metric change during and between browsing sessions without mitigations? + e.g. Window size may be mostly stable during a browsing session + but may change between browsing sessions + e.g. User-Agent string is stable during a browsing session, but may change + between major browser updates +--> + +## Mitigation Strategy +<!-- +Outline (at least) one of the possible mitigation strategies for this metric +(normalisation, randomisation, or disabling) +--> + +### Normalisation +<!-- +Describe a strategy whereby all users report the same value for the metric, or the pros +and cons if there are multiple potential normalisation strategies. + e.g. Standardising reported WebGL constants such as maximum framebuffer size +- After normalisation, would this metric be equivalent another normalised metric? + e.g. fonts are usually equivalent to the OS, which is already exposed. +- Sometimes it is impossible to use the same value for all users, but reducing the + number of user buckets is still a win. + +✅ This is the preferred mitigation strategy. +--> + +### Randomisation +<!-- +Describe a strategy whereby users return randomised metrics + e.g. when enumerating webcams, choose a number of devices from a `[1; 3]` uniform + distribution +- How did you choose this distribution and its parameters? +- What strategies should we use to hide the randomization? + e.g. randomize the value only once per session and per first-party +- Why is it not possible to use a normalized value, instead? Normalization is often + better than randomization because it is often easier to conceal + +A randomised metric should ideally be: +- Different per first party domain + e.g. different websites measure a different value for the metric +- Stable per session per first party domain + e.g. a website repeatedly measuring the metric will get back the same value + during the same browsing session +- Different between sessions, regardless of first party domain + e.g. a website measuring a metric between browsing sessions will get back a different + value + +⚠️ We should only resort to randomisation if providing normalised values completely +and utterly breaks web compatibility, usability, or accessibility. +--> + +### Disabling +<!-- +Describe a strategy whereby the fingerprintable metric is just outright disabled + e.g. Disabling WebAuthN feature entirely +- Why is it not possible to spoof a (normalized) value instead? Disabling an API might + break some sites. + e.g. Rejecting the permission prompt request promise would be preferable to removing + or disabling the relevant APIs +- Is this a temporary change? + e.g. necessary on the ESR version of Firefox we use for Tor Browser, but fixed in a + later version of Firefox. +--> + +## Other Considerations + +### Usability and Accessibility +<!-- +- Would the proposed mitigation make websites unusable for non-technical/human reasons? + e.g. Always requesting language as en-US makes websites usable for non English-reading + users +- Would it make the browser unusable for some users? + e.g. Forcing overlay scrollbars would make websites unusable for some users with motor + issues +- Do we need to provide a user-accessible 'escape-hatch' to allow users to opt-out of the + proposed mitigation? + e.g. Providing an option in about:preferences +--> + +### Web Compatibility +<!-- +Would the proposed mitigation break websites for technical reasons? + e.g. Disabling WebAuthN preventing YubiKey authentication +--> + +### Plausibility +<!-- +Would the proposed mitigation make the browser stand out as a potential bot or scraper or +some other non-standard browser configuration? + e.g. Reporting only 2 CPU-cores is unlikely for modern PCs in the year 2025 +--> + +<!-- Do not edit beneath this line <3 --> + +--- + +/confidential +/label ~"Apps::Product::BaseBrowser" +/label ~"Project 131" +/label ~"Fingerprinting" ===================================== .gitlab/issue_templates/Default.md ===================================== @@ -11,6 +11,7 @@ Please select the appropriate issue template from the **Description** drop-down. *NOTE*: the following issue types are intended for internal use - 💣 **Test** - develop a test or update testing infrastructure +- 👣 **Fingerprinting** - open a fingerprinting issue - ✨ **Feature** - implement new features - ⬅️ **Backport** - cherry-pick change to other release channels - ⤵️ **Rebase - Alpha** - rebase alpha to latest Firefox ESR version View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/24890f9d... -- View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/24890f9d... You're receiving this email because of your account on gitlab.torproject.org.