New Release: Tor Browser 9.0

Update [7:30 UTC]: Clarified the amount of locales we support. It's 32 with Tor Browser 9.0.

Update [10:45 UTC]: Added a section about letterboxing.

Tor Browser 9.0 is now available from the Tor Browser download page and also from our distribution directory.

This release features important security updates to Firefox.

Tor Browser 9.0 is the first stable release based on Firefox 68 ESR and contains a number of updates to other components as well (including Tor to 0.4.1.6 and OpenSSL to 1.1.1d for desktop versions and Tor to 0.4.1.5 for Android).

In addition to all the needed patch rebasing and toolchain updates, we made big improvements to make Tor Browser work better for you.

We want everyone in the world to be able to enjoy the privacy and freedom online Tor provides, and that's why over the past couple years, we've been working hard to boost our UX and localization efforts, with the biggest gains first visible in Tor Browser 8.0.

In Tor Browser 9.0, we continue to build upon those efforts with sleeker integration and additional localization support.

Goodbye, Onion Button

We want your experience using Tor to be fully integrated within the browser so how you use Tor is more intuitive. That's why now, rather than using the onion button that was in the toolbar, you can see your path through the Tor network and request a New Circuit through the Tor network in [i] on the URL bar.

Tor Browser - circuit display - dark theme

 

Hello, New Identity Button

Tor Browser - Toolbar - New Identity Button

Instead of going into the onion button to request a New Identity, we've made this important feature easier to access by giving it its own button in the toolbar.

Tor Browser - New Identity

You can also request a New Identity, and a New Circuit, from within the [=] menu on the toolbar.

Torbutton and Tor Launcher Integration

Now that both extensions are tightly integrated into Tor Browser, they'll no longer be found on the about:addons page.

Tor Browser - about preferences

We redesigned the bridge and proxy configuration dialogs and include them directly into the browser's preference settings as well.

Rather than being a submenu behind the onion button, Tor Network Settings, including the ability to fetch bridges to bypass censorship where Tor is blocked, are easier to access on about:preferences#tor.

Letterboxing

Tor Browser, in its default mode, is starting with a content window rounded to a multiple of 200px x 100px to prevent fingerprinting the screen dimensions. The strategy here is to put all users in a couple of buckets to make it harder to single them out. That worked until users started to resize their windows (e.g. by maximizing them or going into fullscreen mode). Tor Browser 9 ships with a fingerprinting defense for those scenarios as well, which is called Letterboxing, a technique developed by Mozilla and presented earlier this year. It works by adding white margins to a browser window so that the window is as close as possible to the desired size while users are still in a couple of screen size buckets that prevent singling them out with the help of screen dimensions.

Better Localization Support

If we want all people around the world to be able to use our software, then we need to make sure it's speaking their language. Since 8.0, Tor Browser has been available in 25 languages, and we added 5 locales more in Tor Browser 8.5. Today, we add support for two additional languages: Macedonian (mk) and Romanian (ro), bringing the number of supported languages to 32.

We also fixed bugs in our previously shipped localized bundles (such as ar and ko).

Many thanks to everyone who helped with these, in particular to our translators.

Known Issue

As usual when preparing Tor Browser releases, we verified that the build is bit-for-bit reproducible. While we managed to get two matching builds, we found that in some occasions the builds differ (we found this happening on the Linux i686 and macOS bundles). We are still investigating the cause of this issue to fix it.

Give Feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know. Thanks to all of the teams across Tor, and the many volunteers, who contributed to this release.

Changelog

