New Release: Tor Browser 9.5

by antonela | June 1, 2020

Update [06/03 15:40 UTC]: Added developers docs for enabling onion-location and client authentication.

Tor Browser 9.5 is now available from the Tor Browser download page and also from our distribution directory. The Android version is also available from Google Play and should be available from F-Droid within the next day.

This release includes important security updates to Firefox.

This new Tor Browser release is focused on helping users understand onion services.

Tor's onion routing remains the best way to achieve end-to-end anonymous communication on the Internet. With onion services (.onion addresses), website administrators can provide their users with anonymous connections that are metadata-free or that hide metadata from any third party. Onion services are also one of the few censorship circumvention technologies that allow users to route around censorship while simultaneously protecting their privacy and identity.

For the first time, Tor Browser users on desktop will be able to opt-in for using onion sites automatically whenever the website makes them available. For years, some websites have invisibly used onion services with alternative services (alt-svc), and this continues to be an excellent choice. Now, there is also an opt-in mechanism available for websites that want their users to know about their onion service that invites them to upgrade their connection via the .onion address.

What is new?

Onion Location

Website publishers now can advertise their onion service to Tor users by adding an HTTP header. When visiting a website that has both an .onion address and Onion Location enabled via Tor Browser, users will be prompted about the onion service version of the site and will be asked to opt-in to upgrade to the onion service on their first use.

If you are a developer, learn how to enable onion-location in your onion service.

Onion Location Propublica

 

Onion Authentication

Onion services administrators who want to add an extra layer of security to their website can now set a pair of keys for access control and authentication. Tor Browser users can save keys and manage them via about:preferences#privacy in the Onion Services Authentication section.

If you are a developer, learn how to secure your onion service using client auth.

Onion Authentication

Improved URL Bar Security Indicators

Browsers traditionally rendered sites delivered via a secure transport protocol with a green lock icon. But in mid-2019, the formerly green lock icon became gray, intending to de-emphasize the default (safe) connection state and, instead, putting more emphasis on broken or insecure connections. Major browsers as Mozilla Firefox and Google Chrome understood that it is a benefit for the entire user base if they deploy familiar experiences for both users. We are following Firefox on this decision, and we have updated Tor Browser security indicators to make it easier for users to understand when they are visiting a non-secure website.

Tor Browser 9.5 URL Bar Update

Error Pages for Onion Services

Sometimes users have a hard time reaching onion sites. In previous versions of Tor Browser, when there was an error connecting to an onion service, users received a standard Firefox error message, with no information about why they were unable to connect to the onion site.

In this release, we have improved the way Tor Browser communicates with users about service-, client-, and network-side errors that might happen when they are trying to visit an onion service. Tor Browser now displays a simplified diagram of the connection and shows where the error occurred. We want these messages to be clear and informative without being overwhelming.

Error Page for Onion Pages

Onion Names

Because of cryptographic protections, onion service URLs are not easy for humans to remember (ie, https://torproject.org vs. http://expyuzz4wqqyqhjn.onion/). This makes it hard for users to discover or return to an onion site. We found that organically, developers have approached this problem in different ways, mostly with solutions tailored for their service. Given that there is no solution that works perfectly for all our user groups, we also approached this problem from a broad angle. For this release, we partnered with Freedom of the Press Foundation (FPF) and the Electronic Frontier Foundation's HTTPS Everywhere to develop the first proof-of-concept human-memorable names for SecureDrop onion services addresses:

Freedom of the Press Foundation has reached out to a small number of additional media organizations for participation, and Tor and FPF will jointly consider next steps based on feedback on this initial proof-of-concept.

Onion Names

 

Known Issues

Tor Browser 9.5 comes with a number of known issues.

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.

Full Changelog

The full changelog since Tor Browser 9.0.10 is:

  • All Platforms
    • Update Firefox to 68.9.0esr
    • Update HTTPS-Everywhere to 2020.5.20
    • Update NoScript to 11.0.26
    • Update Tor to 0.4.3.5
    • Translations update
    • Bug 21549: Disable wasm for now until it is properly audited
    • Bug 27268: Preferences clean-up in Torbutton code
    • Bug 28745: Remove torbutton.js unused code
    • Bug 28746: Remove torbutton isolation and fp prefs sync
    • Bug 30237: Control port module improvements for v3 client authentication
    • Bug 30786: Add th locale
    • Bug 30787: Add lt locale
    • Bug 30788: Add ms locale
    • Bug 30851: Move default preferences to 000-tor-browser.js
    • Bug 30888: move torbutton_util.js to modules/utils.js
    • Bug 31134: Govern graphite again by security settings
    • Bug 31395: Remove inline script in aboutTor.xhtml
    • Bug 31499: Update libevent to 2.1.11-stable
      • Bug 33877: Disable Samples and Regression tests For Libevent Build
    • Bug 31573: Catch SessionStore.jsm exception
    • Bug 32318: Backport Mozilla's fix for bug 1534339
    • Bug 32414: Make Services.search.addEngine obey FPI
    • Bug 32493: Disable MOZ_SERVICES_HEALTHREPORT
    • Bug 32618: Backport fixes from Mozilla bugs 1467970 and 1590526
    • Bug 33342: Avoid disconnect search addon error after removal
    • Bug 33726: Fix patch for #23247: Communicating security expectations for .onion
    • Bug 34157: Backport fix for Mozilla Bug 1511941
  • Windows + OS X + Linux
    • Update Tor Launcher to 0.2.21.8
      • Translations update
      • Bug 19757: Support on-disk storage of v3 client auth keys
      • Bug 30237: Add v3 onion services client authentication prompt
      • Bug 30786: Add th locale
      • Bug 30787: Add lt locale
      • Bug 30788: Add ms locale
      • Bug 33514: non-en-US Tor Browser 9.5a6 won't start up
    • Bug 19251: Show improved error pages for onion service errors
    • Bug 19757: Support on-disk storage of v3 client auth keys
    • Bug 21952: Implement Onion-Location
    • Bug 27604: Fix broken Tor Browser after moving it to a different directory
    • Bug 28005: Implement .onion alias urlbar rewrites
    • Bug 30237: Improve TBB UI of hidden service client authorization
    • Bug 32076: Upgrade to goptlib v1.1.0
    • Bug 32220: Improve the letterboxing experience
    • Bug 32418: Allow updates to be disabled via an enterprise policy.
    • Bug 32470: Backport fix for bug 1590538
    • Bug 32645: Update URL bar onion indicators
    • Bug 32658: Create a new MAR signing key
    • Bug 32674: Point the about:tor "Get involved" link to the community portal
    • Bug 32767: Remove Disconnect search
    • Bug 33698: Update "About Tor Browser" links in Tor Browser
    • Bug 33707: Swap out onion icon in circuit display with new one
    • Bug 34032: Use Securedrop's Official https-everywhere ruleset
    • Bug 34196: Update site info URL with the onion name
    • Bug 34321: Add Learn More onboarding item
  • Windows
    • Bug 22919: Improve the random number generator for the boundaries in multipart/form-data
    • Bug 29614: Use SHA-256 algorithm for Windows timestamping
    • Bug 33113: Bump NSIS version to 3.05
  • OS X
    • Bug 32505: Tighten our rules in our entitlements file for macOS
  • Linux
    • Bug 27903: Tor Browser 8 does not respect gtk3 settings
    • Bug 34315: Avoid reading policies from /etc/firefox on Linux
  • Android
    • Bug 26529: Notify user about possible proxy-bypass before opening external app
    • Bug 30767: Custom obfs4 bridge does not work on Tor Browser for Android
    • Bug 32303: Obfs4 is broken on Android Q
    • Bug 33359: Use latest Version of TOPL and Remove Patches
    • Bug 33931: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha
  • Build System
    • All Platforms
      • Update Go to 1.13.11
      • Bug 33380: Add *.json to sha256sums-unsigned-build.txt
    • Windows
      • Bug 33802: --enable-secure-api is not supported anymore in mingw-w64
    • Linux
    • Android
      • Bug 28765: LibEvent Build for Android
      • Bug 28766: Tor Build for Android
      • Bug 28803: Integrate building Pluggable Transports for Android
      • Bug 30461: Clean up tor-android-service project
      • Bug 32993: Package Tor With Tor Android Service Project
      • Bug 33685: Add Support for Building zlib for Android

Comments

Please note that the comment area below has been archived.

We are considering a security broken scenario primarily when the onion service is serving mixed content from an insecure URL.

You can learn more about our discussion in our former ticket about security indicators for onion services

https://trac.torproject.org/projects/tor/ticket/23247

and in our latest iteration

https://trac.torproject.org/projects/tor/ticket/32645

Anonymous (not verified) said:

June 03, 2020

Permalink

What is the difference between "Onionsite Security Broken" and "Onion Loading Mixed Content"? One of the images above shows two different sets of icons for these two.

I think "security broken" means the URL specifies https://, but the TLS certificate is bad. You're still protected by the .onion crypto, but not necessarily TLS. Mixed content means that a site, http(s)://xyz.onion loads content from a clearnet site, like http(s)://xyz.com. I'm just guessing here. Please read the docs and/or source code to be sure. Maybe the developers would like to clarify.

Anonymous (not verified) said:

June 02, 2020

Permalink

Tor NOTICE: Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6305/6321). That's ok. We will try to fetch missing descriptors soon.
---
That's ok. But it delays the bootstrap for several seconds.

