Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2022-11-10T21:33:53Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27258font whitelist means we don't have to set gfx.downloadable_fonts.fallback_delay2022-11-10T21:33:53ZArthur Edelsteinfont whitelist means we don't have to set gfx.downloadable_fonts.fallback_delayIn 8455, "gfx.downloadable_fonts.fallback_delay" was set to -1 to avoid temporarily rendering a local font, which would allow its characters to be measured. But now that we whitelist fonts, it is probably OK to stop setting this pref. We...In 8455, "gfx.downloadable_fonts.fallback_delay" was set to -1 to avoid temporarily rendering a local font, which would allow its characters to be measured. But now that we whitelist fonts, it is probably OK to stop setting this pref. We should confirm that the fallback mechanism doesn't provide a whitelist bypass.Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27128Consider homogenizing HTTP/2 Settings prefs.2022-10-28T19:15:20ZArthur EdelsteinConsider homogenizing HTTP/2 Settings prefs.From #14592:
> * SETTINGS_HEADER_TABLE_SIZE depends on the "network.http.spdy.default-hpack-buffer" pref. In Firefox it is set by default to 65536 on desktop and 4096 on mobile.
> * SETTINGS_ENABLE_PUSH and SETTINGS_MAX_CONCURRENT_STREA...From #14592:
> * SETTINGS_HEADER_TABLE_SIZE depends on the "network.http.spdy.default-hpack-buffer" pref. In Firefox it is set by default to 65536 on desktop and 4096 on mobile.
> * SETTINGS_ENABLE_PUSH and SETTINGS_MAX_CONCURRENT_STREAMS depend on "network.http.spdy.allow-push" pref, which is "true" by default.
> * SETTINGS_INITIAL_WINDOW_SIZE depends on "network.http.spdy.push-allowance", which is 131072 on desktop and 32768 on mobile by default.
> * SETTINGS_MAX_FRAME_SIZE is always set to 0x4000.
>
> The above prefs don't provide significant entropy, unless the user has modified the one or more of them from their default value. Otherwise they mainly serve to distinguish different browsers or platforms.
We could consider making these prefs all the same, to avoid this extra distinction between platforms. But are there performance drawbacks?Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25559Miscellaneous security- and privacy-related prefs for Tor Browser2022-11-09T18:38:53ZArthur EdelsteinMiscellaneous security- and privacy-related prefs for Tor BrowserJKT has been working on some prefs he suggested we might consider:
* Security.mixed_content.upgrade_display_content
* Upgrades passive mixed content to HTTPS transparently
* Network.ftp.enabled
* disable FTP
* security.insecure_conne...JKT has been working on some prefs he suggested we might consider:
* Security.mixed_content.upgrade_display_content
* Upgrades passive mixed content to HTTPS transparently
* Network.ftp.enabled
* disable FTP
* security.insecure_connection_icon.enabled and security.insecure_connection_icon.pbmode.enabled
* security.insecure_connection_text.enabled and security.insecure_connection_text.pbmode.enabled
* Both of these mark HTTP connections as insecure. One with a broken lock icon, the other with text saying ‘Not Secure’
* Insecure flash content:
* security.mixed_content.block_object_subrequest
* Sensors:
* device.sensors.*.enabled (motion, proximity, ambientLight and orientation) && the Event constructors are now also included in device.sensors.enabled
* `device.sensors.enabled` set to False in RF (https://bugzilla.mozilla.org/show_bug.cgi?id=1369319)
* dom.registerProtocolHandler.insecure.enabled
* browser.cache.offline.insecure.enable
* dom.registerContentHandler.enabled
Others being pondered:
* Http-disabled
* I believe this is to block all HTTP connections.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24686In Tor Browser context, should network.http.tailing.enabled be set to false?2022-10-14T19:38:30ZcypherpunksIn Tor Browser context, should network.http.tailing.enabled be set to false?Here's what `network.http.tailing.enabled` does: https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/ It depends on Disconnect's tracking list.
In Tor Browser context I'm not sure whether this would be beneficial.Here's what `network.http.tailing.enabled` does: https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/ It depends on Disconnect's tracking list.
In Tor Browser context I'm not sure whether this would be beneficial.Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23451Adapt font whitelist to changes on macOS (zh locales)2022-12-02T11:21:12ZGeorg KoppenAdapt font whitelist to changes on macOS (zh locales)https://bugzilla.mozilla.org/show_bug.cgi?id=1350766 wants to use Songti TC/SC for macOS as default fonts. We should check whether we need to update the related font whitelist.
(This is the ticket for https://lists.torproject.org/piperm...https://bugzilla.mozilla.org/show_bug.cgi?id=1350766 wants to use Songti TC/SC for macOS as default fonts. We should check whether we need to update the related font whitelist.
(This is the ticket for https://lists.torproject.org/pipermail/tbb-dev/2017-September/000610.html)Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22787Fontconfig warning: remove 'blank' configuration2022-07-12T22:23:22ZcypherpunksFontconfig warning: remove 'blank' configurationIn the log:
> Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf
Quickly skimming fontconfig's changelog one finds:
> commit 46b2c62faa64250eec3981ee816e91a9a3dee857
> Author: Ak...In the log:
> Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf
Quickly skimming fontconfig's changelog one finds:
> commit 46b2c62faa64250eec3981ee816e91a9a3dee857
> Author: Akira TAGOH <akira@tagoh.org>
> Date: Wed Jun 17 16:29:08 2015 +0900
>
> Add a warning for blank in fonts.conf
>
> and remove the unnecessary code for parsing blanks
>
> src/fcxml.c | 7 +++++++
> 1 file changed, 7 insertions(+)Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22137Provide the same scrollbar size across different platforms + versions (and su...2023-11-04T00:31:22ZGeorg KoppenProvide the same scrollbar size across different platforms + versions (and subpixel entropy)Scrollbar sizes are different on different platforms. But it seems that there are ways to split the Linux users into different buckets based on that: On a Debian Stretch system with XFCE I get 15px thickness on an Ubuntu 14.04 system wit...Scrollbar sizes are different on different platforms. But it seems that there are ways to split the Linux users into different buckets based on that: On a Debian Stretch system with XFCE I get 15px thickness on an Ubuntu 14.04 system with GNOME I get 13px thickness.
A test can be found on http://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-TOR-Browser.html.
One option mentioned in that blog post would be to provide 17px on all platforms.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41484Should generic monospace font be before script-specific ones?2024-03-06T08:59:46ZPier Angelo VendrameShould generic monospace font be before script-specific ones?In the long issue about fixing scripts, we set sans-serif script-specific fonts before the generic `monospace` fonts in `font.name-list.monospace.*`.
The reasoning behind this was that we didn't add script-specific `monospace` fonts any...In the long issue about fixing scripts, we set sans-serif script-specific fonts before the generic `monospace` fonts in `font.name-list.monospace.*`.
The reasoning behind this was that we didn't add script-specific `monospace` fonts anyway, so Firefox would fall back to Noto Sans in any case (and for consistency, we told it to jump to Noto Sans rather than Noto Serif).
This would guarantee a better consistency when the lang is set, but it will never display monospace characters, even when covered by a monospace font.
Should we change the priority, and use the generic `monospace` fonts (Cousine, Courier, Menlo, etc) before the script-specific Noto Sans?Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41464[win] Investigate TSF / TIP (IME)2022-11-29T12:34:56ZThorin[win] Investigate TSF / TIP (IME)From FF107+ [1774317](https://bugzilla.mozilla.org/show_bug.cgi?id=1774317) [TSF] Support `GUID_PROP_URL`
> Although I feel it has some concerns about privacy. However, TIP (IME) can access other private things.
Note: The prefs are
- `p...From FF107+ [1774317](https://bugzilla.mozilla.org/show_bug.cgi?id=1774317) [TSF] Support `GUID_PROP_URL`
> Although I feel it has some concerns about privacy. However, TIP (IME) can access other private things.
Note: The prefs are
- `pref("intl.tsf.expose_url.allowed", true)`; // maybe not goof for Privacy Browser
- `pref("intl.tsf.expose_url_in_private_browsing.allowed", false)`; // good for PB Mode and TB in future
Is this TSF, or just TIP or just TIP (IME) that has privacy concerns. Someone with some knowledge of these things should investigate.
Also an accessibility issue?
> TSF is used in various scenarios to enable intelligent services, such as autocorrection, text suggestions as you type, shapewriting etc. The URL GUID will be used by accessibility via TSF services in the OS. For example, accessibility experiences can be optimized for specific URLs, such as a screen reader reading "microsoft.com" or "YouTube at google.com".
labels please @ triage ownerSponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41347Variable font support can be used to fingerprint OS versions2023-01-05T15:25:52Zcypherpunks1Variable font support can be used to fingerprint OS versionsIn Tor Browser, the value of the `layout.css.font-variations.enabled` preference changes depending on the operating system version. For example, it is enabled on Windows 10 and disabled on Windows 7 and this can be detected with javascri...In Tor Browser, the value of the `layout.css.font-variations.enabled` preference changes depending on the operating system version. For example, it is enabled on Windows 10 and disabled on Windows 7 and this can be detected with javascript.
It can be tested here:
https://privacycheck.sec.lrz.de/active/fp_je/fp_js_echo.html
When the preference is enabled, the `font-optical-sizing` and `font-variation-settings` properties will appear under HTML Elements.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41092Enable tracking query parameters stripping2023-10-03T15:36:13ZArthur EdelsteinEnable tracking query parameters strippingURL query parameters (aka URL search parameters) are a major vector for cross-site tracking. They comprise what is perhaps the most significant category of cross-site tracking vector that remains unblocked in Tor Browser.
Fortunately, F...URL query parameters (aka URL search parameters) are a major vector for cross-site tracking. They comprise what is perhaps the most significant category of cross-site tracking vector that remains unblocked in Tor Browser.
Fortunately, Firefox [has announced](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/osQQROd2jKA) that they will be enabling tracking query parameter stripping for Strict mode and Private mode. (As of Firefox 103, this protection seems to be enabled in Strict Mode only in Release.) It would be great if Firefox's feature can be enabled in Tor Browser and expanded to cover more parameters that Firefox doesn't, including Google's gclid and dclid and Microsoft's msclkid. For a longer list of candidate parameters, see https://privacytests.org/Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41065navigator.storage "best effort" + "persistent" leak partitionSize/totalSpace ...2023-11-20T16:02:58ZThorinnavigator.storage "best effort" + "persistent" leak partitionSize/totalSpace entropyEdit: upstream [1781277](https://bugzilla.mozilla.org/show_bug.cgi?id=1781277)
AFAICT, in FF96 or lower, storage quota was always `2,147,483,648`. Note PB windows and normal windows are always the same. Also note, I'm not interested in ...Edit: upstream [1781277](https://bugzilla.mozilla.org/show_bug.cgi?id=1781277)
AFAICT, in FF96 or lower, storage quota was always `2,147,483,648`. Note PB windows and normal windows are always the same. Also note, I'm not interested in slight variations due to storage usage, we can cancel that noise out.
In FF97 (I'll see if I can find the bugzilla) it seems to have become dependent on disk space (and/or disk size), which adds some entropy. Here are my notes
```
// 2147483648 : FF57-96 Windows (and TB ESRs) / Android / Win 10 VM FF60-96
// FF97+ : note opusforlife, bashonly are user names who submitted data (so I can track it)
10737418240 : numerous windows + linux users with lots of disk size, Android Fabrizio 100gb spare from 128gb
5778733465 : Android10 opusforlife 12gb spare from 64gb (Mull)
5641604300 : Android Fabrizio 49gb spare from 64gb
5512729395 : Android9 Thorin 44gb spare from 64gb
5301081292 : Android bashonly 40gb spare from 64gb
5256596684 : Win 10 VM 33gb spare from 52gb
2934867968 : Debian XCFE 2glops 650gb spare from 1TB
1521166745 : Ubuntu VM Fabrizio with 15GB of storage
1177328025 : Android aleyvo 1.5gb spare from 16gb
// other: who cares if they match
// brave: 2147483648 (same in incognito and Tor window)
// opera: 310418104 normal
// opera: 521917312 private
// chrome: 1200238045593 normal
// chrome: 33076376370 normal android
// chrome: 485041940 incognito
// chrome: 204974075 incognito android
```
So TB102+ will reflect this - so far I have 3 results. You can test [here](https://arkenfox.github.io/TZP/tests/engine.html), just scroll down to the bottom, just above the `ERRORS` section, or alternatively, just run this in the browser console, and then expand the promise
```js
console.log(navigator.storage.estimate())
```
So what would be nice to know is how deep this rabbit hole goes... and to look at the code changes in FF97+, which will probably tell us the answer. Once we know how bad it is, we can propose RFP handle it upstream
@richard `Fingerprinting` label please .. also alone feel free to report their quota + OS + free disk size if applicable
---
EDIT
- FF97 [1735713](https://bugzilla.mozilla.org/show_bug.cgi?id=1735713) Revamp temporary storage limits
- FF97 [1593646](https://bugzilla.mozilla.org/show_bug.cgi?id=1593646) StorageManager.estimate is misleading when...
digging into it now: https://bugzilla.mozilla.org/show_bug.cgi?id=1735713#c0
> Our temporary storage limits are still based on free disk space which is now in a conflict with the storage spec. We should base our temporary storage limits on total dSponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40919Consider dropping protection against line-height introduced in #231042024-03-26T18:57:40ZPier Angelo VendrameConsider dropping protection against line-height introduced in #23104#23104 was about a way to discover the Tor Browser platform by checking the computed `line-height`.
However, with [Bug 1536871](https://bugzilla.mozilla.org/show_bug.cgi?id=1536871), Mozilla added an alternative protection, that makes `...#23104 was about a way to discover the Tor Browser platform by checking the computed `line-height`.
However, with [Bug 1536871](https://bugzilla.mozilla.org/show_bug.cgi?id=1536871), Mozilla added an alternative protection, that makes `getComputedStyle` return `normal`, instead of the real pixel value.
Therefore, we should consider that fix deprecated, and remove it from our patch set.
Here is the [test of the patch](/uploads/d24c5bec108eb4a88a7c661a9e08602b/test.html), quickly modified to display the value to the user.
Please notice its current result:
![Screenshot_from_2022-05-13_16-01-41](/uploads/c5053cb205227bc459c679cda5c573cf/Screenshot_from_2022-05-13_16-01-41.png)
which is coherent with Firefox and with Chromium-based browsers.Sponsor 131 - Phase 2 - Privacy Browserhttps://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/40081Letterboxing since 32220 affected by layout.css.devPixelsPerPx2022-12-08T17:41:30ZMoreQuarksLetterboxing since 32220 affected by layout.css.devPixelsPerPxThis submission includes 3 sections: (1) Summary of Issue, (2) Detailed Description of Issue, and (3) Desired Outcome.
---
(1) Summary of Issue —
When using Tor Browser on a MacBook Air 13-inch laptop computer, the default configura...This submission includes 3 sections: (1) Summary of Issue, (2) Detailed Description of Issue, and (3) Desired Outcome.
---
(1) Summary of Issue —
When using Tor Browser on a MacBook Air 13-inch laptop computer, the default configuration about:config > layout.css.devPixelsPerPx Value -1.0 (screenshot 1) renders too small the size of content in the Toolbar, the size of bookmarks folders and text in the Bookmarks Toolbar, and the size of content in the browser inner window. The small size leads to user eyestrain that is largely avoided when Tor Browser uses modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 (screenshot 2).
Modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 prevents user eyestrain when using Tor Browser on a MacBook Air 13-inch laptop, but, when Tor Browser 9.5.3 is using this configuration, screen resolution fails to conform to a multiple of w:50 x h:50, w:100 x h:50, w:100 x h:100, or w:100 x h:200. I wonder whether this issue might be related to some sort of letterboxing issue in Tor Browser 9.5.3 (and 9.5.1 and 9.5).
Modified configuration about:config > layout.css.devPixelsPerPx Value 3.0 (screenshot 3) ~~has none of the issues described in the preceding two configurations~~ screen resolution fails to conform to a multiple of w:50 x h:100 when manually adjusting the window size, ~~but~~ and this configuration is not user-friendly because the size of Toolbar content, Bookmarks Toolbar content, inner window content, and the exterior window itself are excessively oversized and too large.
---
(2) Detailed Description of Issue —
In Tor Browser 9.5.3, 9.5.1, 9.5, 9.0.10, 9.0.9, and 9.0.4, the screen resolution in each version was tested and 24 corresponding screenshots were created to help define and resolve this issue in 9.5.3.
Throughout this submission, references to Tor Browser 9.5.3 collectively refer to versions 9.5.3, 9.5.1 and 9.5, and references to Tor Browser 9.0.10 collectively refer to versions 9.0.10, 9.0.9 and 9.0.4.
Tor Browser versions 9.5.3 and 9.0.10 are using the following Customize settings (screenshots 4, 5) when running the screen tests:
• Toolbars > ✓ Bookmarks Toolbar
• Density > Compact
• Drag ★Bookmarks Toolbar Items into the toolbar
• Use the default settings for Title Bar, Drag Space, and Themes.
In Tor Browser 9.5.3 and 9.0.10, default configuration about:config > layout.css.devPixelsPerPx Value -1.0 renders too small for comfortable viewing the Toolbars content, bookmarks folders and text appearing in the Bookmarks Toolbar, and inner window content. (screenshot 6). This default configuration causes unacceptable user eyestrain when using Tor Browser on a MacBook Air 13-inch laptop computer.
In Tor Browser 9.5.3, modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 hits the sweet spot for making a slight but significantly beneficial enlargement in the size of the Toolbars content, bookmarks folders and text appearing in the Bookmarks Toolbar, and inner window content (screenshot 7). This modified configuration makes the viewing experience more comfortable and user-friendly by preventing user eyestrain when using Tor Browser on a MacBook Air 13-inch laptop computer.
However, when Tor Browser 9.5.3 is using modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 when it starts, the window opens at screen resolution w:998 x h:599 (screenshot 7) across browser sessions, letterboxing displays the window at w:798 x h:599 (screenshot 8) across browser sessions when manually adjusting the size of the window, and Enter Full Screen opens the window at w:1198 x h:599 (screenshot 9) across browser sessions.
In contrast, when Tor Browser 9.0.10 is using modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 when Tor Browser starts, the window opens at w:1000 x h:600 (screenshot 10) across browser sessions, letterboxing correctly displays the window at w:450 x h:450 (screenshot 11) across browser sessions when manually adjusting the size of the window, and Enter Full Screen correctly opens the window at w:1200 x h:600 (screenshot 12) across browser sessions.
In Tor Browser 9.5.3, setting modified configuration about:config > layout.css.devPixelsPerPx Value 3.0 (screenshot 13) and immediately quitting and restarting Tor Browser in that configuration opens the window at w:800 x h:500 (screenshot 14) across browser sessions, letterboxing displays the window at w:450 x h:450 (screenshot 15) across browser sessions when manually adjusting the size of the window, and Enter Full Screen opens the window at w:900 x h:500 (screenshot 16) across browser sessions.
However, in Tor Browser 9.5.3, modified configuration about:config > layout.css.devPixelsPerPx Value 3.0 is unsuitable because this configuration causes the content in the Toolbar and Bookmarks Toolbar to be excessively oversized and too large, and the size of content appearing in the inner window and the size of the exterior window itself are excessively oversized and too large (screenshot 17).
When Tor Browser 9.5.3 is using modified configuration about:config > layout.css.devPixelsPerPx Value 3.0 when Tor Browser starts, immediately changing the configuration from about:config > layout.css.devPixelsPerPx Value 3.0 to about:config > layout.css.devPixelsPerPx Value 2.4 (screenshot 18) without restarting Tor Browser instantaneously changes the screen resolution from size w:800 x h:500 (screenshot 19) to indicated test size w:1000 x h:600 (screenshot 20 ), letterboxing displays the window at indicated test size w:451 x h:500 (screenshot 21, 451x500) when manually adjusting the window size, and Enter Full Screen opens the window at indicated test size w:1200 x h:600 (screenshot 22).
However, during the browser session in the preceding paragraph, Tor Browser 9.5.3 renders the window at indicated test size w:1000 x h:600 only during that single browser session, and Enter Full Screen opens the window at indicated test size w:1200 x h:600 only during that single browser session because, after quitting and restarting Tor Browser 9.5.3, the window opens with configuration about:config > layout.css.devPixelsPerPx Value 2.4 and screen resolution w:998 x h:599 (screenshot 7), the window displays indicated test size w:449 x h:599 (screenshot 23) when manually adjusting the window size, and Enter Full Screen opens the window at indicated test size w:1199 x h:599 (screenshot 24).
The described issues are present in Tor Browser versions 9.5.3, 9.5.1, 9.5, but testing indicates they are not present in Tor Browser versions 9.0.10, 9.0.9, and 9.0.4.
Modified configuration about:config > layout.css.devPixelsPerPx Value 2.4 is compatible with Tor Browser 9.0.10, 9.0.9, and 9.0.4 and causes no letterboxing or screen resolution issues in those versions.
---
(3) Desired Outcome —
When Tor Browser is using Customize settings Toolbars>✓ Bookmarks Toolbar, Density>Compact, drag>★Bookmarks Toolbar Items into toolbar, and default settings>for Title Bar, Drag Space, and Themes, Tor Browser would render the following screen resolutions for each instance Tor Browser starts when it is using modified configuration about:config > layout.css.devPixelsPerPx Value 2.4:
• Screen resolution conforms to a multiple of w:50 x h:50, w:100 x h:100, or w:100 x h:200 across browser sessions.
• Screen resolution conforms to a multiple of w:50 x h:50, w:100 x h:50, w:100 x h:100, or w:100 x h:200 across browser sessions when manually adjusting the size of the window.
• Enter Full Screen opens the window at a multiple of w:100 x h:100 or w:100 x h:200 across browser sessions.
---
Platform: macOS Catalina Version 10.15.6, MacBook Air 13-inch laptop computer.
TorZillaPrint screen test: https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html
---
![screenshot_1](/uploads/787be645a7b08e7725bf59660e9e0b02/screenshot_1.png)
![screenshot_2](/uploads/f497e853c4da6f53d6922e9bb6025ee1/screenshot_2.png)
![screenshot_3](/uploads/7e87cc658f605bccd8f311d0b0398baf/screenshot_3.png)
![screenshot_4](/uploads/c548dab58e95aa17763b42d4ddedb429/screenshot_4.png)
![screenshot_5](/uploads/86148f19d1203436af59a4e52796b82e/screenshot_5.png)
![screenshot_6](/uploads/57343d3dc8c7e29793c1757c714fa023/screenshot_6.png)
![screenshot_7](/uploads/303d52aa4eebb2ad1f83bf5ce85787a2/screenshot_7.png)
![screenshot_8](/uploads/789141d24942ef4bb3fb3c0f6a0d997a/screenshot_8.png)
![screenshot_9](/uploads/1ed0fa9ba75755bcaa8d383bc541605b/screenshot_9.png)
![screenshot_10](/uploads/37d7c6465872d20ab86cde8d74291b77/screenshot_10.png)
![screenshot_11](/uploads/786c23ed34df62d76261affdc1b6219e/screenshot_11.png)
![screenshot_12](/uploads/f55c49d68520bb611554c2b1f58d7819/screenshot_12.png)
![screenshot_13](/uploads/e0ffb431d80a57938790e73e75eb096a/screenshot_13.png)
![screenshot_14](/uploads/2e3bb78f822af09feef3896c52a9a0e9/screenshot_14.png)
![screenshot_15](/uploads/8b07b56987869e0ea440182d51e561bf/screenshot_15.png)
![screenshot_16](/uploads/12f65a8e88134dce3b7aadecbcdd3f17/screenshot_16.png)
![screenshot_17](/uploads/9dcd73d578ace605a88b59318edf926d/screenshot_17.png)
![screenshot_18](/uploads/85742446f01c0b6ee234dfe072ebba30/screenshot_18.png)
![screenshot_19](/uploads/f4e346036f4d26539435da8f91ba7ab8/screenshot_19.png)
![screenshot_20](/uploads/c74522a9a0347548d2219a457969af07/screenshot_20.png)
![screenshot_21](/uploads/e352331b9c8443b3d6d404f284168265/screenshot_21.png)
![screenshot_22](/uploads/21befd985b2b9c2b37c897b3dca5e697/screenshot_22.png)
![screenshot_23](/uploads/fd0597ede644020f7e858e06127a4597/screenshot_23.png)
![screenshot_24](/uploads/6bf107fde4abac760506cdd6dcbfafcb/screenshot_24.png)Sponsor 131 - Phase 2 - Privacy Browserma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40057ensure that CSS4 system colors are not a fingerprinting vector2023-06-01T17:13:29ZMark Smithensure that CSS4 system colors are not a fingerprinting vectorFrom #33534: Firefox 76 added support for CSS4 system colors. It looks like these were not added to https://searchfox.org/mozilla-central/source/widget/nsXPLookAndFeel.cpp#534 (`GetStandinForNativeColor()`). We should test the behavior a...From #33534: Firefox 76 added support for CSS4 system colors. It looks like these were not added to https://searchfox.org/mozilla-central/source/widget/nsXPLookAndFeel.cpp#534 (`GetStandinForNativeColor()`). We should test the behavior and consider updating the system colors to Windows 10 and MacOS 10.10.x.
https://bugzilla.mozilla.org/show_bug.cgi?id=1590894 \
"Need to support CSS4 system colors"Sponsor 131 - Phase 2 - Privacy BrowserDan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33282Increase the max width of new windows2023-10-03T15:38:07ZThorinIncrease the max width of new windowsnew window sizes are only applied to non-android devices (AFAIK). Android will use LBing when ready.
new windows are calculated with a max width of 1000px (and then steps down in 200px increments). Note: height is similar (max 1000m ste...new window sizes are only applied to non-android devices (AFAIK). Android will use LBing when ready.
new windows are calculated with a max width of 1000px (and then steps down in 200px increments). Note: height is similar (max 1000m steps of 100)
Somewhat relevant, LBing has reduced the number of combos of `w`x`h`: but assuming there was no accidental window sizing, and ignoring anything from bugs (toolbar showing, dpi etc)... just focusing on new windows
desktop/laptop screens are likely to be widescreen (approx 16/9), and even the old 1.33/1 (e.g. 1024x768) is not square
Lets say 99% of heights used are `[600,700,800,900,1000]`. Increasing the max width to `1200` theoretically increases the number of entropy buckets by 5 (1 new x number of heights) and to `1400` by 10, etc. But in reality, it's **not going to affect actual entropy** (but there may be some edge cases): e.g.
- if you can do `1000`px high, you can almost certainly do `1200` wide (or you never could do 1000 wide anyway: e.g 1024x768)
- if you're limited to 600 high, you can't do 1200 anyway
Obviously there are a lot of desktop/laptop screen aspect ratios out there, and we don't have any hard data - but my point is:
**why are we square on desktops/laptops?** - a lot of webpages cause a horizontal scroll bar which is quite annoying (and you know just how upset users can get with visuals: see LB introduction) - so I'll just label this as a usability issue: not just the scrollbar, but wastage of available screen real estate / productivity.
Without some real hard data, we can only guess (but we can look at Firefox telemetry or real world screen stats). My instinct tells me 1200 max is "safe" (as its below both 4/3 and 16/9), and if 4/3 is an edge case, then 1400 or 1600 is also "safe"
I know 1000px seems the safer bet, but 1200px = more usability = more users/uptake .. and, it shouldn't affect actual real world entropy
Class, discuss!Sponsor 131 - Phase 2 - Privacy Browserma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32308Stop inner letterbox jiggling as border is dragged2023-05-04T05:43:28ZcypherpunksStop inner letterbox jiggling as border is draggedTBB 9.0
Linux 64
Cinnamon
The inner content area of the letterbox jiggles violently as the Tor Browser window border is dragged to resize. The effect is worse on horizontal (width) than vertical (height). Ideally, the content area wou...TBB 9.0
Linux 64
Cinnamon
The inner content area of the letterbox jiggles violently as the Tor Browser window border is dragged to resize. The effect is worse on horizontal (width) than vertical (height). Ideally, the content area would crisply snap as the border shrinks or grows.Sponsor 131 - Phase 2 - Privacy Browserrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31821reapply window.open() clamping2022-11-29T15:31:19ZThorinreapply window.open() clampingIn alpha we seem to have lost the 10px clamping for new windows (which are opened in a new tab: see legacy/trac#9881 )
- See https://bugzilla.mozilla.org/show_bug.cgi?id=1556016
- See https://ghacksuserjs.github.io/TorZillaPrint/TorZill...In alpha we seem to have lost the 10px clamping for new windows (which are opened in a new tab: see legacy/trac#9881 )
- See https://bugzilla.mozilla.org/show_bug.cgi?id=1556016
- See https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html - click the `new window` button
Pic to follow: example of a user resizing the browser for more real estate: which we want to encourage for uptake and for the letterboxing buckets to be less FP'able (I assume).
Would be good to upstream itSponsor 131 - Phase 2 - Privacy Browserhttps://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 Vendrame