The full changelog since Tor Browser 8.5.6 is:

  • All Platforms
    • Update Firefox to 68.2.0esr
    • Bug 31740: Remove some unnecessary RemoteSettings instances
    • Bug 13543: Spoof smooth and powerEfficient for Media Capabilities
    • Bug 28196: about:preferences is not properly translated anymore
    • Bug 19417: Disable asmjs on safer and safest security levels
    • Bug 30463: Explicitly disable MOZ_TELEMETRY_REPORTING
    • Bug 31935: Disable profile downgrade protection
    • Bug 16285: Disable DRM/EME on Android and drop Adobe CDM
    • Bug 31602: Remove Pocket indicators in UI and disable it
    • Bug 31914: Fix eslint linter error
    • Bug 30429: Rebase patches for Firefox 68 ESR
    • Bug 31144: Review network code changes for Firefox 68 ESR
    • Bug 10760: Integrate Torbutton into Tor Browser directly
    • Bug 25856: Remove XUL overlays from Torbutton
    • Bug 31322: Fix about:tor assertion failure debug builds
    • Bug 29430: Add support for meek_lite bridges to bridgeParser
    • Bug 28561: Migrate "About Tor Browser" dialog to tor-browser
    • Bug 30683: Prevent detection of locale via some *.properties
    • Bug 31298: Backport patch for #24056
    • Bug 9336: Odd wyswig schemes without isolation for browserspy.dk
    • Bug 27601: Browser notifications are not working anymore
    • Bug 30845: Make sure internal extensions are enabled
    • Bug 28896: Enable extensions in private browsing by default
    • Bug 31563: Reload search extensions if extensions.enabledScopes has changed
    • Bug 31396: Fix communication with NoScript for security settings
    • Bug 31142: Fix crash of tab and messing with about:newtab
    • Bug 29049: Backport JS Poison Patch
    • Bug 25214: Canvas data extraction on local pdf file should be allowed
    • Bug 30657: Locale is leaked via title of link tag on non-html page
    • Bug 31015: Disabling SVG hides UI icons in extensions
    • Bug 30681: Set security.enterprise_roots.enabled to false
    • Bug 30538: Unable to comment on The Independent Newspaper
    • Bug 31209: View PDF in Tor Browser is fuzzy
    • Translations update
  • Windows + OS X + Linux
    • Update Tor to 0.4.1.6
    • Update OpenSSL to 1.1.1d
      • Bug 31844: OpenSSL 1.1.1d fails to compile for some platforms/architectures
    • Update Tor Launcher to 0.2.20.1
      • Bug 28044: Integrate Tor Launcher into tor-browser
      • Bug 32154: Custom bridge field only allows one line of input
      • Bug 31286: New strings for about:preferences#tor
      • Bug 31303: Do not launch tor in browser toolbox
      • Bug 32112: Fix bad & escaping in translations
      • Bug 31491: Clean up the old meek http helper browser profiles
      • Bug 29197: Remove use of overlays
      • Bug 31300: Modify Tor Launcher so it is compatible with ESR68
      • Bug 31487: Modify moat client code so it is compatible with ESR68
      • Bug 31488: Moat: support a comma-separated list of transports
      • Bug 30468: Add mk locale
      • Bug 30469: Add ro locale
      • Bug 30319: Remove FTE bits
      • Translations update
    • Bug 32092: Fix Tor Browser Support link in preferences
    • Bug 32111: Fixed issue parsing user-provided bridge strings
    • Bug 31749: Fix security level panel spawning events
    • Bug 31920: Fix Security Level panel when its toolbar button moves to overflow
    • Bug 31748+31961: Fix 'Learn More' links in Security Level preferences and panel
    • Bug 28044: Integrate Tor Launcher into tor-browser
    • Bug 31059: Enable Letterboxing
    • Bug 30468: Add mk locale
    • Bug 30469: Add ro locale
    • Bug 29430: Use obfs4proxy's meek_lite with utls instead of meek
    • Bug 31251: Security Level button UI polish
    • Bug 31344: Register SecurityLevelPreference's 'unload' callback
    • Bug 31286: Provide network settings on about:preferences#tor
    • Bug 31886: Fix ko bundle bustage
    • Bug 31768: Update onboarding for Tor Browser 9
    • Bug 27511: Add new identity button to toolbar
    • Bug 31778: Support dark-theme for the Circuit Display UI
    • Bug 31910: Replace meek_lite with meek in circuit display
    • Bug 30504: Deal with New Identity related browser console errors
    • Bug 31929: Don't escape DTD entity in ar
    • Bug 31747: Some onboarding UI is always shown in English
    • Bug 32041: Replace = with real hamburguer icon ≡
    • Bug 30304: Browser locale can be obtained via DTD strings
    • Bug 31065: Set network.proxy.allow_hijacking_localhost to true
    • Bug 24653: Merge securityLevel.properties into torbutton.dtd
    • Bug 31164: Set up default bridge at Karlstad University
    • Bug 15563: Disable ServiceWorkers on all platforms
    • Bug 31598: Disable warning on window resize if letterboxing is enabled
    • Bug 31562: Fix circuit display for error pages
    • Bug 31575: Firefox is phoning home during start-up
    • Bug 31491: Clean up the old meek http helper browser profiles
    • Bug 26345: Hide tracking protection UI
    • Bug 31601: Disable recommended extensions again
    • Bug 30662: Don't show Firefox Home when opening new tabs
    • Bug 31457: Disable per-installation profiles
    • Bug 28822: Re-implement desktop onboarding for ESR 68
  • Windows
    • Bug 31942: Re-enable signature check for language packs
    • Bug 29013: Enable stack protection for Firefox on Windows
    • Bug 30800: ftp:// on Windows can be used to leak the system time zone
    • Bug 31547: Back out patch for Mozilla's bug 1574980
    • Bug 31141: Fix typo in font.system.whitelist
    • Bug 30319: Remove FTE bits
  • OS X
    • Bug 30126: Make Tor Browser compatible with macOS 10.15
    • Bug 31607: App menu items stop working on macOS
    • Bug 31955: On macOS avoid throwing inside nonBrowserWindowStartup()
    • Bug 29818: Adapt #13379 patch for 68esr
    • Bug 31464: Meek and moat are broken on macOS 10.9 with Go 1.12
  • Linux
    • Bug 31942: Re-enable signature check for language packs
    • Bug 31646: Update abicheck to require newer libstdc++.so.6
    • Bug 31968: Don't fail if /proc/cpuinfo is not readable
    • Bug 24755: Stop using a heredoc in start-tor-browser
    • Bug 31550: Put curly quotes inside single quotes
    • Bug 31394: Replace "-1" with "−1" in start-tor-browser.desktop
    • Bug 30319: Remove FTE bits
  • Android
    • Update Tor to 0.4.1.5
    • Bug 31010: Rebase mobile patches for Fennec 68
    • Bug 31010: Don't use addTrustedTab() on mobile
    • Bug 30607: Support Tor Browser running on Android Q
    • Bug 31192: Support x86_64 target on Android
    • Bug 30380: Cancel dormant by startup
    • Bug 30943: Show version number on mobile
    • Bug 31720: Enable website suggestions in address bar
    • Bug 31822: Security slider is not really visible on Android anymore
    • Bug 24920: Only create Private tabs in permanent Private Browsing Mode
    • Bug 31730: Revert aarch64-workaround against JIT-related crashes
    • Bug 32097: Fix conflicts in mobile onboarding while rebasing to 68.2.0esr
  • Build System
    • All Platforms
      • Bug 30585: Provide standalone clang 8 project across all platforms
      • Bug 30376: Use Rust 1.34 for Tor Browser 9
      • Bug 30490: Add cbindgen project for building Firefox 68 ESR/Fennec 68
      • Bug 30701: Add nodejs project for building Firefox 68 ESR/Fennec 68
        • Bug 31621: Fix node bug that makes large writes to stdout fail
      • Bug 30734: Add nasm project for building Firefox 68 ESR/Fennec 68
      • Bug 31293: Make sure the lo interface inside the containers is up
      • Bug 27493: Clean up mozconfig options
      • Bug 31308: Sync mozconfig files used in tor-browser over to tor-browser-build for esr68
    • Windows
      • Bug 29307: Use Stretch for cross-compiling for Windows
      • Bug 29731: Remove faketime for Windows builds
      • Bug 30322: Windows toolchain update for Firefox 68 ESR
        • Bug 28716: Create mingw-w64-clang toolchain
        • Bug 28238: Adapt firefox and fxc2 projects for Windows builds
        • Bug 28716: Optionally omit timestamp in PE header
        • Bug 31567: NS_tsnprintf() does not handle %s correctly on Windows
        • Bug 31458: Revert patch for #27503 and bump mingw-w64 revision used
      • Bug 9898: Provide clean fix for strcmpi issue in NSPR
      • Bug 29013: Enable stack protection support for Firefox on Windows
      • Bug 30384: Use 64bit containers to build 32bit Windows Tor Browser
      • Bug 31538: Windows bundles based on ESR 68 are not built reproducibly
      • Bug 31584: Clean up mingw-w64 project
      • Bug 31596: Bump mingw-w64 version to pick up fix for #31567
      • Bug 29187: Bump NSIS version to 3.04
      • Bug 31732: Windows nightly builds are busted due to mingw-w64 commit bump
      • Bug 29319: Remove FTE support for Windows
    • OS X
      • Bug 30323: MacOS toolchain update for Firefox 68 ESR
      • Bug 31467: Switch to clang for cctools project
      • Bug 31465: Adapt tor-browser-build projects for macOS notarization
    • Linux
      • Bug 31448: gold and lld break linking 32bit Linux bundles
      • Bug 31618: Linux32 builds of Tor Browser 9.0a6 are not matching
      • Bug 31450: Still use GCC for our ASan builds
      • Bug 30321: Linux toolchain update for Firefox ESR 68
        • Bug 30736: Install yasm from wheezy-backports
        • Bug 31447: Don't install Python just for Mach
      • Bug 30448: Strip Browser/gtk2/libmozgtk.so
    • Android
      • Bug 30324: Android toolchain update for Fennec 68
        • Bug 31173: Update android-toolchain project to match Firefox
        • Bug 31389: Update Android Firefox to build with Clang
        • Bug 31388: Update Rust project for Android
        • Bug 30665: Get Firefox 68 ESR working with latest android toolchain
        • Bug 30460: Update TOPL project to use Firefox 68 toolchain
        • Bug 30461: Update tor-android-service project to use Firefox 68 toolchain
      • Bug 28753: Use Gradle with --offline when building the browser part
      • Bug 31564: Make Android bundles based on ESR 68 reproducible
      • Bug 31981: Remove require-api.patch
      • Bug 31979: TOPL: Sort dependency list
      • Bug 30665: Remove unnecessary build patches for Firefox