Anonymous (not verified) said:

June 02, 2020

Permalink

uncaught exception: 2147746065 SessionStore.jsm:1325:22
(this bug was reported as fixed,iirc)

pastly

pastly said:

June 02, 2020

Permalink

"fooooooooooo.onion is requesting your private key" is misleading. Dangerous sounding, even. It's **not** dangerous, but it sounds like the onion service is trying to do something bad to you.

I seem to remember a ticket or comment in a ticket stating as much. I can't find it. So I'm making this comment here in the hopes that I make change happen :)

Thanks for the hard work, TB devs!

Anonymous (not verified) said:

June 03, 2020

Permalink

Thanks for this - I was slightly horrified when I saw the screenshot. Anyone with a little knowledge of public-key cryptography would know that you never send your private key to anyone. So I'd be reluctant to fill it in that dialog.

Went to comment but saw this has already been raised :)

Anonymous (not verified) said:

June 02, 2020

Permalink

> Go to 1.13.11
Sounds like GOTO ;)
"Updated Go to 1.13.11" is better. First time you do security update of compiler as a usual update. Go ahead!

Anonymous (not verified) said:

June 02, 2020

Permalink

>Onion Names

What stops the US government from forcing you to take down / unlist certain hard-coded addresses or even silently swapping them out for MITM attacks? What if other governments use this as a reason to ban Tor Browser altogether? After all, these services encourage people to leak confidential information.

Also, will you allow more people to register *.tor.onion domains at some point in the future? You wrote that it's a proof-of-concept... If so, I can already predict that you would be pressured to take down certain domains even if they're completely legal. I don't like where this is going to tbh.

This is not available for general use because we haven't found answers for these questions. This is a hard problem with bad solutions. We're starting with something simple and we'll improve it based on feedback we receive. There will be many more conversations about this before anything is built or deployed - so stay tuned for those.

But if the same .onion services are already available on the regular internet what difference would it make to government? Methinks all it would mean is better anonymity for the user if they chose to use Tor and the .onion address to visit the site, but the service itself is already available on the regular internet. Hence it's not a "hidden service" if it's mirrored from the regular internet.

Possibly. The internet-accessible site equally could be a "mirror" of the onion service. Onion services are not necessarily location-hidden, and location hiding is only one (minor) property of them. Using the .onion address is generally safer, but it is less usable because the name is none sense and/or it is "easily" phish-able (against end users). Unfortunately, the current solutions rely on first connecting to internet-accessible website, so you can learn about the onion address, and then connecting to the onion address you learned.

Yeah, it's not good or appropriate for the 501c3 regulated Tor Project to get into becoming a centralized naming authority, a whitelist operator, and effectively bundling a list of suggested websites to visit that are not part of Tor Project itself.

Anonymous (not verified) said:

June 02, 2020

Permalink

I thought Tor Browser's design was opposed to filter-like lists. Who maintains the distributed lists of onion domain translations? Who determines if an onion is truly operated by the clearnet mirror it claims to be?

For this release, we partnered with Freedom of the Press Foundation (FPF) and the Electronic Frontier Foundation's HTTPS Everywhere to develop the first proof-of-concept human-memorable names for SecureDrop onion services addresses:
[...]
Freedom of the Press Foundation has reached out to a small number of additional media organizations for participation, and Tor and FPF will jointly consider next steps based on feedback on this initial proof-of-concept.

Anonymous (not verified) said:

June 02, 2020

Permalink

Sorry, I meant the lists that redirect to onions. Torproject.org redirects to expyuzz4wqqyqhjn.onion. Do FPF and EFF also control the redirection lists?

But as for the human-memorable names, aren't they "for SecureDrop onion services addresses" for now as it says, whereas the redirection lists are applied more widely?

Ah. the redirection is advertised by the website. When you visit the first website (such as torproject.org), the webserver includes a "hint" that the website it also available at a .onion address. Tor Browser recognizes this and shows the ".onion available" button. There is not a list for this feature.

The human-meaningful short-names are only available for SecureDrop at this point in time, correct. Meanwhile, anyone can use the onion-location redirection.

Anonymous (not verified) said:

June 02, 2020

Permalink

It happened again... After a new version of NoScript is included in TorBrowser, NoScript's author almost right away replaces it with his even newer version (like v. 11.0.29 now), via an automated update that TorBrowser is set to accept.
While the updates always sound justified (and they may be), watch: this happens shortly after almost every TorBrowser release. Why?

TorBrowser devs, please close this potential security hole - disable the automated add-on updates, at least from NoScript. I think it's configured so in the Tails' TorBrowser.

Anonymous (not verified) said:

June 03, 2020

Permalink

A repeating coincidence... Check it out yourselves the few next times when TBB ships the new NoScript.

Thanks for looking up the existing ticket for this. It's opened 6 years ago!

Someone's suggestion to disable the auto add-on update by the individual users is probably not a good idea.

You can set them to Off in about:addons

Add-on Details - Allow automatic updates: Off

I have done this, so once again no automatic update here.

Come on Tor team PLEASE fix this security hole already....

Other than that everything seems to be working great, Thank you.

NoScript buttons are now greyed out for permanent site settings, preventing us from changing them per site. How do we get these buttons back without reverting to an earlier version of NoScript?

Anonymous (not verified) said:

June 02, 2020

Permalink

Great release.

The changelog is missing the gsettings workaround for #27903 that was added in this release.

phil (not verified) said:

June 02, 2020

Permalink

when I use youtube I get a thin white border in the youtube display ie not my screen display that was not there before this version ie ver 9.0.10

Has anyone else noticed this?

should it be there? why was it not there before?

Thank you

Anonymous (not verified) said:

June 02, 2020

Permalink

https://jqlsbiwihs.oedi.net/tbb/maximized-torbrowser-window/
the Tor border was noticed for some time at start up
https://www.zdnet.com/article/firefox-to-add-tor-browser-anti-fingerpri…
the Firefox border does not show when I start my home page

The Youtube border was not shown or at least noticed until I updated to this version, ie yesterday not noticed today as soon as I used youtube border noticed.

Thus not sure why Youtube border would not show in 9.010 but does show in 9.5

Thank you for prompt reply.

Before that version, Tor Browser used to show a message every time you went fullscreen advising you not to do so because your browser's width and height could be unique and therefore trackable. Letterboxing rounds your browser's width and height down to a round number like this so there's less entropy.

In addition the Youtube border does not show when I am not using Tor ie web browser without Tor So, the Youtube border is because of Tor and not the web browser

Thank you

Workaround: consider using https://invidio.us - an alternative frontend to Youtube. It has .onion addresses, and even works without javascript. See https://github.com/omarroth/invidious

Use any of the following addresses (Taken from https://instances.invidio.us)

name version type users signup location health
invidio.us 0.20.1-6435c7b https 29827 US 99.771
invidious.snopyta.org 0.20.1-6435c7b https 1302 FI 100.00
yewtu.be 0.20.1-8305af8 https 310 FR 100.00
invidious.13ad.de 0.20.1-8305af8 https 242 DE 99.984
invidious.ggc-project.de - https - - DE 99.910
yt.maisputain.ovh - https - - DE 100.00
invidious.toot.koeln - https - - DE 100.00
invidious.fdn.fr - https - - - -
watch.nettohikari.com - https - - DE -
owxfohz4kjyv...a.b32.i2p - i2p - - - -
axqzx4s6s54s...iid.onion - onion - - - -
4l2dgddgsrkf...gyd.onion - onion - - - -
kgg2m7yk5aybusll.onion - onion - - - -
fz253lmuao3s...cad.onion - onion - - - -
qklhadlycap4cnod.onion - onion - - - -
c7hqkpkpemu6...oid.onion - onion - - - -
mfqczy4mysscub2s.onion - onion - - - -

cheers looks interesting I will use invidio much appreciated we live and learn

Just so I am not misunderstood the youtube border is only slim, small and the film can still be clearly viewed

Thank you

Anonymous (not verified) said:

June 02, 2020

Permalink

You still didn't fix self-signed https onionsite. Why is this? This nightmare started since TBB version 8.

Can't you just ignore self-sign certificate if it's name and expiration is valid?

99% chance you shouldn't be adding self-signed certificates to your onion services. https://matt.traudt.xyz/posts/dont-https-your-o44SnkW2.html

It's not making you any safer unless you check it every time, which you're not. Oh you are? Okay. Do you have other users? They aren't checking it.

No one will notice when your certificate is replaced with an attackers. The attack that was already supposed to be impossible wasn't even stopped.

Anonymous (not verified) said:

June 03, 2020

Permalink

I disagree. Latest technology requires HTTPS connection. HTTP/2 cannot be used on http:. Mozilla add-on updates requires HTTPS connection.

> which you're not. Oh you are?
Yeah, I do this on my onionsite. Problem?

> No one will notice when your certificate is replaced with an attackers.

This is just silly. If the attacker can replace my certificate they must attack .onion first.
If you claim http onion is so secure, then you must accept that https onion is also secure because it is on onion system.

I know plenty of onionsites sitting on https for a good reason, and their owners do provide proof on their clearnet site.

>> which you're not. Oh you are?
>Yeah, I do this on my onionsite. Problem?

If you're already going to the trouble of checking the certificate hash of your site, then is it that much of an inconvenience for you to bypass the warning? The other points you make seem like they might be valid however. I'll have to look into it some more. Thanks for bringing this up. You should open a bug report and explain these problems and arguments in detail.

Anonymous (not verified) said:

June 03, 2020

Permalink

If the connection between Tor Browser and onion server cannot be MitMed like you advertised in support.tpo page, how do you explain the scenario that the hacker replace the onionsite's certificate? If you can do that, the connection to onionsite is not safe at all.

I have forum onionsite and it's https://.

Passerby (not verified) said:

June 02, 2020

Permalink

Regarding the onion names, wouldn't it be more effective to take the generated Onion URL and run it through a dictionary of words so that the end result would be:

wordsrandomlygenerated.onion

Named services (while conceptually useful for humans) would imply an inevitable centralized governance for deciding who gets what name for their onion service.

Yes, and this has been discussed a few times. One difficult problem is "which dictionary?". Tor users speak dozens of languages, so onion service addresses shouldn't be only some-combination-of-English-words, meanwhile using different word combinations for each language *and* those word-combinations being (likely) completely unrelated to each other would be terrible for usability.

Lisa (not verified) said:

June 03, 2020

Permalink

Why don't you use emojis? They're universal across all languages.

According to https://emojipedia.org/faq/, there are currently 3,304 emojis in the Unicode Standard. That means you can reduce the number of characters for the domain name dramatically!

Something like [EMOJI_1][EMOJI_2][...]][EMOJI_n-1].onion would be awesome. <3<3

