[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9387 [Tor Launcher]: Tor Launcher/Torbutton should provide a "Security Slider"
#9387: Tor Launcher/Torbutton should provide a "Security Slider"
-------------------------+-------------------------------------------------
Reporter: | Owner: gk
mikeperry | Status: new
Type: | Milestone:
enhancement | Version:
Priority: major | Keywords: TorBrowserTeam201502, tbb-security,
Component: Tor | tbb-usability, tbb-linkability, tbb-3.0,
Launcher | extdev-interview, tbb-isec-report,
Resolution: | tbb-4.5-alpha
Actual Points: | Parent ID:
Points: |
-------------------------+-------------------------------------------------
Comment (by mikeperry):
Replying to [comment:74 gk]:
> mikeperry: This is the comment to commit
7975b2023d5dc9bc0437cb5d5fbfe539448900e4: Originally, I had a similar idea
but just looking at the particular security level and binding the custom
pref to it is wrong I think. We need to think about the custom setting
being bound to the *whole* slider instead. And here is why: Level 4 (or
"high") is not only about setting the preferences in the High section in
comment:43 but rather all the preferences in Low-Medium/Low-Medium/High
must be set accordingly as well in order to guarantee the full protection
AND making sure there are only 4 partitions of users if they stick to the
slider and don't prefer custom settings. Or take the default mode: if one
selects the default mode but disables JavaScript then first of all this is
no default mode anymore even if no particular preference in that mode is
changed. Doing this is pretty dangerous as we could easily get some users
that are in default mode but have JavaScript disabled and some that are in
that mode but have it enabled. And then maybe some that have
media.audio.enabled and some not, leading to a much larger partition than
is good for our users.
>
> Hence just the check if any of the security slider related preferences
got touched. If so, AND we are not in custom mode, set the custom
checkbox. The only way to set it back currently is via the Torbutton menu.
We could think about an additional option: if the user manages it to
manually set all the security slider related preferences back to their
respective values (which is depending on the current slider level) then
uncheck the custom checkbox as well.
>
> Still guessing at the meaning of the comment a bit: `m_tb_sliderUpdate`
is only set if we set the slider level on the Torbutton dialog which is
only possible if the custom checkbox is unchecked. Thus, the reasoning was
if we get the notification AND `m_tb_sliderUpdate` is not set AND we are
not in custom mode we can just set it without checking the value of any
pref.
Well, the way I use the slider in the high position is as a default state.
I frequently temporarily allow many sites via NoScript, and sometimes if a
site needs to perform many redirects, I globally enable script permissions
for a bit, and then disable them later. I think it is this global script
enable that is causing my slider to get stuck in the "Custom" position.
So, in my opinion, this means two things:
1. I think that the slider should recognize that when I globally disable
scripts again, "Custom" should become unchecked. Really, I think this
should be the case for all of our prefs, but globally enabling/disabling
JS is facilitated by our NoScript UI (for good reason) and may be common.
1. I think the slider shouldn't actually become locked if "Custom" is set.
I should be able to drag it and go back to one of the official positions,
which would uncheck "Custom" and reset all the prefs appropriately.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9387#comment:76>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs