Feedback/Proposal for SecurityLevel module for Tor Browser 14.5.4

Feedback Tor Browser Feedback
1

This is my first forum post here, please forgive any mistake I may make while writing this. I’m not completely acquainted with the community’s rules other than what is specified in the guidelines.

(Summary)

Contains my feedback and feature proposal for the SecurityLevel module. I would like other forum members to share their thoughts regarding my proposal to see if I’m missing anything drastic from a security standpoint.

Feedback:

  • I like the new SecurityLevel lock mechanism.
  • I dislike that the SecurityLevel lock mechanism can’t be toggled.

Feature Proposal:

  • Add a new checkbox under “Security” to enable or disable the session lock functionality
  • Once enabled, Tor Browser acts the same as it does in 14.5.4.
  • If disabled, Tor Browser will be forced to reset the session
  • Once disabled, Tor Browser allows security levels to be switched in the same session.

Graphical Depiction:

Browser Security Level Graphical Depiction
Browser Security Level Graphical Depiction731×310 21.7 KB

(Reason for Proposal)

When trying to access a website requiring Javascript, like https://imgur.nerdvpn.de/ for example, if I load this website on “safest”, I am not able to complete the Proof of Work and acquire the session cookie to access the site. If I switch to “safer”, my browsing session and anything I was logged into or had open, is gone.

Before Tor Browser 14.5.4, I would easily be able to access this site while retaining my browsing session by simply switching “Safest” to “safer”, getting the cookie, then switching back to “safest” and browsing without JavaScript.

(Conclusion)

I hope this forum post conveys my points and reasoning behind a change like this, and would again love to hear the feedback and ideas of others.

4 Likes
2

I second this proposal. I think I understand the rationale for locking the security level to a session in the latest release, but I’d like to be able to override it in settings, as @consciousness0 has suggested. The current behavior should remain the default to protect the average user, but I too have use cases where I’d like to change the SecurityLevel on the fly. I also fear that the removal of the ability to do this in Settings may result in some users venturing into about:config in order to circumvent this control - i.e. by changing the value of the browser.security_level.security_slider setting and then dismissing the confirm popup that results. Better that users comfortable with legacy behavior can instead tick a Settings checkbox, as in this proposal.

My own 2 cents: I do not like the new popups associated with the browser.security_level.security_slider and browser.security_level.security_custom config settings. The user is asked to tick a disclaimer box before entering about:config and that should be enough to validate that the user takes responsibility for any changes made there. This should include changing the SecurityLevel within a session. Additional popups detract from the UX IMHO.

This all said I’d like to congratulate the team for getting 14.5.4 out :onion:

2 Likes
3

Hi @consciousness0 – welcome to the Tor Forum, and thanks for being so thorough with your feedback!

For context, some (emphasis on some, not all) of the settings the security level selector changes under-the-hood require a restart before they take effect, which wasn’t communicated to users or enforced in our previous interface. That’s why the new interface forces a restart after changing security level, and also why I’d rather avoid providing users with a way to restore the previous interface as it was.

(Even if this wasn’t the case – maintaining two distinct interfaces to do the same thing isn’t very efficient, and we’d rather try and arrive at a single interface that works for everyone, if possible)

However I fully recognize the pain point both you and @noino have highlighted about losing the ability to quickly switch security levels on the fly. I wonder if we could come up with an alternative solution instead?

For instance, when you would temporarily downgrade to Safer in the past, was this workaround exclusively to enable JavaScript on a temporarily basis? Or are there other reasons you would downgrade mid-session too?

If so, it sounds like adding a way for Safest users to temporarily enable JavaScript (preferably on a per-site basis) may solve the issue. This could be done via the security level panel that can be accessed from the toolbar, for example. However this is purely an idea – and the feasibility of any solutions I spitball here would need to be thoroughly investigated by the Tor Browser developers first.

1 Like
4

A relevant comment on this issue was posted by user @teres3 on another thread:
https://forum.torproject.org/t/new-release-tor-browser-14-5-4/19562/5

The user’s point re Cloudflare is a good example of a use case where previously changing security level mid-session (from “Safest”) was useful.

@donuts

For instance, when you would temporarily downgrade to Safer in the past, was this workaround exclusively to enable JavaScript on a temporarily basis? Or are there other reasons you would downgrade mid-session too?