----
Sadly this forum software doesn't support emojis... I wanted to post them for illustration purposes.

>The website encountered an unexpected error. Please try again later.
>Drupal\Core\Entity\EntityStorageException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value:
>...

Anonymous (not verified) said:

June 04, 2020

Permalink

Translated lists for every supported language could do. The related word combinations in different languages would point to the same onion service. There will be some overlap for the words: A translated word could be written the same as a word in another language. As long as it still refers to the same word there is no problem (e.g en:"machine" = fr:"machine" = word #52759). Else this could be fixed with adding the language code to the whole URL (e.g "en" , "fr").

Most work would be in generating the translations. That could probably be automated. The checks for profanity and splitting apart words that were translated to the same word or refer to diffrent word # could be crowdsourced. The final check for unambiguousness can be automated again. After that the lists are fixed and few support is needed. Additionally those lists are highly reusable for other projects.

New languages can be added through the same process. But if the word combinations are not marked with a language code, they will need to work around the existing lists.

It's not inevitable. Not easy, but not inevitable. See "squaring zokoo's triangle" by the late Aaron Swartz. Case in point: "Namecoin" is a fork of bitcoin that has managed to completely decentralize the .bit namespace. It uses a blockchain, proof-of-work, digital signatures, etc, just like bitcoin, but instead of deciding on who is the rightful owner of some coins, it decides what is the rightful address of a .bit name. There are other similar, and not-so-similar, approaches for decentralized name systems. This was discussed on the Tor blog back in 2017: https://vbdvexcmqi.oedi.net/cooking-onions-names-your-onions

Anonymous (not verified) said:

June 02, 2020

Permalink

[06-03 04:07:38] Torbutton WARN: Version check failed! JSON parsing error: SyntaxError: JSON.parse: expected ',' or ']' after array element at line 19 column 1 of the JSON data

Anonymous (not verified) said:

June 02, 2020

Permalink

But in mid-2019, the formerly green lock icon became gray

We are following Firefox on this decision

Is the green lock icon going to change to grey? For me it's still green, e.g. right now on this page it's green.

Anonymous (not verified) said:

June 13, 2020

Permalink

Every https URL still has a green lock icon. I'm using TBB 9.5 on Linux, updated from the previous release (not a fresh install).

Anonymous (not verified) said:

June 03, 2020

Permalink

This might be a niche and pedantic complaint, but when you visit an onion site that requires authentication (as in this screenshot) and you click cancel, then you click the circled-i button to the left of the URL, it says connection is not secure.

But there is no connection, and any handshake-type stuff that happens is all secure, right? Maybe it's not an issue but I thought I'd just bring it up.

Anonymous (not verified) said:

June 04, 2020

Permalink

This is how all firefox internal webpages work. They are not https: (usually, about:), that's why 'not secure'.

site blocket o… (not verified) said:

June 03, 2020

Permalink

Hello! While trying to access riseup.net on Tor, I got a screen with a 'Site blocked' message, served by a company called Neustar. It is the first time that it happens and I am wondering what is going on here. Why do they act on Tor network? Thank you.

Anonymous (not verified) said:

June 03, 2020

Permalink

I have a question about the Onion Location Header. Aside from being easier for site admins to configure, how is this better than detecting when the remote address is a Tor exit node, and sending a 301-Redirect header containing the .onion? The latter works even if the client is not a Tor Browser, for example in the case of Debian package mirrors, chat clients, and any other HTTP-based protocol. Is it expected that HTTP client libraries like cURL and wget will eventually begin to honor the onion header, too? Thanks.

I presume it's because users should be given the freedom to decide whether the want to be redirected to the onion site. My concern however is about the possibility of a MITM attack intercepting Onion Location Headers and replacing real .onions with malicious ones. I wonder if this possibility has been considered?

Yes, it is about consent. Regarding modification of the header in-transit, the situation is no worse than any other HTTP header provided on the connection (either for 'alt-svc' or 'location' redirection). In this case, onion-location is only accepted over "secure" connections (https and http+.onion).

Therefore, I don't suggest you trust an onion-location advertisement when you visit a website and click-through an invalid certificate warning - but this isn't something Tor Browser can decide on its own.

Anonymous (not verified) said:

June 03, 2020

Permalink

Playing video is still broken.

NotSupportedError: The media resource indicated by the src attribute or assigned media provider object was not suitable.

Anonymous (not verified) said:

June 03, 2020

Permalink

When we will the problem with the custom android bridges get fixed?
When we will be able to use them?

Anonymous (not verified) said:

June 06, 2020

Permalink

I tried more bridges and it worked.
I am pretty sure that the firewall of my country blocked the bridges before.
Thanks for your excellent work!

but "sdt.onion" is not human meaningful. "securedrop.tor.onion" is long and less user-friendly, but it tells the user exactly which group is defining the name mapping.

I want to write a blog post describing the trade-offs we considered and why we are trying this naming scheme. I hope that will be written/published in the next few weeks so we can get feedback on it.

584Bbrw2 (not verified) said:

June 03, 2020

Permalink

On the android version of tor 9.5 in Settings>Privacy why is the box for clearing tor data on user clicking "Exit" not selected by default, does tor clear all data if user just exits app without clicking "exit"?

As this could put people without much browser knowledge at risk.

This is a massive upgrade compared to 9.0 well done tor team!.

Tor Browser on Android clears all data when you explicitly exit the app and when the app is killed/closed for any other reason (including opening the Recent Apps list and swipping the app "away").

Android is not an easy platform for developing privacy-oriented apps, but we are trying to make Tor Browser safe-by-default.

Thanks for the kind words!

Anonymouse (not verified) said:

June 03, 2020

Permalink

NoScript 11.0.26 or 11.0.29 not functional on my 32-bit version of Tor Browser 9.5 on Linux. When clicking on any of the buttons in the NoScript drop down menu, that particular line just flashes yellow and won't change from the DEFAULT setting. NoScript worked fine up to TB 9.0.10.
Should I reinstall Tor Browser or even try an older version of NoScript?
Thanks for the hard work everyone is putting in to the Tor Browser.

Anonymous (not verified) said:

June 03, 2020

Permalink

In the article, you link to a Cloudflare blog post (https://blog.cloudflare.com/cloudflare-onion-service/) where they talk about supporting alt-svc with .onions as an alternative to captchas. This seems pretty exciting, as Tor has been plagued for many years by Cloudflare blocking it, sometimes even with malicious unsolvable never-ending captchas that just waste the user's time.

Unfortunately, I tried visiting a few Cloudflare sites, and I'm not seeing the ".onion available" banner. (I do see it on torproject.org so it's not my setup.)

Any idea what the status of this is? The Cloudflare blog post is over a year old.

The Cloudflare configuration allows Tor users to bypass one layer of abuse-detection when the connection uses the (alt service) .onion address. Cloudflare still shows a CAPTCHA in some situations, even if the connection is using the .onion address (because some shitty people still use Tor for abusive behavior).

Cloudflare shouldn't be blamed for the unsolvable captchas. Those came from a system provided by Google. Recently, Cloudflare switched to a new captcha provider, and hopefully the captchas will be better now, in general.
https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptcha/

Cloudflare does not use the onion-location header we discussed in this blog post. They use the invisible alternative services method. This is a better option for them because Tor Browser user will continue seeing the website they expect in the url bar (https://example.com) but the browser will transparently connect to a .onion address instead.

Anonymous (not verified) said:

June 05, 2020

Permalink

> [the "alt-svc" header] is a better option for them because Tor Browser user will continue seeing the website they expect in the url bar (https://example.com) but the browser will transparently connect to a .onion address instead.

If alt-svc works for cloudflare, and has for some time already, then why was the recent onion header feature developed, or even desirable? The alt-svc header seems like a superior solution to me, for the reasons you explained. The only exception I can think of is if users bookmark the .onion and use it long-term, it could be more trustworthy/authentic than the site's domain name and TLS certificate.

The only benefits (I know about) are 1) as a person visiting the site, you are given a choice about how you connect (through an Exit node, or via onion service), 2) it gives website operators a way of advertising they support Tor ("support" in that they have an onion service and they are Tor-friendly (presumably)), and 3) advocacy/awareness.