It does reduce your anonymity, but not as much as before. The size is rounded to multiples of 100 so you are more likely to have the same size as someone else who's window also got rounded exactly to that size.

However the specific value combination still tells more about you then default size.

Anonymous

October 25, 2019

Permalink

re: letterboxing

Have not seen this suggested so far. I rarely maximize the screen except for video content now and then so .. what about making the letterbox come on only when the screen is maximized - just as the previous warning came on only when screen was maximized. That would be a good thing then - could still maximize when wanted and be protected - the rest of the time normal...

What about accidental maximizations or fullscreens? This is a source of anguish for those that care about anonymity and never change their window size. And what about reducing the uniformity for the rest?

Disabling letterboxing just for some specific deanonymizing use case so that we all stand out more is a bad idea.

I agree, but I do not think Tor Project or Mozilla are going to abandon letterboxing anytime soon, precisely because of the danger to ordinary people in "private browsing" mode which you cited.

Anonymous

October 25, 2019

Permalink

network.cookie.cookieBehavior... Really? No way this can't be serious as a common procedure. Cookies, as other tools, are used to gather information from users; and this information-data is sold literally for millions of dollars. When Tor decides to enforce users to accept (default option) and ignore the cookies, then all the trust founded in Tor privacy quickly starts to crumble till total collapse. By the way, don't expect also that most users will came to this place to warn or complain about. In fact mostly will not; instead they will just move on and forever away.

Not sure what you mean. The default option in Tor Browser (contrary to Firefox) is *not* to accept all cookies. We block any third-party cookie by default exactly to make the tracking by cookies across different domain impossible.

The problem with letterboxing is that it's always white, even when I'm using dark mode with the "Dark Mode" extension. Which I wouldn't have to use if tor-browser didn't ignore color setting I have set under Language and Appearance.

See: https://trac.torproject.org/projects/tor/ticket/32220. We hope to have the white borders fixed in 9.0.1.

my virus total 360 blocks install of this saying "changes dll" is this normal??? i run it through virustotal.com and it comes up clean

It seems your virus total 360 tool reports a false positive. I'd suggest getting rid of it. If you really need some antivirus/firewall tool use the built-in Windows capabilities.

@ Anonymous, yes in about:config.

example I want all devtools prefs to false because I don't need it.

Or telemetry and so on.

I set in mozilla.cfg all devtools to false and locked them. Before update to version 9, no problems, works.
With version 9, many devtools prefs are ignored and I have moved them to user.js. That works.

Or this:

user_pref("devtools.onboarding.telemetry.logged", true);

I tested it and set in mozilla.cfg:
lockPref("devtools.onboarding.telemetry.logged", false);

Restarted TBB, no effect, was set to true again.

I put it in user.js
user_pref("devtools.onboarding.telemetry.logged", false);

Restarted TBB, no effect, was set to true again.

After that i set false in about:config to "devtools.onboarding.telemetry.logged"

No effect after restart of TBB with version 9.

I would be better I have 100% control over that and
change what ever I want.

Any idea to change it and prevent TBB to set it on true after restart TBB?

I can confirm that Tor Browser 9.0 is resetting some preference values, whether set via about:config or user.js.

I am using a separate bundle for the few cases that I need clearnet. In the past I disabled proxying and Tor launcher addon (and a couple other things like circuit display, update checks, tor check, etc. but this was not strictly necessary) mostly via user.js. So for a fresh bundle I simply placed user.js in the appropriate directory and changed a few other things within the browser itself. I did this once and the settings persisted through each future run.

With TB 9.0 I have to go to about:config and manually change the values each time I run this bundle because the settings are reset on each run. It is not the case that user.js is simply ignored but that some of the values are reset by some later code on startup.

Which settings do you have to reset every time?

These are the ones that get reset back to defaults:

  1. <br />
  2. user_pref("network.proxy.socks_remote_dns", false);<br />
  3. user_pref("network.proxy.type", 0);<br />

All other settings that I also modify via user.js don't get reset back to defaults.

Maybe it's related to Tor preferences not being accessible i.e. if I go to preferences and click on the Tor icon nothing appears or happens. For me this is not surprising at all since I also disable torlauncher.prompt_at_startup and torlauncher.start_tor, but maybe it confuses some piece of code into resetting those values above.

Different versions of the Tor browser have the same fingerprint on the same device. https://panopticlick.eff.org/

That is good as along as they have the same fingerprint on other devices as well. The problem is only if some fingerprint is specific for some device. If so, can you check which part of the reported fingerprint is specific for your device?

Also try using higher security levels as much as possible. "Safer" level is perfectly usable almost everywhere.

Hi @ all!

Is it possible to disable the torlauncher.torrc_fixup?

I want use my own torrc file and the torrc fixup sometimes breaks my torrc file and replaces it with original torrc.

