|
|
1
|
+# 👣 Fingerprinting
|
|
|
2
|
+<!--
|
|
|
3
|
+Use this template to track a browser fingerprinting vector. Such vectors
|
|
|
4
|
+allow for stateless cross-site tracking (i.e. across somehow collaborating
|
|
|
5
|
+but otherwise unrelated 1st party domains like foo.com and bar.com)
|
|
|
6
|
+
|
|
|
7
|
+For the purposes of developing a fix, this template is meant to define all of the things
|
|
|
8
|
+we want to think about and analyze before implementing a fix. It's totally fine to leave
|
|
|
9
|
+parts of this template empty on initial report! The the issue description can be updated
|
|
|
10
|
+and edited as we learn things.
|
|
|
11
|
+
|
|
|
12
|
+This template is also meant to serve as documentation/explanation about how we think
|
|
|
13
|
+about fingerprinting vectors and minimising their utility.
|
|
|
14
|
+-->
|
|
|
15
|
+
|
|
|
16
|
+## Problem Statement
|
|
|
17
|
+<!--
|
|
|
18
|
+Please give an overview of the problem you think we should address.
|
|
|
19
|
+ e.g. system fonts (`font: caption`) might expose desktop
|
|
|
20
|
+ environment/distribution/language/customization because Firefox uses OS
|
|
|
21
|
+ settings.
|
|
|
22
|
+-->
|
|
|
23
|
+
|
|
|
24
|
+## Documentation
|
|
|
25
|
+<!--
|
|
|
26
|
+Please provide a links to the relevant standards or documentation for the affected web
|
|
|
27
|
+platform features. Additionally, please provide links to relevant academic research,
|
|
|
28
|
+upstream Bugzilla issues, etc (if available).
|
|
|
29
|
+-->
|
|
|
30
|
+
|
|
|
31
|
+## Repro Steps
|
|
|
32
|
+<!--
|
|
|
33
|
+Please provide any proof of concept which can help us under how this feature
|
|
|
34
|
+can be used for fingerprinting and that we can use as a test for our patches.
|
|
|
35
|
+-->
|
|
|
36
|
+
|
|
|
37
|
+## Analysis
|
|
|
38
|
+
|
|
|
39
|
+### Metric Distribution
|
|
|
40
|
+<!--
|
|
|
41
|
+- How many different possible buckets of values exist without fingerprinting
|
|
|
42
|
+mitigations?
|
|
|
43
|
+- How are users distributed between these buckets?
|
|
|
44
|
+- Do any group of users stand-out by default?
|
|
|
45
|
+- Do users in each of these buckets likely have different risk profiles?
|
|
|
46
|
+-->
|
|
|
47
|
+
|
|
|
48
|
+### Metric Stability
|
|
|
49
|
+<!--
|
|
|
50
|
+- How does the metric change during and between browsing sessions without mitigations?
|
|
|
51
|
+ e.g. Window size may be mostly stable during a browsing session
|
|
|
52
|
+ but may change between browsing sessions
|
|
|
53
|
+ e.g. User-Agent string is stable during a browsing session, but may change
|
|
|
54
|
+ between major browser updates
|
|
|
55
|
+-->
|
|
|
56
|
+
|
|
|
57
|
+## Mitigation Strategy
|
|
|
58
|
+<!--
|
|
|
59
|
+Outline (at least) one of the possible mitigation strategies for this metric
|
|
|
60
|
+(normalisation, randomisation, or disabling)
|
|
|
61
|
+-->
|
|
|
62
|
+
|
|
|
63
|
+### Normalisation
|
|
|
64
|
+<!--
|
|
|
65
|
+Describe a strategy whereby all users report the same value for the metric, or the pros
|
|
|
66
|
+and cons if there are multiple potential normalisation strategies.
|
|
|
67
|
+ e.g. Standardising reported WebGL constants such as maximum framebuffer size
|
|
|
68
|
+- After normalisation, would this metric be equivalent another normalised metric?
|
|
|
69
|
+ e.g. fonts are usually equivalent to the OS, which is already exposed.
|
|
|
70
|
+- Sometimes it is impossible to use the same value for all users, but reducing the
|
|
|
71
|
+ number of user buckets is still a win.
|
|
|
72
|
+
|
|
|
73
|
+✅ This is the preferred mitigation strategy.
|
|
|
74
|
+-->
|
|
|
75
|
+
|
|
|
76
|
+### Randomisation
|
|
|
77
|
+<!--
|
|
|
78
|
+Describe a strategy whereby users return randomised metrics
|
|
|
79
|
+ e.g. when enumerating webcams, choose a number of devices from a `[1; 3]` uniform
|
|
|
80
|
+ distribution
|
|
|
81
|
+- How did you choose this distribution and its parameters?
|
|
|
82
|
+- What strategies should we use to hide the randomization?
|
|
|
83
|
+ e.g. randomize the value only once per session and per first-party
|
|
|
84
|
+- Why is it not possible to use a normalized value, instead? Normalization is often
|
|
|
85
|
+ better than randomization because it is often easier to conceal
|
|
|
86
|
+
|
|
|
87
|
+A randomised metric should ideally be:
|
|
|
88
|
+- Different per first party domain
|
|
|
89
|
+ e.g. different websites measure a different value for the metric
|
|
|
90
|
+- Stable per session per first party domain
|
|
|
91
|
+ e.g. a website repeatedly measuring the metric will get back the same value
|
|
|
92
|
+ during the same browsing session
|
|
|
93
|
+- Different between sessions, regardless of first party domain
|
|
|
94
|
+ e.g. a website measuring a metric between browsing sessions will get back a different
|
|
|
95
|
+ value
|
|
|
96
|
+
|
|
|
97
|
+⚠️ We should only resort to randomisation if providing normalised values completely
|
|
|
98
|
+and utterly breaks web compatibility, usability, or accessibility.
|
|
|
99
|
+-->
|
|
|
100
|
+
|
|
|
101
|
+### Disabling
|
|
|
102
|
+<!--
|
|
|
103
|
+Describe a strategy whereby the fingerprintable metric is just outright disabled
|
|
|
104
|
+ e.g. Disabling WebAuthN feature entirely
|
|
|
105
|
+- Why is it not possible to spoof a (normalized) value instead? Disabling an API might
|
|
|
106
|
+ break some sites.
|
|
|
107
|
+ e.g. Rejecting the permission prompt request promise would be preferable to removing
|
|
|
108
|
+ or disabling the relevant APIs
|
|
|
109
|
+- Is this a temporary change?
|
|
|
110
|
+ e.g. necessary on the ESR version of Firefox we use for Tor Browser, but fixed in a
|
|
|
111
|
+ later version of Firefox.
|
|
|
112
|
+-->
|
|
|
113
|
+
|
|
|
114
|
+## Other Considerations
|
|
|
115
|
+
|
|
|
116
|
+### Usability and Accessibility
|
|
|
117
|
+<!--
|
|
|
118
|
+- Would the proposed mitigation make websites unusable for non-technical/human reasons?
|
|
|
119
|
+ e.g. Always requesting language as en-US makes websites usable for non English-reading
|
|
|
120
|
+ users
|
|
|
121
|
+- Would it make the browser unusable for some users?
|
|
|
122
|
+ e.g. Forcing overlay scrollbars would make websites unusable for some users with motor
|
|
|
123
|
+ issues
|
|
|
124
|
+- Do we need to provide a user-accessible 'escape-hatch' to allow users to opt-out of the
|
|
|
125
|
+ proposed mitigation?
|
|
|
126
|
+ e.g. Providing an option in about:preferences
|
|
|
127
|
+-->
|
|
|
128
|
+
|
|
|
129
|
+### Web Compatibility
|
|
|
130
|
+<!--
|
|
|
131
|
+Would the proposed mitigation break websites for technical reasons?
|
|
|
132
|
+ e.g. Disabling WebAuthN preventing YubiKey authentication
|
|
|
133
|
+-->
|
|
|
134
|
+
|
|
|
135
|
+### Plausibility
|
|
|
136
|
+<!--
|
|
|
137
|
+Would the proposed mitigation make the browser stand out as a potential bot or scraper or
|
|
|
138
|
+some other non-standard browser configuration?
|
|
|
139
|
+ e.g. Reporting only 2 CPU-cores is unlikely for modern PCs in the year 2025
|
|
|
140
|
+-->
|
|
|
141
|
+
|
|
|
142
|
+<!-- Do not edit beneath this line <3 -->
|
|
|
143
|
+
|
|
|
144
|
+---
|
|
|
145
|
+
|
|
|
146
|
+/confidential
|
|
|
147
|
+/label ~"Apps::Product::BaseBrowser"
|
|
|
148
|
+/label ~"Project 131"
|
|
|
149
|
+/label ~"Fingerprinting" |