There is some debate about whether website operators should require consent before redirecting connections through an onion service (do you need consent before upgrading connections to a more secure protocol?). However, this is an important educational moment, as well. Many Tor users do not really understand onion services, and we are hoping this feature brings more awareness about it. In addition, as more sites adopt this feature, it shows that Tor and onion services are used/available around the web, where they were completely invisible before.

Anonymous (not verified) said:

June 06, 2020

Permalink

Ah, I understand, and completely agree with #2 and #3.

I think #1 is a valid but rather weak argument. a) Users of the web are already subjected to all kinds of things without their consent or choice. Tracking, malvertising, whether or not to connect via Cloudflare/Cloudfront/Akamai/etc in the first place. Upgrading to .onion is probably the most benign - if not benevolent - of anything. I agree with user control and consent, but b) if the site can still silently send alt-svc, there's really no consent to begin with. It's a tough call. Thanks for the reply!

Anonymous (not verified) said:

June 06, 2020

Permalink

Thanks for this. It's been years since I've even bothered trying to solve a Cloudflare captcha (or even enable javascript on their pages for the captcha to appear) due to having had my time wasted by neverending captchas in the past, so I hadn't even noticed they'd changed to a good provider.

Anonymous (not verified) said:

June 03, 2020

Permalink

In recent versions I've been having an issue where if I go to Options -> Privacy & Security -> Cookies and Site Data and click "Manage Permissions...", and I "Allow" a few sites where I want to save a login cookie, these settings get deleted when restarting the browser. This used to work. Not sure exactly what version it stopped working - possibly 9.0. Now, every time I restart the browser, I have to go into those settings and re-apply them to prevent the cookies being deleted on next restart.

To be clear: it's not the cookies that get deleted (at least not initially), it's my cookie settingsthat get cleared.

I realise this is a non-default configuration, but is there any chance you could fix this?

Anonymous (not verified) said:

June 03, 2020

Permalink

How do the tor.onion URLs work? How were they created and is there a plan for them to be more widely adopted? What's the difference between the v2 and v3 onions?

This is a loaded question/comment :)

1) Tor Browser includes a hard-coded list of *.tor.onion domains. Currently this list only includes SecureDrop instances under *.securedrop.tor.onion and the list is provided by Freedom of the Press Foundation. We are interested in expanding this for other organizations/people, but we don't know exactly how we can do this safely (this is why we only have one at this time).