Enabling JS (for turnstiles/captchas/other required functionality which is broken in “Safest”) on a per-site basis is what I am primarily thinking of.

1 Like
5

Thanks @Noino, I’ll merge their comment into this thread too.

6

I wish there was a mid-session way or a UX flow to load sites using a different security level than the current setting in the browser without having to close all other sites. For example, if a user reads a static site on the “safest” security level which links to one that uses anubis or cloudflare’s turnstile then the user would have to save the link somewhere other than the current session, then change the security level which forces a restart then paste that link or use a bookmarked link to get to that site.
In 14.5.3, you could start in “safest” and when you click on a site that requires JS, you could change to “Standard” or “Safer” then F5 for that site.
I trust that there are good reasons for the changes to UX, and I do not know what a solution to remedy the problem I have should look like. But the current release 14.5.4 breaks the UX of 14.5.3 and before of changing the security level before loading the site for the site to run at the security level.
Has anyone else noticed this? If so, what do you think?

7

I’ve just opened the following ticket in Gitlab to track this issue:

1 Like
8

quoting myself: “We could solve this by forcing a restart but that then becomes a pain point”

9

Hey @donuts

If it helps, I will provide and answer to your question:

For instance, when you would temporarily downgrade to Safer in the past, was this workaround exclusively to enable JavaScript on a temporarily basis? Or are there other reasons you would downgrade mid-session too?

My browsing habits reside higher towards the “safest” mode and I prefer to find JavaScript-free alternatives to services which typically require it, so I can not speak for all other “safest” users. However personally, the only time I will switch from “safest” to “safer” is to achieve the following:

  • 1: Solve a CAPTCHA - solving specifically Cloudflare Turnstile, or old versions of Anubis, as I showed in my original example. (solve it, back to “safest”, reload.)

  • 2: Load a Video - Youtube or Odysee typically, traditional versions of these websites require JavaScript to operate, multiple videos (webpages loaded) may be played in succession after another, and therefore “safest” is kept on until my viewing is concluded.

  • 3: Read an Article/Forum Browsing - if the website requires JavaScript or cookies, I will temporarily switch.

  • 4: Access Webmail - some webmail providers (specifically Proton or Tutanota) require JavaScript to be enabled in order to sign in. “safer” would be retained until the end of checking emails.

After reading this, I realize the only time I would actually switch to “safer” is to indeed enable JavaScript in a semi-temporary manner. I will keep “safer” enabled for a range of just bypassing the CAPTCHA to potentially multiple different clicks or page loads in the case of videos with #2.

I think your idea of a temporary switch button of some sort to enable JavaScript is an amazing medium that strikes a balance between developer maintainability and user freedom, and believe this would be a good avenue to further explore.

I would still love to read more feedback from forum members and perhaps yourself as the issue develops to see if there are any additional situations I’m not considering where a Tor Browser user would require a switch to “safer” aside from the situations I mentioned.

Thank you for taking the time to read and understand my post, it’s greatly appreciated.

3 Likes
10

Thanks for the extra info @consciousness0, this type of feedback is honestly so useful to have (same goes to @Noino and @teres3).

As it would happen, a more advanced version of the feature I described above has been proposed in the past (see the issue linked below). Obviously the designs shown there would need to be modernized, however I’d be interested to hear from the browser developers what they think the technical challenges would be to develop a feature like this today.

11

Hello to everyone. I’m in an unstable emotional state after the update, and I’ll go straight to an example.I often download files from the bunkr site, it is highly likely to be malicious, but if you go through the preview stage and go to download in a new window, the direct download page is clean, download does not work without java script enabled. In the past, I’ve gone to the preview page at strict security level, and changed the settings to safer on the direct download page. Everything works well in reverse, from high to low, you don’t need a restart just to enable a java script, just to refresh a page, it worked fine for me. There are many examples where it is simply necessary to first login the site with the java script disabled and in certain places to enable it, I know what I’m doing, I just want to work on the internet safely. Do you think it will make my life better if I go everywhere with java script enabled and infect my computer with malicious code, because someone may not realize that if you go to a site initially with standard settings, changing the level of security will not add to your anonymity, and some of the changes won’t work without restarting? Make it possible in future updates to drop the security level from strict to lower without restarting, and leave the forced restart when changing it to a higher level. TOR was a handy tool in the past, and now it’s become useless to me.

