Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-26T20:22:16Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41676Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth2024-03-26T20:22:16ZTom Rittertom@ritter.vgSet privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depthSee https://bugzilla.mozilla.org/show_bug.cgi?id=1709867#c21 - we're changing how to spoof the timezone to make way for fine-grained control of that aspect of RFP. On Nightly we _by default_ have changed the behavior of RFP. Tor Browse...See https://bugzilla.mozilla.org/show_bug.cgi?id=1709867#c21 - we're changing how to spoof the timezone to make way for fine-grained control of that aspect of RFP. On Nightly we _by default_ have changed the behavior of RFP. Tor Browser should flip this pref to true to keep the old behavior until we are certain their are no leaks. This will be landing on Nightly soon, so eventually it will ride to Release and affect Android.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41625newwin: Review Bugzilla 1816503 (Window resizing logic updated FF112)2024-03-12T09:04:47Zrichardnewwin: Review Bugzilla 1816503 (Window resizing logic updated FF112)Window resizing logic updated in https://bugzilla.mozilla.org/show_bug.cgi?id=1816503. We should make sure everything here works for us when we get to ~"FF115-esr"
/cc @ma1 @thorinWindow resizing logic updated in https://bugzilla.mozilla.org/show_bug.cgi?id=1816503. We should make sure everything here works for us when we get to ~"FF115-esr"
/cc @ma1 @thorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41604Unable to login to https://accounts.firefox.com/ on TB 122023-11-17T15:59:22ZcypherpunksUnable to login to https://accounts.firefox.com/ on TB 12https://accounts.firefox.com/
```
500 Error
Oh dear, something went wrong there. We've been notified and will get working on a fix.
```
```
n@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.b...https://accounts.firefox.com/
```
500 Error
Oh dear, something went wrong there. We've been notified and will get working on a fix.
```
```
n@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:13512
diff@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:13673
getLoad@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:16126
getAllData@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:24310
getFilteredData@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:25652
flush@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:23291
logEvent@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:26424
logView@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:27200
logView@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:1:37891
showView/</<@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/app.bundle.en_US.js:9:111501
invoke@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:6401
run@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:1809
R/<@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:99:2761
invokeTask@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:7019
runTask@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:2424
m@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:9056
invokeTask@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:84:8124
p@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:115:743
d@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:115:1058
_@https://accounts-static.cdn.mozilla.net/bundle-8d3a82a32addcefec372e3c48273d0afc905e39d/appDependencies.bundle.js:115:1357
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41585Inner letterbox jiggles as border is dragged2024-03-12T09:04:02ZcypherpunksInner letterbox jiggles as border is draggedTBB 12.0.2 lists #32308 in its changelog. @richard closed that issue, saying, "Looks like we're done here." Huh? Didn't anyone test it?? Because I'm still observing jiggling/jitter in 12.0.2 Linux 64-bit.
1. In TBB 12.0.2 desktop, open ...TBB 12.0.2 lists #32308 in its changelog. @richard closed that issue, saying, "Looks like we're done here." Huh? Didn't anyone test it?? Because I'm still observing jiggling/jitter in 12.0.2 Linux 64-bit.
1. In TBB 12.0.2 desktop, open https://arkenfox.github.io/TZP/tzp.html
2. Slowly drag one side of the window horizontally.
3. While dragging, observe the line for "inner window... [LB] [RFP NewWin]" flickering red and the numbers changing a few pixels.
Heck, you could try it on the page of the original issue, #32308, and watch the content wrapping go crazy.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41551Investigate WebGPU usage2023-06-01T17:18:57ZrichardInvestigate WebGPU usageSo it seems WebGPU has been enabled by default in nightly, presumably it will make its way to the stable channel once Mozilla is happy with it. We should have a look at WebGPU fingerprintability and maybe ensure it's disabled come ~"FF11...So it seems WebGPU has been enabled by default in nightly, presumably it will make its way to the stable channel once Mozilla is happy with it. We should have a look at WebGPU fingerprintability and maybe ensure it's disabled come ~"FF115-esr"
Upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1746245https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41523Tor Browser 12.0 does not respect `user.js`/default settings on first start2024-03-03T00:34:17ZChrisKTor Browser 12.0 does not respect `user.js`/default settings on first start<!--
* Use this issue template for reporting a new bug.
-->
Crosslink: https://forum.torproject.net/t/tor-browser-12-0-does-not-respect-user-js-default-settings-on-first-start/5894
### Summary
Before Tor Browser 12.0 it was possible to...<!--
* Use this issue template for reporting a new bug.
-->
Crosslink: https://forum.torproject.net/t/tor-browser-12-0-does-not-respect-user-js-default-settings-on-first-start/5894
### Summary
Before Tor Browser 12.0 it was possible to provide default settings to a “fresh” Tor Browser installation. This is mainly useful for defaulting to “Safest” security slider:
```
user_pref("browser.security_level.security_slider", 1);
```
(named `extensions.torbutton.security_slider` in previous versions, I guess)
Issue with 12.0: default settings are not respected on first browser startup (when `profile.default` is not initialized yet) - the browser instance needs to be closed and restarted. This is suboptimal for virtual/temporary environments, that bootstrap a fresh profile on startup.
From my own tests, Firefox ESR 102.5.0 correctly applies `user.js` or [Firefox AutoConfig](https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig) properly on first start, hence likely no upstream problem.
I am wondering, is this a new bug or intended security feature?
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Download and extract `tor-browser-linux64-12.0_ALL.tar.xz`, so there is a fresh, uninitialized profile
2. Before start, Either copy `user.js` manually to `tor-browser/Browser/TorBrowser/Data/Browser/profile.default/user.js`, with content:
```
user_pref("browser.security_level.security_slider", 1);
```
Same result also, when AutoConfig is used with `pref`, see also Workaround section down under.
3. Tor Browser won’t have safest security level after startup. It needs to be closed and restarted, now with proper setting applied.
### Workaround
After some more evaluation, the only remaining way possible is to use `lockPref` instead of `pref` for AutoConfig, `user_pref`/`user.js` being not possible at all.
Download fresh Tor Browser (step 1) above, now instead of copying `user.js`, do following for AutoConfig (assuming `tor-browser` as root extraction dir):
```sh
cat > tor-browser/Browser/defaults/pref/autoconfig.js <<'EOF'
pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);
EOF
cat > tor-browser/Browser/firefox.cfg <<'EOF'
// TORBROWSER DEFAULTS
lockPref("browser.security_level.security_slider", 1);
lockPref("intl.language_notification.shown", true);
EOF
```
But `lockPref` seems too restrictive, doesn't allow `user.js` to be used and does not provide additional security benefits.
### What is the current bug behavior?
`user.js` is not respected. Firefox AutoConfig is not respected, except when using `lockPref`.
### What is the expected behavior?
Behave like previous Tor Browser versions, in accordance with `user.js` and AutoConfig Firefox ESR default setting capabilities.
### Environment
Operating System
Debian 11
Tor Browser version
12.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41474Hacky Racers: Exploiting Instruction-Level Parallelism to Generate Stealthy F...2023-01-09T15:50:57ZrichardHacky Racers: Exploiting Instruction-Level Parallelism to Generate Stealthy Fine-Grained TimersFrom HackerOne:
---
## Summary:
We develop Hacky Racers, a new type of timing gadget that uses instruction-level parallelism, another key feature of out-of-order execution, to measure arbitrary fine-grained timing differences, even in...From HackerOne:
---
## Summary:
We develop Hacky Racers, a new type of timing gadget that uses instruction-level parallelism, another key feature of out-of-order execution, to measure arbitrary fine-grained timing differences, even in the presence of highly restricted JavaScript sandbox environments. While Tor browser mitigates timing side channels by reducing timer precision and removing language features such as SharedArrayBuffer that can be used to indirectly generate timers via thread-level parallelism, no such restrictions can be designed to limit Hacky Racers. We also design versions of Hacky Racers that require no misspeculation whatsoever, demonstrating that transient execution is not the only threat to security from modern microarchitectural performance optimization.
Finally, we use Hacky Racers to construct novel backwards-in-time Spectre gadgets, which break many hardware counter-measures in the literature by leaking secrets before misspeculation is discovered.
## Steps To Reproduce:
please refer to the attached paper
## Impact
Fine-grained timers would be so easy to generate so that the mitigation provided by removing sharedarraybuffer becomes totally meaningless.
---
Upstream issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1782238
[Hacky_Racers__Exploiting_Instruction-Level_Parallelism_to_Generate_Stealthy_Fine-Grained_Timers.pdf](/uploads/003a5206675566bb14afd3bf48db7710/Hacky_Racers__Exploiting_Instruction-Level_Parallelism_to_Generate_Stealthy_Fine-Grained_Timers.pdf)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41467compat: always return true for navigator.beacon but disable the API2024-03-19T17:45:33ZThorincompat: always return true for navigator.beacon but disable the APIfrom https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40783#note_2854455
> - [x] `beacon.enabled` **very interesting**
References
- https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
- https://gitla...from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40783#note_2854455
> - [x] `beacon.enabled` **very interesting**
References
- https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
- https://gitlab.com/librewolf-community/browser/source/-/issues/83 - an example of known site breakage (edit: with beacon disabled)
- https://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#1138-1179 - where to patch?
@tom seems trivial. Edit: IDK if the above would cause more breakage than it solves (edit: i.e vs just having beacon disabled)
@pierov why is this **very interesting** (I have my own thoughts, want to hear yours)?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41319investigate system-ui changes affecting widgets2023-01-05T15:36:10ZThorininvestigate system-ui changes affecting widgetsfrom https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41116#note_2836154 - @pierov `Fonts` label, feel free to clean up the title
STR
- https://arkenfox.github.io/TZP/tzp.html#fonts
- click on `[widget] fonts` ... `de...from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41116#note_2836154 - @pierov `Fonts` label, feel free to clean up the title
STR
- https://arkenfox.github.io/TZP/tzp.html#fonts
- click on `[widget] fonts` ... `details` and check your console
e.g: en-US
```
Firefox (windows)
"button: MS Shell Dlg \\32 , 13.3333px"
"checkbox: MS Shell Dlg \\32 , 13.3333px"
"color: MS Shell Dlg \\32 , 13.3333px"
"combobox: MS Shell Dlg \\32 , 13.3333px"
"radio: MS Shell Dlg \\32 , 13.3333px"
"text: MS Shell Dlg \\32 , 13.3333px"
"datetime: monospace, 13.3333px"
"datetime-local: monospace, 13.3333px"
"textarea: monospace, 13px"
TB with system-ui patch (windows)
"button: sans-serif, 13.3333px"
"checkbox: sans-serif, 13.3333px"
"color: sans-serif, 13.3333px"
"combobox: sans-serif, 13.3333px"
"radio: sans-serif, 13.3333px"
"text: sans-serif, 13.3333px"
"datetime: monospace, 13.3333px"
"datetime-local: monospace, 13.3333px"
"textarea: monospace, 13px"
```
but `sans-serif` !== `MS Shell Dlg \\32`, so we end up with changes, including the chrome
you can visual check by looking at http://stephenhorlander.com/form-controls.html
Here are two pics, open them in separate tabs and toggle between them to see the changes
<details><summary>click me for pics</summary><p>
![nopatch](/uploads/45d137fb0e697a4607864a1be51cd2bc/nopatch.png)
![patch](/uploads/afb461f8d4178e50847035afd9105044/patch.png)
</p></details>https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41305Using "Large Text" accessibility setting in Gnome applies measurable font sca...2023-11-05T04:30:30ZhenryUsing "Large Text" accessibility setting in Gnome applies measurable font scaling and disrupts letterboxingGnome has an accessibility setting called "Large Text". This is also sometimes used by users who basically want 1.25 screen scaling, which is not yet stable in Gnome, even though it has different effects.
I'm not sure exactly what this ...Gnome has an accessibility setting called "Large Text". This is also sometimes used by users who basically want 1.25 screen scaling, which is not yet stable in Gnome, even though it has different effects.
I'm not sure exactly what this does under the hood, but one of the effects is that GDK will expose the screen DPI as 120 rather than 96. On the firefox side:
+ This is used for the font size DPI https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/accd3b2dd88103fbe01442c558f877e2c47fe150/gfx/thebes/gfxPlatformGtk.cpp#L435
+ Which means the font scale factor will be 1.25 https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/accd3b2dd88103fbe01442c558f877e2c47fe150/gfx/thebes/gfxPlatformGtk.cpp#L461
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1604761
If a tor browser user has switched on this system setting, then it can make them appear more unique and contribute to their fingerprint. I found two ways to do this.
### 1. Test element
You can test indirectly for the font scaling that firefox applies by inserting an element into your page
```html
<span>test</span>
```
and measuring it.
### 2. Letterboxing
The letterboxing will still control the browser window sizing in steps. However, the `height` and `width` values for the `window.visualViewport` are non-integer values, rather than the integer values, which would distinguish a user using "Large Text". E.g.
```js
VisualViewport { offsetLeft: 0, offsetTop: 0, pageLeft: 0, pageTop: 0, width: 800.7999877929688, height: 450.3999938964844, scale: 1 }
```
Moreover, I noticed in manual testing that as you incrementally adjust the window height, the browser viewport height would jump between two close values, which further degrades the letterboxing. E.g. `450.3999938964844` and `449.6000061035156`.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41301Dynamic Voltage and Frequency Scaling fingerprinting2022-11-30T15:28:27ZThorinDynamic Voltage and Frequency Scaling fingerprintingjust throwing this here so we don't forget
https://github.com/Diptakuet/DF-SCA-Dynamic-Frequency-Side-Channel-Attacks-are-Practical
> We present DF-SCA, which is a software-based dynamic frequency side-channel attack on Linux and Andro...just throwing this here so we don't forget
https://github.com/Diptakuet/DF-SCA-Dynamic-Frequency-Side-Channel-Attacks-are-Practical
> We present DF-SCA, which is a software-based dynamic frequency side-channel attack on Linux and Android OS devices. We show that Dynamic Voltage and Frequency Scaling (DVFS) feature in modern systems can be utilized to perform website fingerprinting attacks for Google Chrome and Tor browsers on modern Intel, AMD, and ARM architectures.
@tom FYI @richard `fingerprint` label thanks :)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41235Rate limit gyroscope sampling frequency on FF mobile2022-11-30T14:52:17ZMike PerryRate limit gyroscope sampling frequency on FF mobileBy the time we get around to an official mobile port, we should double-check that Mozilla has reduced the sampling rate of the gyroscope on Android:
http://crypto.stanford.edu/gyrophone/files/gyromic.pdfBy the time we get around to an official mobile port, we should double-check that Mozilla has reduced the sampling rate of the gyroscope on Android:
http://crypto.stanford.edu/gyrophone/files/gyromic.pdfhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41233Fenix fingerprinting2022-09-01T22:43:30ZThorinFenix fingerprintingAs I come across Fenix-only items I will add them here for consideration: sysrqb & gk know how to get hold of me if you need a PoC
- toolbar location can be detected
- Settings > Customize > Toolbar > Top/Bottom
- font inflation can ...As I come across Fenix-only items I will add them here for consideration: sysrqb & gk know how to get hold of me if you need a PoC
- toolbar location can be detected
- Settings > Customize > Toolbar > Top/Bottom
- font inflation can be detected
- Settings > Accessibility > Automatic Font Sizing
Feel free to add more itemshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41116Review Mozilla 1226042: add support for the new 'system-ui' generic font family2024-03-06T08:59:35ZrichardReview Mozilla 1226042: add support for the new 'system-ui' generic font family## https://bugzilla.mozilla.org/show_bug.cgi?id=1226042
Added a default system-ui font in FF92. We should make sure this doesn't interfere with any of our font-related patches, particularly our patch for tor-browser#41043## https://bugzilla.mozilla.org/show_bug.cgi?id=1226042
Added a default system-ui font in FF92. We should make sure this doesn't interfere with any of our font-related patches, particularly our patch for tor-browser#41043Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41042some dynamic images display poorly without access to HTML5 canvas image data2023-01-05T17:48:36ZJeremy Benthamsome dynamic images display poorly without access to HTML5 canvas image data<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Certain dynamic images for which HTML5 canvas image data are requested do not render correctly without explicitly agreeing to share HTML5 canvas image data. For ex...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Certain dynamic images for which HTML5 canvas image data are requested do not render correctly without explicitly agreeing to share HTML5 canvas image data. For example, maps provided by `mapbox.com` seem to have this problem by default, even though there is no indication of a problem when attempting to load these images using ordinary Firefox. Loading [a page that embeds a resource from `mapbox.com`](https://www.wunderground.com/wundermap) in Tor Browser yields an image that looks like this:
![mapbox-random](/uploads/46f4d583549a98f77a8bbd165843377c/mapbox-random.png)
**EXHIBIT A**
The stripey pattern in Exhibit A appears to result from the random canvas data that Tor Browser is configured to provide by default. The randomisation can be removed, although the resulting images are still broken. When the user sets `privacy.resistFingerprinting.randomDataOnCanvasExtract` to **false**, the result is that white rectangles appear instead of stripey patterns:
![mapbox-norandom](/uploads/c8833599d762985622a99f6f4cbf0554/mapbox-norandom.png)
**EXHIBIT B**
Please note that such sites request HTML5 canvas image data via an icon in the URL bar. If a user opens the dialog and chooses to explicitly **allow** access to HTML5 canvas image data to the site, then Tor Browser will display the embedded content correctly, like this:
![mapbox-dangerous](/uploads/3b151b5b9c7cb86bb20e3b0dcbf0cb00/mapbox-dangerous.png)
**EXHIBIT C**
Note that vanilla Firefox always renders correctly (as in Exhibit C) and does not ask for HTML5 canvas image data. Suggest it is reasonable to conflude that vanilla Firefox allows (dangerous) access to HTML5 canvas image data by default.
**Expected behaviour**
I am not sure why canvas image data are actually necessary to render this image correctly; I would hope that there would be a way to provide something generic to the requesting site, revealing nothing while allowing such images to render correctly.
**Environment**
The behaviour described in this bug report was observed in both Tor Browser 11.0.14 and Tor Browser 11.0.15. The dangerous behaviour in vanilla Firefox was observed in 91.11.0esr (Debian).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026Tor Browser doesn't respect user set changes to Colors and Appearance2023-11-02T09:44:41Zchampionquizzerchampionquizzer@torproject.orgTor Browser doesn't respect user set changes to Colors and AppearanceA user has reported to the [forum](https://forum.torproject.net/t/color-settings-in-tor-11-0-14/3609) and also to frontdesk:
> I installed Tor 11.0.14 en(us) version on my Windows 7 Home Premium 64-bit. Because of my bad eyes I use hig...A user has reported to the [forum](https://forum.torproject.net/t/color-settings-in-tor-11-0-14/3609) and also to frontdesk:
> I installed Tor 11.0.14 en(us) version on my Windows 7 Home Premium 64-bit. Because of my bad eyes I use high contrast theme on my computer with yellow text on black background. In Tor browser I immediately went to Settings > Colors and set Text to yellow, Background to black, checked Use system colors and selected Always. The same setting I use successfully in Firefox. But in Tor browser nothing happened.
If there is Use system colors checked or unckecked, if there is selected Always or Never, displayed pages don’t change their backgroud nor text colors. Only menus and Settings tab display their colors according to selected Windows theme (text and background colors). Displayed internet pages ignore any color settings made in Tor browser Settings tab.This is completely different behaviour from original Firefox browser.
What is the problem here?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40944Prompt if Tor Browser is zoomed2023-11-04T01:34:46ZbugzillaPrompt if Tor Browser is zoomedDon't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in legacy/trac#7255?
Because zooming changes resolution to very rare values.Don't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in legacy/trac#7255?
Because zooming changes resolution to very rare values.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40858Quantize innerWidth/Height when pages are zoomed2024-03-12T09:04:02ZArthur EdelsteinQuantize innerWidth/Height when pages are zoomedFollow up to legacy/trac#14429Follow up to legacy/trac#14429https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40704Minimize fingerprintability of scroll interval/rate2023-09-01T03:04:17ZSeirdyMinimize fingerprintability of scroll interval/rateScroll behavior can vary across devices, configurations, and hands. The scrolling behavior on small vs. large touchpads (with two-finger scrolling), "clicky" mouse wheels with different scroll intervals, smooth "rolling" mouse wheels, ke...Scroll behavior can vary across devices, configurations, and hands. The scrolling behavior on small vs. large touchpads (with two-finger scrolling), "clicky" mouse wheels with different scroll intervals, smooth "rolling" mouse wheels, key-taps, and key repeats (with different repeat rates) are all different.
With JavaScript or [lazy loading](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40056), a page can track where a user has scrolled. JS could track whether a user scrolls in discrete or continuous increments, in long sweeping gestures or short bursts, at variable or continuous speeds, etc. There should be a good amount of entropy available.
Possible mitigations:
- Tor Browser: have scrolling only function in fixed or percent-based increments on "Safer" or "Safest" mode.
- Tor Browser: have scrolling only work with keyboard input on "Safest" mode, as it has less variability (I think).
- Users: use Whonix/Kicksecure default settings with its keystroke anonymizer.
- Users: stick to using pgup/pgdn buttons with letterboxing enabled.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40558resistfingerprinting: Canvas Image Upload2023-12-01T22:18:31ZMatthew Finkelresistfingerprinting: Canvas Image UploadThis is the parent ticket for collecting duplicates of this issue. This is a bug that needs fixing in Firefox/Geckoview.
The Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1631673.This is the parent ticket for collecting duplicates of this issue. This is a bug that needs fixing in Firefox/Geckoview.
The Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1631673.