Version 2 onion addresses rely on cryptography that was standardized in the 1990s and its strength is based on assumptions that made it secure "for the next 10-20 years". Unfortunately, that was (approximately) 20 years ago. This does not mean version 2 onion services are broken (there doesn't exist any evidence that this is true), but the underlying cryptography is not as strong as we need. This prompted the development of version 3 onion services (v3). v3 onion services use modern cryptographic primitives and they protect against other network-level attacks. Unfortunately, v2 onion addresses are much shorter than v3 onion addresses. While shorter addresses are more memorable, they provide significantly less protection and they are much less secure today. (Nearly) Everyone should use v3 onion services now, whenever possible.

Anonymous (not verified) said:

June 15, 2020

Permalink

You say

Everyone should use v3 onion services now, whenever possible.

Than please show this by turning torproject.org into osv3 instead v2.

Anonymous (not verified) said:

June 03, 2020

Permalink

(#8) Error Killing GPU process due to IPC reply timeout
(#9) Error Failed to connect GPU process
(#10) Error Receive IPC close with reason=AbnormalShutdown
(#11) Error Receive IPC close with reason=AbnormalShutdown
(#12) Error Receive IPC close with reason=AbnormalShutdown
(#13) Error Receive IPC close with reason=AbnormalShutdown
(#14) Error Receive IPC close with reason=AbnormalShutdown
(#15) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown
(#16) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown
(#17) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown

Poisoned Exten… (not verified) said:

June 04, 2020

Permalink

How difficult would it be for a particular extension maker/hoster shipping with TBB to identify the update request as coming from an exit node and serve a different, poisoned update strictly for TBB users?

I'm not suggesting this happens, I'm asking because I'm curious.

Tor Browser includes two extensions, by default: HTTPS Everywhere and NoScript.

For NoScript, this would require collusion between Mozilla and the NoScript developer.
For HTTPS Everywhere, this only requires collusion between EFF developers and EFF sysadmins.

Anonymous (not verified) said:

June 04, 2020

Permalink

Is it safe to use fullscreen with the browser's built-in video player or does it give away the resolution?
By "browser's built-in video player" I mean the player that is used when you open a video file (.mp4, .webm...) directly instead of using the website's player (youtube, vimeo...).

Norah (not verified) said:

June 04, 2020

Permalink

Hi everybody. I am new to Tor. Why when I use search bar I still get browser I used before Tor? Thank you.

Hi, welcome! Tor Browser is simply a modified version of Mozilla Firefox. When you use the search bar, your query is sent to DuckDuckGo (by default) which is a competitor of Google. Tor Browser is simply a safer agent of you as you browse the Internet.

Den from Mosco… (not verified) said:

June 04, 2020

Permalink

Thanks a lot for all Tors instructors and customers! Real good program! If it'll be much more money, will send it to you brothers!

Zoooopppp (not verified) said:

June 04, 2020

Permalink

When the problem with android bridges will get fixed ino the stable Tor browser?
It is impossible to use custom obsf4 bridges...

Anonymous (not verified) said:

June 04, 2020

Permalink

I wish it was bumped... as in included like it should be, instead of automatic updates.

Hi, another Anonymous! It's hard to understand what you want to say without proper grammar. But NoScript is a pet project of Giorgio Maone, and it is his sole decision when to update (usually, many times a month).

What is wrong with my grammar? Getting tired of being ignored, so I don't put much effort in sorry. This among many other reasons is why the functions should be included in the browser instead.

Anonymous (not verified) said:

June 06, 2020

Permalink

Then there appears to be some bug. Possibly because I have automatic updates for add-ons set to Off. I checked the add-on manifest page and indeed it appears to say version 11.0.26 is the version installed. However the add-on details page says 11.0.25.

? (not verified) said:

June 04, 2020

Permalink

"I am fine logging this as a bug [...]"
Pretty lovely nice.

What's the reason for this easy to fix bug -a character string?- is not solved after this long -19 months ago!- time?
Why Torbrowser must report the real system OS?
Who really need this?

Anonymous (not verified) said:

June 05, 2020

Permalink

Is there any particular reason as to why https://vbdvexcmqi.oedi.net doesn't have a .onion address? As well as the fact that https://trac.torproject.org has an onion address listed here https://onion.torproject.org/ but it currently doesn't have Onion-Location setup on the server, though I'm guessing this one will be fixed soon? Also why exactly doesn't tor use a single unified .onion address using subdomains like the torproject.org domain for clearnet? The only domain I see having an issue in that list is 2019.decvnxytmk.oedi.net.

> Also why exactly doesn't tor use a single unified .onion address using subdomains like the torproject.org domain for clearnet?

I can't speak for TP or anyone else specifically, but generally speaking:

1) The browser would send the same "Host:" header, where it would otherwise be different for each subdomain, so it makes webserver configuration difficult, and could break server-side code that relies on subdomains
2) The private key has to be shared by every site that uses the .onion. If any one site or service compromised, all of them are compromised. There's no security separation or hierarchy. If vbdvexcmqi.oedi.net were compromised, then so would be ftp.torproject.org.
3) With a regular domain name, the webserver is separated from the domain name (registrar). Even if your site is hacked and SSL private key is stolen, the attacker cannot control your domain name (assuming your registrar account wasn't also hacked). With a .onion there is no such separation; a .onion is permanently associated with its private key in a 1-to-1 fashion. Unlike a regular domain name, once compromised, a .onion can never be made trustworthy again. Therefore it's more important to use different .onion addresses for different services (compared to regular domain names), in order to limit the scope of the potential damage.

Yes, you could probably come up with a sophisticated proxying key-sharing load-balancing scheme for using the same user-facing .onion to access multiple independent backends securely, but there's no simple solution as far as I know.

What an ugly w… (not verified) said:

June 05, 2020

Permalink

It would be so much easier were you to create a web forum for people to access.

Yes, I know there are options available, unofficial ones. I want to see an official one, and I know about the ML. This would solve so much if you would just implement this idea. Thank you.

Anonymous (not verified) said:

June 05, 2020

Permalink

Is there a way to turn the pink .onion available thing off? When I click on it, it just disappears, nothing happens.

Anonymous (not verified) said:

June 06, 2020

Permalink

Like I said nothing happens. Possibly could be because I have set StrictNodes 1. I would expect some notification to popup to show the onion and ask permission to connect, but nothing. The pink .onion available button just disappears? I think there may of been some popup that flashed the first time but nothing now, could of been imagining that though! Could you please tell me what the css modifier is so I can hide/or color the button?

While on the subject. I think it would be a good idea to have error pages for such settings often I just get the timed-out error page, which doesn't explain anything. Thank you.

The behavior you are describing is very strange. I agree we should provide a message and/or error if there is a failure of some kind. "StrictNodes 1" should not result in this behavior, because you should receive an error page saying the website could not be loaded (instead of failing silently).

I opened a ticket for this: https://trac.torproject.org/projects/tor/ticket/34395

The css patch is:
https://gitweb.torproject.org/tor-browser.git/diff/browser/components/o…

Anonymous (not verified) said:

June 11, 2020

Permalink

I figured out the problem. After clicking the button that disappears, if I change tabs, the button reappears. Upon clicking it the second time the message "Tor Browser prevented this page from automatically redirecting to another page." appears. Due to having "accessibility.blockautorefresh;true" set, with this as false it automatically redirects, though there is no popup to verify the redirection, which is the kind of reason why I have this set. Clicking allow then tries to load the onion, though as usual for me it just endlessly loads then times out.

Anon (not verified) said:

June 08, 2020

Permalink

The .onion redirector doesn't really work, Tor Browser is stopping autoredirects and I need to click "Allow" in the top bar to make it work...

mmiinneerr5599… (not verified) said:

June 08, 2020

Permalink

I've tried to bring in Tor several times . Costing me almost 200 MB each time just to find out that once again it won't work for one reason or another . Is Tor being blocked ? Am I doing something wrong ? Is it just another of the many scams I encounter in a day ? An inquiring mind wants to know but can't find out . I know nothing about the net or web or whatever . I do know I'm being blocked / cenceored by a virus riding on chrome and can do nothing about it . Screw it . Good by .

We may respond, but we don't have any useful information. The Tor Project does not collect/log IP addresses for websites hosted on our webservers. Similarly, the Tor network is run by volunteers, so The Tor Project doesn't have access to users' IP addresses connecting to relays in the network.

Anonymous (not verified) said:

June 10, 2020

Permalink

For all PDF's in the safest security level.
I'm using MacOS High Sierra and Tor Browser 9.5.

Do you have Javascript completely disabled? In recent Tor Browser versions, on the "Safest" security level, Javascript is disabled within the entire browser. You can re-enable it by opening "about:config", search for "javascript.enabled" and toggle the preference to "true". Please see the announcement on the Tor Browser 9.0.7 blog post: https://vbdvexcmqi.oedi.net/new-release-tor-browser-907

CRhode (not verified) said:

June 09, 2020

Permalink

Three problems:

1) Can't get past CAPCHA logging in on bugs.torproject.org with TOR Browser. No CAPCHA logging in with Firefox. The irony!

2) Can't submit new bug to the bug tracker because my login's not authenticated.

3) I wish to register a complaint about the "cousine" monospace font used by the Tor Browser. (Firefox uses DejaVu Sans Mono.) To wit: The "box drawing" characters aren't monospace.

Try this on YOUR browser:

╔═══════════════════════════════╗
║ INDEX ║◀━━━
║ ║
║ ┏━━━┓ ┏━━━┓ ║
║ ┃ < ┃ ┃ > ┃ ║
║ ┗━━━┛ ┗━━━┛ ║
║ TabUp TabDn ║
║ ┏━━━┓ ║
┏━━━━━━━━━━━━━━┫ ▶ ┃ ║
┃ ║ ┗━━━┛ ║
┃ ║ Start ║
┃ ║ ║
┃ ║ ║
┃ ╚═══════════════════════════════╝
┃
┃
┃
┃ ╔═══════════════════════════════╗
┗━━━▶║ SLIDE ║◀━━━
║ ║
║ ┏━━━┓ ┏━━━┓ ║
║ ┃ < ┃ ┃ > ┃ ║
║ ┗━━━┛ ┗━━━┛ ║
║ Prev Next ║
║ ┏━━━┓ ┏━━━┓ ║
┏━━━━━━━━━━━━━━┫ ▶ ┃ ┃ ┃ ║◀━━━
┃ ║ ┗━━━┛ ┗━━━┛ ║
┃ ║ Play Blank ║
┃ ║ ┃ ║
┃ ║ ┃ ║
┃ ╚═══════════════════┃═══════════╝
┃ ┃
┃ ┃
┃ ┗━━━━━━━━━━━━━━━━
┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

notimportant (not verified) said:

June 10, 2020

Permalink

Is it by desin that the in the new version, noscript remembers the site settigs if "overide tor browsers security level preset" is checked?
I remember it being mentioned in an earlyer discussion that saving noscript settings is (was?) considered a security risk?

Alternate Serv… (not verified) said:

June 16, 2020

Permalink

I have seen this too on tbb9.5 and older. Some sites like forum and others.
Onion is something, i think, with cloudflare. Endless hops with "Alternate Service Mapping", i don't remember setting in about:config, on(=default).
Message is about network-observer.js.

Jon Anderson M… (not verified) said:

June 11, 2020

Permalink

1) it's difficult to locate your 'Feedback' link
2) your 'Update' process says: " Restart to Update Tor' " which is so confusing!! 'Restart WHAT ??? .. restart Win10 ??? restart the Tor browser ?? Each possibility can result in MAJOR problems !! so: ASK US DIRECTLY ! : "' Restart TOR ....." .... "Restarting Windows can be a LONG and frustrating exjperience !!" ( 15 mins on my huge system !! ) !!

Thanks for the feedback. This is a good place for it. We can improve this update experience if the interface doesn't make clear the "Restart to update Tor Browser" message is a button that restarts the browser (not the computer).

Anonymous (not verified) said:

June 11, 2020

Permalink

Just a nitpick, but in future I would appreciate if you didn't include screen captures with subjects such as politics. If I wanted to read that propaganda, I would visit the websites myself. Thank you.

NoScript provides protections in addition to filtering javascript, therefore you are better enabling the Safest security level which includes settings javascript.enabled to false and other protections.

Anonymous (not verified) said:

June 12, 2020

Permalink

Is the "onion site available" feature supposed to work on android too? I tried torproject.org and EFF.org and I'm not seeing any indication.

Anonymous (not verified) said:

June 13, 2020

Permalink

Scary red screen + 'Something went wrong!'

How does Tor Browser know that something went wrong?

A check at check.torproject.org reveals: Congratulations. This browser is configured to use Tor.

So the two official statements would seem to contradict each other. Did something go wrong or not? Also, why is Tor making this check on browser start? Is Tor Browser sending connection information to a server somewhere we should know about?

There are four questions asked in this comment. Thanks for playing.

The "Something went wrong!" page is created if the browser's connection with the (local) tor client is in an unexpected state. The browser doesn't connect to check.torproject.org.

Anonymous (not verified) said:

June 13, 2020

Permalink

[Moderators: why does the Outreachy post forbid user comments?]

Google funding always makes me nervous because that company's business goals typically seem oppositional to the cybersecurity and privacy needs of Tor users. That said, I am particularly happy to see this:

> Nicolei Ocana - Introduction
> Project: Help Tor Project support our users
> Mentor: Gus
>
> This project will help us to support our users and ensure that they receive and can find the most up to date information on using our products.

Off the top of my head:

o Probably the simplest and easiest positive step would be a regular Friday post in which Tor users are allowed to post observations, questions ("is the following evidence of an attack or a bug or just me not doing it right?") and concerns not neccessarily related to anything TP has posted recently; if NO could do that he might get some good ideas about the rest of his work at TP,

o NO should not assume everyone has fast internet, a smart phone, email, access to international electronic payments etc--- many potential users who badly need Tor do not live in places where such things are easy for poor people to obtain,

o Tor documentation still needs massive reworking (i) all pages should have date of last update (ii) smaller images so faster loading time for users w slow internet (iii) Community Portal needs to be updated to take account of COVID-19 lockdowns (iv) prompt reporting of evidence of novel attacks on Tor users esp by state-sponsored attackers who hire cyberware as a service companies like NSO Group (v) help desk for those setting up and using onion sites (aimed at small newspapers and small NGOs) (vi) clearer description of how to report bugs or possible cybersecurity issues to TP (vii) some job descr in TP needs to include tracking all of these things to make sure they get done (tickets perhaps?),

o Posts by TP researchers/coders are all too rare and I have been begging for years for (i) an authoritative overview of how cryptology is used in Tor and how TP is preparing for practical easily deployed quantum cryptanalysis, (ii) review of other possible attacks exploiting flaws in pseudorandom number generators, flaws in clock sync, on-by-default built in microphones, known close access attacks (e.g. "stray emanations" from devices and peripherals"), etc. (iii) comparison of i2p (for example) to Tor circuits, (iv) best guess of risks in using/operating onion sites, (v) most interesting new ideas from the privacy research literature, (vi) node diversity (e.g. once again a single large family appears to carry at least 1/3 of Tor exit node traffic--- that's too much potential surveillance power for anyone to have--- what if USG somehow takes control of that family?)

o I'd love to see TP working more closely with Signal and i2p in particular; these technologies seem very different from Tor but with creativity perhaps they can be combined so that 1+1=10,

o I'd love to see more explicitly political work by TP, e.g. working with ACLU, EFF, Privacy International, RU and CN groups to try to pressure political leaders to allow more freedom (obviously very challenging task in RU, CN, US, UK but for sure things will only get worse if we do not fight back in the political as well as the technical arena).

If the blog post does not allow comments, then that is because the author wasn't looking for feedback. I don't understand why receiving funding from Google should make you nervous, how Tor uses the funding is what matters.

On that topic, Tor barely has enough resources (person-time, funding, know-how) for keeping everything working as well as possible. Nearly everything you ask is only possible if Tor doubles in size (in nearly every way), until then this will remain a wishlist (so we can concentrate on keeping this ship floating and moving in the right direction at a reasonable speed).

Anonymous (not verified) said:

June 17, 2020

Permalink

"I don't understand why receiving funding from Google should make you nervous, how Tor uses the funding is what matters."

If you don't understand why, then you need to retake Ethics 101 without cheating.

Newhire quality at TorHQ seems a bit lacking these days.

Anonymous (not verified) said:

June 15, 2020

Permalink

Sorry to be off topic, but since I just figured that trac.torproject.org went read-only, will your gitlab instance open to the public for bug reporting/contributing any time soon?

Yes, "soon". This is being worked on, but gitlab is a very different beast from trac, so some functionality won't be like-for-like. New accounts will be created as needed beginning in the near future, but finding a replacement for the cypherpunks account is still an open problem.

Anonymous (not verified) said:

June 17, 2020

Permalink

Unfortunate that discussions don't appear to load without javascript on gitlab. Is it possible for you to fix this?

Anonymous (not verified) said:

June 16, 2020

Permalink

Since 9.0 release it's not possible anymore to use TBB without Tor. Before that I'd use a separate manually "un-tored" bundle for situations where I need to connect without Tor while still benefiting from TB's browser patches. For example, I don't want to login into certain non-anonymous accounts over Tor when there's no benefit and could even cause problems of various kinds.

I wish this was still possible, I don't want to give up all your wonderful browser patches just to connect without Tor.

I know there exists SecBrowser developed by Whonix, but it's not available as a downloadable bundle, you can install it only on Debian. I'm not sure even SecBrowser works anymore though, since it relies on user.js and TBB (since 9.0) overwrites those tor-releated user.js preferences back to defaults. Manually setting those preferences in about:config doesn't work either, anyway.

I hope someone is willing to look into this, even though it's a non-standard use of TBB.

sas (not verified) said:

June 16, 2020

Permalink

Suggestion: I think it would help making the user more annonymous if the Tor Browser would natively support user agent spoofing as that of anti-fingerprinting feature....

Tor Browser does spoof the user-agent string in the HTTP header. The real OS is available via javascript because some javascript apps break if the browser lies to them about the OS (because other assumptions are wrong in the future). This is the trade-off: break the web or reveal the OS. If you use Tor Browser's Safest setting then you will protect yourself against revealing your operating system.

Anonymous (not verified) said:

June 16, 2020

Permalink

"real OS is available via javascript"

Especially with Javascript on it would be good for security i can choose not to
expose my real OS?
And how can i shut up this in the vanilla Firefox?

Anonymous (not verified) said:

June 17, 2020

Permalink

But the safest setting disables a lot of other stuff too.

Hmm. Why not simply provide an additional checkbox to disable that particular script inquiry? Let the user decide.

Because then Tor Browser users are additionally partitioned into people who use the default setting and those who are spoofing their operating system (and the second group will likely be much smaller than the first). This is not meant to imply Tor Browser won't provide such a configuration option, but it is not a priority.

Can you explain why spoofing your operating system is of such importance?

eh (not verified) said:

June 17, 2020

Permalink

"Can you explain why spoofing your operating system [...]"

Interresting.
The user of TBB have to explain why one not really necessary distinction-/fingerprinting-feature, the OS, must be visible with Javascript -unspoofable.
Possible convenience for very few people vs. anti-fingerprinting for all?

Anonymous (not verified) said:

June 25, 2020

Permalink

That doesn't even make any logical sense.

Considering the vast majority of data harvesting websites utilize javascript.. what is the point of spoofing the user-agent string at all? To say Tor spoofs it when spoofing would have no real world impact for the average Tor user? To wit:

"Black-or-white logical fallacy: Where two alternative states are presented as the only possibilities, when in fact more possibilities exist."

Of course more possibilities exist. Give the user control over this specific function, if they so desire it. 'Safest' setting is not a valid answer as it breaks everything else.

We want to thread the needle, and not with a sledgehammer.

But by "threading the needle" you are now part of a very small Tor Browser population. How would toggling an option like this provide you with *more* protection if you move from "1 out of 500 000" to "1 out of 3 000"?

Anonymous (not verified) said:

June 16, 2020

Permalink

Suggestion: Remove metadata from uploads with something like exiftool -all=

Maybe make it optional, dunno. I think whistleblowers could benefit from this a lot.

User (not verified) said:

June 17, 2020

Permalink

Hi,
as far as I know the Tor Browser is based on Firefox ESR.. What is the reason then to send the website referer when opening a link in new tab. Firefox ESR doesn't seem to be doing the same thing.

Thanks

user (not verified) said:

June 22, 2020

Permalink

Well yeah exactly. I right click on a link to open it in a new tab. Then if I refresh the new tab after the site has fully loaded, while opening the web developer tools network, the referer is sent with the get request. If I right click https://wiki.mozilla.org/Security/Referrer
the referer will be sent as:
Referer: https://vbdvexcmqi.oedi.net/
Why is this happening? I tried the same on Firefox ESR & as one would expect, it did not send the referer.

Many thanks.

Why would one expect the request to not include a referrer? This sounds exactly like the correct behavior (based on the purpose of the Referer header). I would expect Firefox includes a referrer, too. Opening a link in a new tab does not break the chain of context between the source and destination webpages. If you right-clicked on the link and copied the URL and then pasted that URL in a URL bar, then I would expect that Firefox would not know or include a referrer.

invalid (not verified) said:

June 20, 2020

Permalink

When did you re-allow enterprise policies? Does this mean this is now safe to use?
Why is canvas blocking only temporarily possible? Browserleaks.com, e.g., is always (after a Tor restart) able to extract canvas data on loading. Why does browserleaks report that i´m apparently using all sorts of adblock filters like fanboy etc. when actually i´m not subscribing to anything?

Enterprise Policy was first enabled in https://vbdvexcmqi.oedi.net/new-release-tor-browser-95a12 (and it was included in 9.5 stable). It is only controllable by a file placed in the correct location in the Tor Browser installation. The dangerous parts of it should still be disabled. https://bugs.torproject.org/32418

Browserleaks sounds buggy, and for blocking canvas, Tor Browser should prompt you for permission before the website is allowed to extract data. Permissions are not saved across restarts (by default).

Anonymous (not verified) said:

June 26, 2020

Permalink

On Tor Browser 9.5 for Windows, with the security level set to "Safest," the NoScript plugin is not able to temporarily enable JavaScript for websites. This issue remains even if the plugin is instructed to override Tor's default security settings. I noticed the problem at protonirockerxow.onion, ProtonMail's onion site. The Tor Browser was used without modification beyond choosing the safest security level. I'm glad that the issue leaves the browser too secure instead of insecure. I would appreciate some help with this issue, as using the safest mode is important to me. Thank you in advance.