1 Like
12

I really hope the devs work out a solution to the safest->safer being broken. For me, I like to go from standard->safest when clicking on links to external websites such as when I am reading an article which links to a reference.that I want to check out.
In general, I think forcing the restart while trying to enforce good usage patterns actually breaks existing user workflows. I don’t know how “dangerous” mid-session security level changes were or how they impact fingerprinting, but whatever comes out of this discussion, I hope that the devs can communicate to simple users like me what the problem was and what a solution could be to that problem and the one we have now.

1 Like
13

Thank you for opening this issue consciousness0 I also have problem with the new SecurityLevel Behavior in Tor Browser 14.5.4

@donuts And thank you for relaying this issue to gitlab.

Sorry for my late feedback here But I think UX Team really need to revert the change back to previous version as soon as possible.

In Tor Browser 14.5.4, changing security level will automatic restart Tor Browser without my consent. It causes me losing all the tabs I opened. And the worst part is that it will disconnect my current bridge.

I think this is really a BAD decision, and please revert it. Here are my reason:

The First reason is that censored users have to use bridges, But This change in Tor Browser 14.5.4 disconnects bridges every time whenever the security level is changed. Which is really really bad. Normally It already takes a considerate amount of time to successfully connect a bridge and i think always reconnecting bridges will potentially alert the censor which will jeopardize personal security that potentially leading to cause physical harm to censored users. It might sounds exaggerating to some but State Surveillance is a real thing and I hope whoever made this change would understand it.

The second reason is that this kind of change actually breaks security in web browsing itself as others have mentioned.

The Third reason is that the statement is untrue in the following link

Quote:

When users change Tor Browser’s Security Level (i.e. Standard, Safer, Safest), the new settings will only be applied on the browser’s next section, however, this isn’t let clear. Consequently, it’s possible that a user changes the Security Level from Standard to Safer, for example, but keep browsing with Standard settings without knowing that they need to restart Tor Browser to apply the changes.

No you don’t have to RESTART the Tor Browser to apply the change. In previous versions there are 2 options to apply the change:

1: Refreshing the tab will apply the change in security level

2: If you don’t need to keep the opened taps, Resetting your identify can also apply the change of security fast.

Neither option would disconnect bridge connection and they worked fine.

I think the change made in Tor Browser 14.5.4 regarding security level is utterly unnecessary and very counterproductive, It also post security risk for censored user even in physical term.

My suggestion is just revert this change, And if you worry that users don’t know that they need to refresh page or reset identify to apply the change of security level (which I highly doubt that most users don’t know this already and I honestly don’t know from where the UX team get this notion), you can just add a notice/warning message in the security level option: for example:

Security

Security Level

Disable certain web features that can be used to attack your security and anonymity. Learn more (Add the warning after this) To apply the security level changes, you need to refresh web page or reset your identify.

And lastly on the side note I am concerned that it seems that tor browser UX team has been trying to move people towards more automated configurations lately and make users have less choice or consent. I find this trend and mindset really worrisome. Please let users make their own choices, As a censored user myself who already don’t have much choices I find this kind of borderline “It’s For Your Own Good” mindset very irritating and wanting.

Thank tor project devs for your hard works.

3 Likes
14

In my opinion, the fact that so many people in this thread thought the change was fully applied upon refreshing the page does kind of confirm the need for this forced-restart to exist. Who knows how many people were regularly defeating the browser’s anti-fingerprinting before unknowingly.

I wonder if the Tor team needs to make it more clear when the security slider should/shouldn’t be used in the first place, because it sounds like many who have issues with this new design would be better served by just using Standard or Safer generally.

2 Likes
15

It a security level change where some prefs changes, for security, require a restart. This is not about fingerprinting, which continues to be first-in-class

16

