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.
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.
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
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.
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.
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?
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.
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.
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.
