Loading .gitlab/issue_templates/000 Bug Report.md 0 → 100644 +121 −0 Original line number Diff line number Diff line # 🐞 Bug Report <!-- Use this template to report problems with the browser which are unrelated to website functionality (please use the Web Compatibility template for such issues). The issue's title MUST provide a succinct description of the problem. Some good (hypothetical) titles: - Browser crashes when visiting example.com in Safer mode - Letterboxing appears even when disabled when using tiling window-manager - All fonts in browser-chrome have serifs Please DO NOT include information about platform in the title, it is redundant with our labeling system! --> ## Reproduction steps <!-- Provide specific steps developers can follow to reproduce your issue. --> ## Expected behaviour <!-- Provide a description of the browser feature or scenario which does not appear to be working. --> ## Actual behaviour <!-- Provide a description of what actually occurs. --> ## Bookkeeping <!-- Please provide the following information: --> - Browser version: - Browser channel: - [ ] Release - [ ] Alpha - [ ] Nightly - Distribution method: - [ ] Installer/archive from torproject.org - [ ] tor-browser-launcher - [ ] homebrew - [ ] other (please specify): - Operating System: - [ ] Windows - [ ] macOS - [ ] Linux - [ ] Android - [ ] Tails - [ ] Other (please specify): - Operating System Version: ### Browser UI language <!-- Found in `about:preferences#general`. Feel free to omit this if you like, but sometimes bugs can be language specific so having this info may make it easier for developers to reproduce your problem. --> ### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? <!-- If you changed any preference in about:config that aren't exposed in a UI, could you try to see if you can reproduce without them? Generally speaking, such changes are unsupported and bugs might be closed as invalid. --> ### Do you have any extra extensions installed? <!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> ## Troubleshooting <!-- This is optional, but it will help to resolve your problem. --> ### Does this bug occur in a fresh installation? ### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? <!-- Archived packages for past versions can be found here: - https://archive.torproject.org/tor-package-archive --> ### Does this bug occur in the Alpha release channel? <!-- Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. ⚠️ However, the Alpha release channel is the development version and as such may be contain critical bugs not present in the Stable release channel. Do not test in Alpha if you are an at risk user unless you really, actually, truly know what you are doing! The latest Alpha can be found here: - https://www.torproject.org/download/alpha/ --> ### Does this bug occur in Firefox ESR (Desktop only)? <!-- Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely also be present in Tor Browser. Firefox ESR is available for download here: - https://www.mozilla.org/en-US/firefox/all/desktop-esr/ --> ### Does this bug occur in Firefox Rapid Release? <!-- If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able to identify and backport the patch which fixes it. Firefox Rapid Release is available for download here: - https://www.mozilla.org/en-US/firefox/new/ If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Bug" .gitlab/issue_templates/010 Proposal.md 0 → 100644 +70 −0 Original line number Diff line number Diff line # 💡 Proposal <!-- Use this template to request a feature or propose some change in the browser. The issue will likely be edited many times over its life to flesh out the various questions, so if you don't know the answers to something, jut leave it blank! The issue's title MUST provide a succinct description of proposal. Some good (hypothetical) titles: - Remove 'Safer' option from Security Level - Bundle uBlock Origin by default - Replace NoScript with faith-based JavaScript sand-boxing --> ## User Story <!-- Provide a high-level summary of the proposed feature, the problem it solves, and what it would allow users to do if implemented. --> ## Security and Privacy Implications <!-- How would this proposal interact with our the browser's threat model? Would this feature negatively affect the browser's security or privacy guarantees? --> ### Security <!-- Outline any security implications this feature would introduce. The browser's security requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#21-security-requirements --> ### Privacy <!-- Outline any privacy implications this feature would introduce. The browser's privacy requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#22-privacy-requirements --> ## Accessibility Implications <!-- Would this proposal affect or interact with the browser's usability for users with accessibility needs (e.g. vision or mobility issues). What problems would need to be solved to ensure these users are not left behind? --> ## Other Trade-Offs <!-- Beyond the security, privacy and accessibility implications, what other implications are there for users? --> ## Prior Art ### Does this feature exist in other browsers? - [ ] Yes - [ ] Firefox - [ ] Firefox ESR - [ ] Other (please specify) - [ ] No ### Does this feature exist as an extension? If yes, which one provides this functionality? <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Proposal" .gitlab/issue_templates/020 Web Compatibility.md 0 → 100644 +112 −0 Original line number Diff line number Diff line # 🌍 Web Compatibility <!-- Use this template to report websites which do not work properly in the browser. The issue's title MUST provide a succinct description of the problem. Some good (hypothetical) titles: - Road signs do not render correctly on maps.foo.com - Infinite CAPTCHA prompts on bar.nat - Cannot login to baz.org --> ## URL <!-- Provide a link to the website --> ## Expected behaviour <!-- Provide a description of the how the website is supposed to work --> ## Actual behaviour <!-- Provide a description of what actually occurs --> ## Reproduction steps <!-- Provide specific steps developers can follow to reproduce your issue --> ## Bookkeeping <!-- Please provide the following information: --> - Browser version: - Browser channel: - [ ] Release - [ ] Alpha - [ ] Nightly - Distribution method: - [ ] Installer/archive from torproject.org - [ ] tor-browser-launcher - [ ] homebrew - [ ] other (please specify): - Operating System: - [ ] Windows - [ ] macOS - [ ] Linux - [ ] Android - [ ] Tails - [ ] Other (please specify): - Operating System Version: ### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? <!-- If you changed any preference in about:config that aren't exposed in a UI, could you try to see if you can reproduce without them? Generally speaking, such changes are unsupported and bugs might be closed as invalid. --> ### Do you have any extra extensions installed? <!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> ## Troubleshooting <!-- This is optional, but it will help to resolve your problem. --> ### Does this bug occur in a fresh installation? ### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? <!-- Archived packages for past versions can be found here: - https://archive.torproject.org/tor-package-archive --> ### Does this bug occur in the Alpha release channel? <!-- Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. ⚠️ However, the Alpha release channel is the development version and as such may be contain critical bugs not present in the Stable release channel. Do not test in Alpha if you are an at risk user unless you really, actually, truly know what you are doing! The latest Alpha can be found here: - https://www.torproject.org/download/alpha/ --> ### Does this bug occur in Firefox ESR (Desktop only)? <!-- Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely also be present in Tor Browser. Firefox ESR is available for download here: - https://www.mozilla.org/en-US/firefox/all/desktop-esr/ --> ### Does this bug occur in Firefox Rapid Release? <!-- If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able to identify and backport the patch which fixes it. Firefox Rapid Release is available for download here: - https://www.mozilla.org/en-US/firefox/new/ If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::WebCompatibility" .gitlab/issue_templates/030 Test.md 0 → 100644 +29 −0 Original line number Diff line number Diff line # 💣 Test <!-- Use this template to track testing of some feature. Please try to make the title a good one-liner for the changelogs! Some good (hypothetical) titles: - Add test exercising new circuit button - Add tests for verifying built-in bridge connectivity - Develop a mock Lox authority for automated testing --> ## Description <!-- Provide an overview of the technical/implementation aspects of this test work a developer would need to know --> ## Scenarios <!-- Provide a list of high-level classes of desired test-cases and the expected behaviour of each --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Test" .gitlab/issue_templates/031 Fingerprinting.md 0 → 100644 +149 −0 Original line number Diff line number Diff line # 👣 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" Loading
.gitlab/issue_templates/000 Bug Report.md 0 → 100644 +121 −0 Original line number Diff line number Diff line # 🐞 Bug Report <!-- Use this template to report problems with the browser which are unrelated to website functionality (please use the Web Compatibility template for such issues). The issue's title MUST provide a succinct description of the problem. Some good (hypothetical) titles: - Browser crashes when visiting example.com in Safer mode - Letterboxing appears even when disabled when using tiling window-manager - All fonts in browser-chrome have serifs Please DO NOT include information about platform in the title, it is redundant with our labeling system! --> ## Reproduction steps <!-- Provide specific steps developers can follow to reproduce your issue. --> ## Expected behaviour <!-- Provide a description of the browser feature or scenario which does not appear to be working. --> ## Actual behaviour <!-- Provide a description of what actually occurs. --> ## Bookkeeping <!-- Please provide the following information: --> - Browser version: - Browser channel: - [ ] Release - [ ] Alpha - [ ] Nightly - Distribution method: - [ ] Installer/archive from torproject.org - [ ] tor-browser-launcher - [ ] homebrew - [ ] other (please specify): - Operating System: - [ ] Windows - [ ] macOS - [ ] Linux - [ ] Android - [ ] Tails - [ ] Other (please specify): - Operating System Version: ### Browser UI language <!-- Found in `about:preferences#general`. Feel free to omit this if you like, but sometimes bugs can be language specific so having this info may make it easier for developers to reproduce your problem. --> ### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? <!-- If you changed any preference in about:config that aren't exposed in a UI, could you try to see if you can reproduce without them? Generally speaking, such changes are unsupported and bugs might be closed as invalid. --> ### Do you have any extra extensions installed? <!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> ## Troubleshooting <!-- This is optional, but it will help to resolve your problem. --> ### Does this bug occur in a fresh installation? ### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? <!-- Archived packages for past versions can be found here: - https://archive.torproject.org/tor-package-archive --> ### Does this bug occur in the Alpha release channel? <!-- Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. ⚠️ However, the Alpha release channel is the development version and as such may be contain critical bugs not present in the Stable release channel. Do not test in Alpha if you are an at risk user unless you really, actually, truly know what you are doing! The latest Alpha can be found here: - https://www.torproject.org/download/alpha/ --> ### Does this bug occur in Firefox ESR (Desktop only)? <!-- Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely also be present in Tor Browser. Firefox ESR is available for download here: - https://www.mozilla.org/en-US/firefox/all/desktop-esr/ --> ### Does this bug occur in Firefox Rapid Release? <!-- If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able to identify and backport the patch which fixes it. Firefox Rapid Release is available for download here: - https://www.mozilla.org/en-US/firefox/new/ If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Bug"
.gitlab/issue_templates/010 Proposal.md 0 → 100644 +70 −0 Original line number Diff line number Diff line # 💡 Proposal <!-- Use this template to request a feature or propose some change in the browser. The issue will likely be edited many times over its life to flesh out the various questions, so if you don't know the answers to something, jut leave it blank! The issue's title MUST provide a succinct description of proposal. Some good (hypothetical) titles: - Remove 'Safer' option from Security Level - Bundle uBlock Origin by default - Replace NoScript with faith-based JavaScript sand-boxing --> ## User Story <!-- Provide a high-level summary of the proposed feature, the problem it solves, and what it would allow users to do if implemented. --> ## Security and Privacy Implications <!-- How would this proposal interact with our the browser's threat model? Would this feature negatively affect the browser's security or privacy guarantees? --> ### Security <!-- Outline any security implications this feature would introduce. The browser's security requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#21-security-requirements --> ### Privacy <!-- Outline any privacy implications this feature would introduce. The browser's privacy requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#22-privacy-requirements --> ## Accessibility Implications <!-- Would this proposal affect or interact with the browser's usability for users with accessibility needs (e.g. vision or mobility issues). What problems would need to be solved to ensure these users are not left behind? --> ## Other Trade-Offs <!-- Beyond the security, privacy and accessibility implications, what other implications are there for users? --> ## Prior Art ### Does this feature exist in other browsers? - [ ] Yes - [ ] Firefox - [ ] Firefox ESR - [ ] Other (please specify) - [ ] No ### Does this feature exist as an extension? If yes, which one provides this functionality? <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Proposal"
.gitlab/issue_templates/020 Web Compatibility.md 0 → 100644 +112 −0 Original line number Diff line number Diff line # 🌍 Web Compatibility <!-- Use this template to report websites which do not work properly in the browser. The issue's title MUST provide a succinct description of the problem. Some good (hypothetical) titles: - Road signs do not render correctly on maps.foo.com - Infinite CAPTCHA prompts on bar.nat - Cannot login to baz.org --> ## URL <!-- Provide a link to the website --> ## Expected behaviour <!-- Provide a description of the how the website is supposed to work --> ## Actual behaviour <!-- Provide a description of what actually occurs --> ## Reproduction steps <!-- Provide specific steps developers can follow to reproduce your issue --> ## Bookkeeping <!-- Please provide the following information: --> - Browser version: - Browser channel: - [ ] Release - [ ] Alpha - [ ] Nightly - Distribution method: - [ ] Installer/archive from torproject.org - [ ] tor-browser-launcher - [ ] homebrew - [ ] other (please specify): - Operating System: - [ ] Windows - [ ] macOS - [ ] Linux - [ ] Android - [ ] Tails - [ ] Other (please specify): - Operating System Version: ### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? <!-- If you changed any preference in about:config that aren't exposed in a UI, could you try to see if you can reproduce without them? Generally speaking, such changes are unsupported and bugs might be closed as invalid. --> ### Do you have any extra extensions installed? <!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> ## Troubleshooting <!-- This is optional, but it will help to resolve your problem. --> ### Does this bug occur in a fresh installation? ### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? <!-- Archived packages for past versions can be found here: - https://archive.torproject.org/tor-package-archive --> ### Does this bug occur in the Alpha release channel? <!-- Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. ⚠️ However, the Alpha release channel is the development version and as such may be contain critical bugs not present in the Stable release channel. Do not test in Alpha if you are an at risk user unless you really, actually, truly know what you are doing! The latest Alpha can be found here: - https://www.torproject.org/download/alpha/ --> ### Does this bug occur in Firefox ESR (Desktop only)? <!-- Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely also be present in Tor Browser. Firefox ESR is available for download here: - https://www.mozilla.org/en-US/firefox/all/desktop-esr/ --> ### Does this bug occur in Firefox Rapid Release? <!-- If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able to identify and backport the patch which fixes it. Firefox Rapid Release is available for download here: - https://www.mozilla.org/en-US/firefox/new/ If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::WebCompatibility"
.gitlab/issue_templates/030 Test.md 0 → 100644 +29 −0 Original line number Diff line number Diff line # 💣 Test <!-- Use this template to track testing of some feature. Please try to make the title a good one-liner for the changelogs! Some good (hypothetical) titles: - Add test exercising new circuit button - Add tests for verifying built-in bridge connectivity - Develop a mock Lox authority for automated testing --> ## Description <!-- Provide an overview of the technical/implementation aspects of this test work a developer would need to know --> ## Scenarios <!-- Provide a list of high-level classes of desired test-cases and the expected behaviour of each --> <!-- Do not edit beneath this line <3 --> --- /label ~"Apps::Product::TorBrowser" /label ~"Apps::Type::Test"
.gitlab/issue_templates/031 Fingerprinting.md 0 → 100644 +149 −0 Original line number Diff line number Diff line # 👣 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"
