Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-02-26T10:44:58Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41692ESR115: decide on autoplay policy and lock it down [bugzilla 1812190]2024-02-26T10:44:58ZThorinESR115: decide on autoplay policy and lock it down [bugzilla 1812190]![tada](/uploads/3704853470111c30276016d6f0e46d06/tada.png)
[code](https://github.com/arkenfox/TZP/issues/233) so you know what is being tested
harden/lock prefs u guys
- about:preferences#privacy > permissions > autoplay > settings > ...![tada](/uploads/3704853470111c30276016d6f0e46d06/tada.png)
[code](https://github.com/arkenfox/TZP/issues/233) so you know what is being tested
harden/lock prefs u guys
- about:preferences#privacy > permissions > autoplay > settings > default for all websites
- this is `media.autoplay.default`
there are also other autoplay prefs, such as making things sticky or per element (user)
```
/* disable autoplay of HTML5 media if you interacted with the site [FF78+]
* 0=sticky (default), 1=transient, 2=user
* Firefox's Autoplay Policy Documentation (PDF) is linked below via SUMO
* [NOTE] If you have trouble with some video sites, then add an exception (2030)
* [1] https://support.mozilla.org/questions/1293231 ***/
user_pref("media.autoplay.blocking_policy", 2);
```
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getAutoplayPolicy
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/112https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16469Evaluate walkie-talkie website traffic fingerprinting defense2023-01-05T16:57:54ZGeorg KoppenEvaluate walkie-talkie website traffic fingerprinting defenseWalkie-Talkie (http://cacr.uwaterloo.ca/techreports/2015/cacr2015-08.pdf) is supposed to be an effective website fingerprinting defense which uses browser modifications. We should evaluate this approach at least and possible include it i...Walkie-Talkie (http://cacr.uwaterloo.ca/techreports/2015/cacr2015-08.pdf) is supposed to be an effective website fingerprinting defense which uses browser modifications. We should evaluate this approach at least and possible include it into 5.0 if it holds what it promises.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29745Exposed chrome:// resources can leak point releases, confirmed can leak app l...2024-03-03T00:39:25ZTracExposed chrome:// resources can leak point releases, confirmed can leak app languageThe default permissions defined in the chrome.manifest file allow specific paths to be called from any web page. For example, chrome://browser/content/* or chrome://global/content/*.
**For references see** https://bugzilla.mozilla.or...The default permissions defined in the chrome.manifest file allow specific paths to be called from any web page. For example, chrome://browser/content/* or chrome://global/content/*.
**For references see** https://bugzilla.mozilla.org/show_bug.cgi?id=1534581
**Trac**:
**Username**: flngerprlntSponsor 131 - Phase 2 - Privacy BrowserPier Angelo VendramePier Angelo Vendramehttps://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/42183Fingerprinting and Accessibility2023-11-02T11:12:00ZhenryFingerprinting and AccessibilityThis is a general issue to discuss the impact resist fingerprinting (RFP) is having on accessibility. Maybe we can organise some research and link related issues.
On the surface, there is a potential conflict between the goal of "make e...This is a general issue to discuss the impact resist fingerprinting (RFP) is having on accessibility. Maybe we can organise some research and link related issues.
On the surface, there is a potential conflict between the goal of "make every user look the same online" and the fact that lots of users have different needs and usage patterns. But there could be some room for improvement and creative thinking.
Some initial thoughts:
+ Tor browser is not only an anti-tracking tool. We want to make sure that users who need it for something else are not kept out by RFP.
+ Some decisions made for RFP also effect accessibility. For example, we force CSS media queries (prefers-contrast, prefers-color-scheme, prefers-reduced-motion).
+ Can we choose better values?
+ Can we allow for punching some holes in these?
+ Can we add some noise so that users who can handle either value can adopt random values to give users who *need* a specific value some cover?
+ Can we offer users guidance on tools outside of tor browser that improve accessibility without raising fingerprinting. E.g. tools that operate at the desktop level outside of web page's control, like magnifiers and color filters.
+ Users of accessibility tools can end up standing out in any behaviour analysis. E.g. if you navigate with a keyboard, then the website will receive a lot of Tab and arrow key events. Can we give them better cover?
/cc @donuts @clairehurst @dan @ma1 @pierov @richard @tjr @thorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/12977Fix Firefox's Full Screen Permissions Prompt2023-11-04T02:16:02ZMike PerryFix Firefox's Full Screen Permissions PromptIt looks like it may be slightly tricky but not impossible to fix the full screen permissions prompt. The full screen code lives in nsDocument::RequestFullScreen(). It actually registers an observer ("fullscreen-approved") topic for reac...It looks like it may be slightly tricky but not impossible to fix the full screen permissions prompt. The full screen code lives in nsDocument::RequestFullScreen(). It actually registers an observer ("fullscreen-approved") topic for reacting to the prompt, but then goes ahead and reparents the element and full screens anyway.
We might be able to refactor this code such that it gets called from the observer callback, after the user has interacted with the dialog.
Probably best done after FF31-ESR though.https://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/41339harden languages fingerprint: JS / accept headers [1746815]2024-03-25T09:32:30ZThorinharden languages fingerprint: JS / accept headers [1746815]@pierov `Fingerprinting` label please, TIA
about:preferences > language is not covered by RFP in any way (except when choosing to spoof english, after which it is no longer protected - spoof is a one off). Users can add additional langu...@pierov `Fingerprinting` label please, TIA
about:preferences > language is not covered by RFP in any way (except when choosing to spoof english, after which it is no longer protected - spoof is a one off). Users can add additional languages and/or even just change the order of e.g. `en-US,en` to `en,en-US` (which has been revealed in another ticket that a user did)
With RFP, we can harden this to parse the preference `intl.accept_languages` (which reflects the contents of `about:preferences` > `Language` > `Choose your preferred language for displaying pages` > `Choose`) for the first value, and to use this to return hardcoded values for both navigator.language, navigator.languages, and language accept header
I am pretty sure Mozilla has these all listed somewhere as the default settings per app language
for example: if first item is
- `en` or `en-US` or `en-GB` or `en-CA` - use `en-US,en`
- `de` or `de-DE` or `de-AT`, or `de-LI` or `de-LU` or `de-CH` - use `de, en-US, en`
- `?` various - use `nb-no, nb, no-no, no, nn-no, nn, en-us, en` (if bokmal)
- IDK why `en-us` is not `en-US`, just reporting what the pref says in TB's nb-no build
- there's two norwegians: `nb` bokmal, and `nn` nynorsk (and `no` norwegian), so I'm not 100% sure how you would reconcile e.g. `no` or `no-no` first
There's an open bugzilla on this [1746815](https://bugzilla.mozilla.org/show_bug.cgi?id=1746815), but only returning the first item is frought with compat issues. There's a reason there are additional language fallbacks.
This solution, detect the language (via pref or whatever) and use a hardcoded result (already listed somewhere) for navigator and accept headers would eliminate entropy here (and doesn't stop the user switching languages)
@tom FYISponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21610Hide about:profiles2023-11-27T09:35:33ZGeorg KoppenHide about:profiles`about:profiles` allows user things like creating new profiles or restarting with extensions disabled. This might lead to weird errors and there is probably no real use case in a Tor Browser context for that. We should hide it ideally wi...`about:profiles` allows user things like creating new profiles or restarting with extensions disabled. This might lead to weird errors and there is probably no real use case in a Tor Browser context for that. We should hide it ideally with an option to make it visible again if it is indeed needed for some reason.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13543HTML5 media support may lead to fingerprinting2023-11-04T02:09:56ZcypherpunksHTML5 media support may lead to fingerprintingI have found out that Tor Browser 4.0 can play videos that older versions of TBB couldn't. It's because the new firefox can load gstreamer plugins into the browser and play mp4 files (inside what I believe to be HTML5 player).
I fear thi...I have found out that Tor Browser 4.0 can play videos that older versions of TBB couldn't. It's because the new firefox can load gstreamer plugins into the browser and play mp4 files (inside what I believe to be HTML5 player).
I fear this means that gstreamer is able to connect directly or send sensitive information to the server where the video file is hosted.
If you change "media.gstreamer,enabled" to "false", it prevents gstreamer from being loaded, but it might cause fingerprinting problems.
Any thoughts on this? Should this be enabled? Or maybe change it in later versions.
It could still be used maybe in TAILS, to make vimeo and other websites able to play videos (using gstreamer in a more secure environment).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40656Identify fingerprintable preferences2023-11-04T01:36:58ZMatthew FinkelIdentify fingerprintable preferencesLet's identify all of the preferences (`about:preferences`) that are fingerprinting vectors. When that is complete, we should make that risk clear, and provide a recommendation.Let's identify all of the preferences (`about:preferences`) that are fingerprinting vectors. When that is complete, we should make that risk clear, and provide a recommendation.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20820Improve the choice for Japanese fonts on Linux (and possibly macOS)2023-08-18T22:46:54ZcypherpunksImprove the choice for Japanese fonts on Linux (and possibly macOS)Back with Tor Browser 5, I was able to install monafont on my computer and it would allow Shift-JIS fonts to render properly. Because Tor Browser now uses its own built-in fonts to make fingerprinting of system fonts harder, and because ...Back with Tor Browser 5, I was able to install monafont on my computer and it would allow Shift-JIS fonts to render properly. Because Tor Browser now uses its own built-in fonts to make fingerprinting of system fonts harder, and because there are no SJIS fonts, I can't correctly view any of it. SJIS is extremely sensitive to spacing, so an alternative font which renders the characters but does not render the spacing correctly does not work at all.
SJIS is used extensively on Japanese websites.
Look at https://ja.wikipedia.org/wiki/モナー (or https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%8A%E3%83%BC if the browser isn't displaying Japanese. Many Japanese characters do not display at all) and see if the examples it displays in SJIS are anything like the image which it displays on the right.
I have not tested on Windows, only Linux.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16110Improve Time Resolution Defense2023-01-05T15:47:25ZMike PerryImprove Time Resolution DefenseHovav Shacham and Keaton Mowery saw legacy/trac#1517 and emailed to point out some papers from the virtualization literature that have tried to deal with timing-based side channels. It turns out that simply reducing the granularity of th...Hovav Shacham and Keaton Mowery saw legacy/trac#1517 and emailed to point out some papers from the virtualization literature that have tried to deal with timing-based side channels. It turns out that simply reducing the granularity of the clock can still allow an adversary to extrapolate the true time by running a busy loop with a predictable operation in it. They provided a simple test that I updated and posted here https://people.torproject.org/~mikeperry/transient/tests/timingtest.html. It is able to recover the original time value with ~1-5ms accuracy.
They linked to this paper https://cseweb.ucsd.edu/~hovav/dist/xentimers.pdf, and suggested that the best approach would be:
> Pick some nominal granularity x. Then define a distribution (normal?) with mean at x. Clocks available to the program only ever show an exact multiple of x, with a clock-edge on transition. But they are lies: Immediately after a clock edge, the monitor draws some value t out of the distribution with mean x, and then sets a time-t timer; when that timer fires, the clock shown to the program is increased by x, and the monitor draws a new value t and continues.
In other words, we'd still report 100ms steps, but change when we bump that step by +/- 50ms or so, based on a random value.
While I'm at it, I should also see how well using window.requestAnimationFrame and setTimeout can reconstruct the clock.
Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers. There's also a new animation API (https://developer.mozilla.org/en-US/docs/Web/API/AnimationPlayer).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/16456inner window: affected by toggling chrome elements (menubar, titlebar, toolba...2024-03-12T09:04:02ZTracinner window: affected by toggling chrome elements (menubar, titlebar, toolbar, docked console, changing density)Hello,
when we are opening findbar panel (ctrl + F hotkeys) screen size will changes.
You may see javascript properties:
height
width
availHeight
availWidth
You may fix this with css style like this:
@namespace url(http://www.mozilla...Hello,
when we are opening findbar panel (ctrl + F hotkeys) screen size will changes.
You may see javascript properties:
height
width
availHeight
availWidth
You may fix this with css style like this:
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
findbar {
position: fixed !important;
bottom: 0px !important;
left: 0px !important;
width: 100% !important;
}
.findbar-closebutton.close-icon {
/*
* Do something with close findbar button
*/
}
**Trac**:
**Username**: tmpAnonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41930intl.accept_languages gets into a stuck modifed state2024-01-22T04:45:19ZThorinintl.accept_languages gets into a stuck modifed stategrrr ... so I was testing some locale changes for TB health checks: namely that the languages are exactly what they should be: i.e supported, correct case, correct order. And that the locale matches (language !== locale is not good enoug...grrr ... so I was testing some locale changes for TB health checks: namely that the languages are exactly what they should be: i.e supported, correct case, correct order. And that the locale matches (language !== locale is not good enough, e.g. `it-IT` language uses `it` locale), also correct case. I am excluding android for now as I believe that we don;t have parity and/or there is something going on with case (e.g. en-us, or even what is used, e.g. en vs en-US .. blah blah)
So I was messing around adding languages. Whilst in en-US, I added French, then Danish
![step1](/uploads/dc7274a024fe6abe89b92b5c47602f56/step1.png)
and when I added Danish, I got the apply and restart, so I did - and this is what happened
![wtf](/uploads/579165c908bccb5bf6be013e39c77e44/wtf.png)
so my locale matches Danish, but my languages were never set correctly. The languages in the UI are as per the first pic
So now I decide to go back to en-US and replicate my steps for you, so I choose to change to english and apply and restart and this is what I get - NOTE I cannot remove `Dansk` or `Francais` ... and after some more fiddling, can't remove `Espanol`, `Cestina`
![nowwhat](/uploads/9ca0fc73739c7201e5b91356ef62b9bb/nowwhat.png)
So not only does the UI become borked, but looking at the first image, we fubar the fingerprint. I think when we apply a language change we need to properly reset the UI and navigator properties **edit** AND locale
cc @pierovPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41680investgate file system API / OPFS2023-12-03T10:27:30ZThorininvestgate file system API / OPFSFF111+: [Origin private file system access](https://fs.spec.whatwg.org/) is now enabled, a new [storage API](https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API) that enables web applications to store and retrieve dat...FF111+: [Origin private file system access](https://fs.spec.whatwg.org/) is now enabled, a new [storage API](https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API) that enables web applications to store and retrieve data from and to the filesystem in a sandbox. - [1811001](https://bugzilla.mozilla.org/show_bug.cgi?id=1811001)
```js
dom.fs.enabled
```
e.g. does it leak timezone, chrome language?
[1748667](https://bugzilla.mozilla.org/show_bug.cgi?id=1748667) [meta] Add support for the WHATWG File System Standard
edit: also disk leak, sanitizing, FPI isolation?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28621Investigate "website fingerprinting through cache occupancy channel"2023-01-05T17:31:44ZArthur EdelsteinInvestigate "website fingerprinting through cache occupancy channel"See this paper:
https://arxiv.org/abs/1811.07153
> Robust Website Fingerprinting Through the Cache Occupancy Channel
> Anatoly Shusterman, Lachlan Kang, Yarden Haskal, Yosef Meltser, Prateek Mittal, Yossi Oren, Yuval Yarom
> (Submitted...See this paper:
https://arxiv.org/abs/1811.07153
> Robust Website Fingerprinting Through the Cache Occupancy Channel
> Anatoly Shusterman, Lachlan Kang, Yarden Haskal, Yosef Meltser, Prateek Mittal, Yossi Oren, Yuval Yarom
> (Submitted on 17 Nov 2018)
>
> Website fingerprinting attacks, which use statistical analysis on network traffic to compromise user privacy, have been shown to be effective even if the traffic is sent over anonymity-preserving networks such as Tor. The classical attack model used to evaluate website fingerprinting attacks assumes an on-path adversary, who can observe all traffic traveling between the user's computer and the Tor network. In this work we investigate these attacks under a different attack model, inwhich the adversary is capable of running a small amount of unprivileged code on the target user's computer. Under this model, the attacker can mount cache side-channel attacks, which exploit the effects of contention on the CPU's cache, to identify the website being browsed. In an important special case of this attack model, a JavaScript attack is launched when the target user visits a website controlled by the attacker. The effectiveness of this attack scenario has never been systematically analyzed,especially in the open-world model which assumes that the user is visiting a mix of both sensitive and non-sensitive sites. In this work we show that cache website fingerprinting attacks in JavaScript are highly feasible, even when they are run from highly restrictive environments, such as the Tor Browser .Specifically, we use machine learning techniques to classify traces of cache activity. Unlike prior works, which try to identify cache conflicts, our work measures the overall occupancy of the last-level cache. We show that our approach achieves high classification accuracy in both the open-world and the closed-world models. We further show that our techniques are resilient both to network-based defenses and to side-channel countermeasures introduced to modern browsers as a response to the Spectre attack.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41788investigate `ui.textScaleFactor` + `browser.display.os-zoom-behavior`2023-11-01T20:55:24ZThorininvestigate `ui.textScaleFactor` + `browser.display.os-zoom-behavior`pretty sure it landed in FF102
- FF104: [1777902](https://bugzilla.mozilla.org/show_bug.cgi?id=1777902) don't change the size of system fonts when ui.textScaleFactor is set
- something to read : https://www.askvg.com/fix-ui-scaling-and-l...pretty sure it landed in FF102
- FF104: [1777902](https://bugzilla.mozilla.org/show_bug.cgi?id=1777902) don't change the size of system fonts when ui.textScaleFactor is set
- something to read : https://www.askvg.com/fix-ui-scaling-and-large-fonts-issues-in-firefox-103-and-later-versions/#problem_solution
I don't know the reason or purpose behind this, or `browser.display.os-zoom-behavior` ... just another couple of variables to go with default zoom, zoom text, system scaling, dpi, device pixel ratio, layout.css.devPixelsPerPx
I tested it in FF and it affects newwin e.g. at 110 it opens larger but the inner windows (sans LBing) is out by many pixels. I didn't test LBing, sorry, just making a quick issue to follow up on in alpha 13 - when we can use @ma1 's patches
Without wanting to hamper accessibility, I think we need to look at locking most of these down - IIUIC users should be using system scalinghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42349investigate `use_us_english_locale` vs non-spoofing en-US2024-03-02T12:25:25ZThorininvestigate `use_us_english_locale` vs non-spoofing en-USsomething's not right and I have found non-deterministic results (AFAICT) - even when the locale is en-US - will fill in more details later
edit: or even worse, it's `use_us_english_locale` is not hooked up to all the Intl APIs and thus...something's not right and I have found non-deterministic results (AFAICT) - even when the locale is en-US - will fill in more details later
edit: or even worse, it's `use_us_english_locale` is not hooked up to all the Intl APIs and thus causes entropy right now. I _think_ we shouldn't even be using `use_us_english_locale` because all resolved options are en-US (which is the locale we set) and therefore all Intl is already covered. The pref is causing discrepancies (depends on some OS factors IIUIC)
It's either broken now, or will be broken next ESR
---
`use_us_english_locale` is deprecated come ESR128, and we need to check spoof english and setting the locale is enoughThorinThorin