:+1: I was only referring to Solve security slider (maybe remove safer) (#42572) · Issues · The Tor Project / Applications / Tor Browser · GitLab:

Your other idea about enabling some of this functionality people are looking for through per-site NoScript settings instead of the global slider does seem to make the most sense…

1 Like
17

Yes, it creates an extra bucket - but this hardly compromises fingerprinting where literally hundreds of other metrics are protected

18

The solution here is very simple for the user case of switching between Safest and Safer.

Restarts should only be forced when actually required. The security level does not determine this - e.g. “if you move to safer you must restart” is not always true

What determines it is if there is a state of change required from the startup settings - and by that I mean the three prefs - and of course moving to Safest never requires a restart (those 3 prefs relate to JS)

To explain…

  • we start up in Safer (the three prefs are disabled)
  • we move to Safest (no restart required, there is no JS)
  • we move back to Safer (no restart required, the prefs are still in their startup state of disabled - they were not changed, a restart is not required!!)
  • we move to Standard (the three prefs change state from our startup values to enabled = restart required)
  • etc

Tho To make Safer-Safest always identical, ie startup in either and toggle between the two, Safest just needs to also enforce those three prefs the same as Safer so there is never a change from startup pref values. This would be a common workflow (Safest ↔ Safer)

There will always be a change between Safer ↔ Standard

tl;dr: There are only two states that matters: the 3 prefs (binary outcome; they are all on or all off) either match or don’t match their startup values. This is not about three security levels and IDK why it’s being done like that. Since there are only two states that matter, then 2 of the 3 security levels can be identical. This is simple math. Since Safer and Standard cannot be the same, then it’s a no brainer to make JS (edit: need coffee) Safer+Safest identical (i.e regards those 3 prefs) and that removes the restart between them if you start in either of them

1 Like
19

Introduction:

Hello everyone, this post has been in the works for a long time. I am making this post to:
  • Consolidate everything that has happened over the lifetime of this thread.
  • Bring new users and busy developers up to speed on the issue.
  • Provide workarounds for the changes covered in “Summarized Timeline”. (not recommended)

After quietly observing what others have said about this issue, I have realized that everyone, regardless of if they are for or against a change to the 14.5.4 security level, has a fair point and raises valid concerns. As a result, I think that solutions which make the largest amount of users happy from both a usability and security standpoint while being the most simple to implement are the best to focus on currently.

This post is also meant to be the beginning of pivoting the focus of this thread to move from describing problems to discussing potential solutions and working out which one would be good. I might be too early, but I think this is where others would like to take it also.

Unfortunately, I’m in the dark as to if one of the solutions listed in this thread was favored by the developers or not, at the time of this post the Gitlab issue is marked as “To do” and I don’t know if there was any internal discussions or not.

Summarized Timeline:

Changes were made to the SecurityLevel module starting in Tor Browser version 14.5.4. The major changes which affect users are the locking of the security state of Tor Browser upon starting it, and changing the security setting requires a restart for the browser.

This change is beneficial to users as the Tor Browser seemed to not entirely change all security parameters when switching security modes. A restart makes sure all security parameters are properly set. If you would like to replicate what @jonah’s covered, jonah’s article about this issue is at: https://www.privacyguides.org/articles/2025/05/02/tor-security-slider-flaw/.

Problems:

The current Gitlab issue for this post is Gitlab issue 43922.

Functionality Problems:

Most functionality problems reported in this thread by users revolve around not being able to temporarily enable JavaScript, the situations described so far are as such:

JS Related Issues:

  • Can’t solve CAPTCHAS requiring JavaScript.
  • Can’t load or download media elements or webpages which require JavaScript.
  • Can’t log into services like webmail which require JavaScript.

Non-JS Related Issues:

  • Changing security level requires reconnecting to a bridge as mentioned by @Radar451.
  • Changing security level removes current tabs & cookies from the session.

Solutions:

The solutions outlined in this section will be presented in the order they were suggested. If new solutions are suggested after this reply is posted, a moderator is free to append to this section.

Solution #0:

Do nothing. Leave the changes as they are now in 14.5.4 and up, and see what happens.

Pros: No developer changes required, people who like the 14.5.4 changes are happy.

Cons: people who depend on the functionality of the pre-14.5.4 security style will need to adapt using the new changes or resort to the unconventional and not recommended methods described in “Workaround of 14.5.4 changes (Not Recommended)”

Solution #1:

Adding a button under the security level change box to either lock or unlock the ability to change the security settings inside of a single session. This was outlined in the initial post for this thread under “Graphical Depiction”.

Pros: Feature’s potential harms are clearly described, feature is easy to understand, grants user desired freedom or desired security if they so choose.

Cons: Would require 2 separate interfaces which is inefficient for developer upkeep - as mentioned by @donuts and could potentially lead to Browser vulnerabilities or fingerprinting issues in the future. Feature could potentially result in mid-session security level change issues.

Solution #2:

Add a button for ‘Safest’ users to temporarily enable JavaScript for a single webpage or multiple page loads.

Pros: Should be more simple to implement than solution #1 and should not result in fingerprinting or mid-session security change issues.

Cons: Feature is not as expanded or in-depth as solution #3.

Solution #3:

Implement per-site security settings.

Pros: would allow the user to individually control many different aspects of each site they visit, including enable or disable JavaScript as they choose.

Cons: Very hard to implement compared to solution #1 or #2 as mentioned by @thorin in the Gitlab issue: Safest users can no longer downgrade mid-session to temporarily enable JS (#43922) · Issues · The Tor Project / Applications / Tor Browser · GitLab

Workaround of 14.5.4 changes: (Not Recommended)

-Warning-

Venturing into about:config is not recommended and can potentially result in atypical or dangerous browser behavior with regards to anonymity, security, or fingerprinting.

Remember that I am giving you these methods as a random person on the internet who should not be inherently trusted and lacks the in-depth knowledge of a developer with regards to how changing these switches in about:config could negatively affect you. Please be smart and cautious, do not follow a circumvention blindly if you decide to do so.

Working Around SecurityLevel Changes:

This section describes how users who depend on the before 14.5.4 functionality could potentially work around these recent changes to continue to use Tor Browser how they need to.

Method #1 (toggling "javascript.enabled"):

This method retains tabs and cookies, but is the least secure and most finger-printable option you can use.

  • start the browser in ‘Safer’ mode.
  • venture into about:config
  • search for “javascript.enabled” and switch it to false (this should load new sites with JavaScript Disabled).
  • test to make sure JavaScript is disabled using something like EFF’s CYT (All JS-Derived Characteristics should read “No JavaScript” except for User agent and HTTP headers)
  • If you need JavaScript on a certain tab, switch “javascript.enabled” to true and refresh the target tab (this now makes JavaScript available to either all tabs or just the tab you refresh, I’m not completely sure, assume every tab now can execute JavaScript and prepare accordingly if you desire.)
  • Do what you need inside of the JS-enabled tab. (pass CAPTCHA for example)
  • Switch “javascript.enabled” back to false and refresh all tabs.

This procedure would be repeated as necessary by the user.

Method #2 ("changing browser.security_level.security_slider"):

Change the “browser.security_level.security_slider” setting, (this flag may still prompt a restart upon changing) as was explained by @Noino and also isn’t generally recommended.

Keeping Tabs when Requiring JS Without Needing about:config:

This option is more secure and less finger-printable than the toggling option, however it only retains tab history and not cookies.

If you would like to stay in ‘Safest’ mode and properly switch to ‘Safer’ mode for a specific tab using the button and would like to keep your tab history (not cookies, they get wiped), the most simple way while keeping things within the browser would be:

  • bookmark your tabs in the ‘Safest’ session.
  • restart to ‘Safer’ or ‘Standard’.
  • load the specific tab you need, do what you need with it.
  • switch back to ‘Safest’ mode and load your tabs from bookmarks.
  • delete bookmarks.

repeat as necessary.

If you don’t want to use bookmarks, copying tab links into a text editor is an option (although also not recommended, make sure it doesn’t make a temporary swapfile or connect to the internet).

Conclusion & Keeping my Writing Accountable:

I am prone to making minor context mistakes when referencing security modes. For example, I may say ‘Safer’ in a context when I meant ‘Safest’, like I did in my first post as was mentioned by kasia here for your reference (thank you for pointing this out!)

English is my second language and I still have trouble with it sometimes. If you find any context issues concerning my post that are very serious, let me know before I lose access to editing the post and I’ll strike out the mistake and fix it or maybe a moderator can fix it after if I confirm that it’s an issue in a subsequent reply or personal email.

Thanks to everyone for being cooperative and trying to work towards a solution, hopefully we can decide on something that helps everyone out. I will continue to check on the thread semi-frequently.

Finally, if you’re a moderator (donuts specifically) and you believe this post is cluttering up the thread and provides no serious benefit to it regarding consolidation or solution, remove it or don’t let it through. I understand.

2 Likes