I am not sure what your problem is. Could you describe what you want to do? Why is it not enough to edit the torrc file (or create it if it's not there)? torrc-defaults gets indeed overwritten as the comment in it says.

So now there are loads of users whose manually disabled letterbox setting will be comfortably forgotten and roll over through every update from now on. By not educating users about a new persistently visually-invasive feature, I think Tor Project fucked up the rollout of it.

How would we have done a better rollout?

I still can't download images from tor android. Do you fix that problem in future updates?

Hey so now that onion button is gone, what do I do to restart the connection - after I have (for reasons) manually killed torr.exe - without closing the browser and losing all the tabs like the new identity button?

How would you have done that *with* the onion button?

Well previously I could get to the Tor Launcher window through the onion button. Pressing reconnect would restart torr.exe
After the update I couldnt figure out how to bring it up anymore (yes I'm a newb, but still an attempt was made).

The only way to restart it now is through the automatic popup prompt like so:
https://i.imgur.com/vZFTzlN.png

Are there any other ways?

Me dice que faltan archivos .dll y no se puede ejecutar tor.

It seems you are missing some updates on your Windows system because one of those updates did get you those missing .dlls. I'd suggest trying to fix your update situation on your computer, install all (the security) updates because otherwise Tor Browser might not give you the security and privacy guarantees it promises you.

Let's continue building great anti-censorship tools!

The option to not check for updates has been removed in the UI. What is the about:config option to disable automatic checking for updates? I like to update manually.

It's a serious mistake to remove settings for users to (easily) control cookies. The "some sites require cookies to..." excuse is fairly lame.
If I go to a site that requires cookies - to work at all, then *I'll* decide to allow cookies, not have it decided for me.
Many sites say that, but don't really break if cookies aren't allowed (or parts I don't care about may break).

We did not remove the settings for having per-site decisions about cookie acceptance. That's still on your preferences section. What he hid was the Tracking Protection UI which includes general, global cookie settings (like general allowance, only first-party cookies etc.). You can do that change in your about:config now by adjusting network.cookie.cookieBehavior.

compliments for the android version

i cant run tor browser after update because of the problem with the file:api-ms... can i download previous version?

It seems you are missing some updates on your Windows system because one of those updates did get you those missing .dlls. I'd suggest trying to fix your update situation on your computer, install all (the security) updates and then use Tor Browser 9 as older versions are having security holes in them, too.

lock button has gone from gray back to green again. did you guys do that?

Surely this OT good news item is worthy of celebration in a new Tor Blog post: the BBC has launched an onion mirror:

bbcnewsv2vjtpsuy.onion

See also:

theregister.co.uk
Tor blimey, Auntie! BBC launches dedicated dark web mirror site
Censor-dodging news for those sat in ban-happy countries
Kat Hall
24 Oct 2019

Kind of funny to think about advanced browser security when you have (had) things like this in mozilla:
#CVE-2019-15903: Heap overflow in expat library in XML_GetCurrentLineNumber
https://www.mozilla.org/en-US/security/advisories/mfsa2019-34/

@ gk,

I tweaked my torrc file. It's working great. After some re-starts of TBB, it's re-created the torrc file and feigned it.

I want to stop this.
So I ask if it is possible to disable "torrc-fixup"?
Or set torrc path manual in about:config?

I am not convinced that the "torrc-fixup" is responsible for that. Could you give us some steps to reproduce your problem? In particular what does "it's re-created the torrc file and feigned it" mean?

Letterboxing dimensions should be based on common desktop resolutions and window sizes in a maximized state, not arbitrary fixed increments. Every Windows user with a classic theme applied and a common resolution will have the same browser window size when maximized, letterboxing or not, so there's no reason to meddle with it. It should only be there for EDGE cases to protect people with unusual setups.

Letterboxing in its current state will motivate users to turn it off to recover screen real estate and further split anonymity pools, making it counter-productive.

There's already a proposal to spoof screen size with a few common resolutions: https://bugzilla.mozilla.org/show_bug.cgi?id=1591337

As for window size: if I understand you correctly you do not want to disable letterboxing in maximized state. Instead you want to use a different set of window sizes that the inner window "snaps" to. Currently this set is multiples of 100 and your idea is instead to use the sizes of maximized vanilla Firefox windows on a standard Windows system at common resolutions (so taking into account panels, window borders, toolbars, scrollbars, etc.). Meaning that, for example, a user running GNU/Linux with a non-maximized window will have letterboxing applied in a such a way that the size would equal a maximized vanilla Firefox window on a common Windows system with a common resolution.

That's an interesting idea. But it would work only as long as the resolution pool for the letterboxing to be based on is sufficiently large, for example at least third of the size of multiples-of-100 set. Otherwise you'd have windows with most of their screen estate wasted for letterboxing. It would also not work at smaller window sizes, unless you start pretending to be a smartphone or a small tablet (could use both landscape and portrait mode depending on window ratio).

I'm not proposing the fixed increments be totally done away with, but where we can identify majority viewport sizes, they should substitute for (one of) the neighboring multiples of 100. Since TB makes no attempt to conceal OS family, these hard-coded values can be OS family specific.

Let me try to explain with an example. Windows 10, 1920x1080 screen resolution, default theme, maximized. Firefox has an available viewport of 1920x932*. We would therefore replace 1900x900 with 1920x932, which would make the letterboxing feature completely invisible to those users when in a maximized state and gain them an extra 640 pixels, with no loss to privacy.

The percentage of such users who might otherwise be given a 1900x900 window size could be very high indeed. If they are persuaded not to turn off letterboxing, we would actually improve their (and everyone else in that resolution bin's) privacy.

Desktop environments on GNU/Linux are probably too heterogeneous for this to be worthwhile. Maybe something could be based on Tails.

BTW, horizontal and vertical scroll bar size can still be measured, even with letterboxing turned on. I'm not sure this can be fixed.

*Not real numbers

> BTW, horizontal and vertical scroll bar size can still be measured

That's a different issue and not related to screen/window directly. It shouldn't be hard to add some CSS mods to the firefox core to make all OS's use a static width. Want to help out -> https://trac.torproject.org/projects/tor/ticket/22137 ?

> Since TB makes no attempt to conceal OS family...

It is always planned, where possible, to obfuscate the OS. Let's not give away easy free entropy. Hopefully the issue with HTTP header UA vs navigator objects can get back to two OSes only when the blocker bug is done.

> these hard-coded values can be OS family specific

That would add complexity/upkeep and isn't a universal solution

> Windows 10, 1920x1080 screen resolution, default theme, maximized. Firefox has an available viewport of 1920x932 (made up numbers)

There is **no** such common inner window size: there are too many variables with the OS (DPI, taskbar heights-widths affect available screen) and Firefox chrome itself (insert list of 20 things here) that we can't control

Because screen metrics are tried to the inner window
- without letterboxing there are literally thousands of possible combinations of width/height, because w/h can increment by 1 pixel
- with letterboxing there are still lots: example on my 2560x1440 screen: staying over 600px width and height: I can get 10 different width steps and 8 different height steps = 80 combos
- zoom being tied to inner window, also affects the screen metrics: screen was never designed to have this happen to it

The problem is one of our own making, by tying screen to chrome. The real solution is to treat screen vs chrome as different threat models, and treat them accordingly: especially as screen is all that FPing scripts in the wild go for, because they crave stability. Letterboxing would still protect chrome metrics

Desktop environments on GNU/Linux are probably too heterogeneous for this to be worthwhile. Maybe something could be based on Tails.

But why not base letterboxing in all other releases on Windows as well? The User-Agent HTTP header is set to Windows in all releases after all.

I think there is much bigger potential here than just satisfying users who maximize their windows. Instead make all users at all window sizes on all OSs pretend to run a maximized vanilla Firefox on a standard Windows desktop at some standard resolution. So to completely replace the current multiples-of-100 set with something that is very common outside of TBB userbase.

Most people use Windows, some of them use Firefox, most of them maximize their browsers, and almost all of them use standard resolutions. So why not use their really existing inner window sizes for letterboxing in TBB?

Ehm, new tor browser behavior in tor log:

10/xx/19, xx:xx:xx.xxx [WARN] Error replacing "X:xxxxxx\TorBrowser\Data\Tor\torrc": Permission denied

On which Windows version does this happen? Maybe that's https://trac.torproject.org/projects/tor/ticket/30976?

"[...]X:xxxxxx\TorBrowser\Data\Tor\torrc": Permission denied"

On MSWin7, the last privacycompatibe MSWindows-version, with blocked
write in file attribute(file->right-click).

I wonder what is causing this file to be read-only? Is that the only file being in read-only mode in Tor Browser? Or on this drive?

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

4 + 16 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.