Restore NoScript control widget icon to the Tor Browser toolbar
Background:
In Tor Browser 8.5, the NoScript control widget icon that previously (in 8.0.9) was in the toolbar has disappeared.
It can manually be re-added by right-clicking the toolbar, selecting "Customize..." and dragging the NoScript icon back to the toolbar.
Even in "Standard" security mode, many websites break without fiddling with permissions in the NoScript widget. In "Safest" security mode, nearly all websites break without (sometimes substantial) fiddling with permissions in the NoScript widget.
Why this is a problem:
The user story for re-enabling the NoScript widget in the toolbar is so obscure that it is unlikely more than, say, 10% of the user base will understand how to do so.
What's more, without a big red icon to click, many users will not understand why a website breaks, and will simply abandon Tor Browser; they won't understand that they should fiddle with the toolbar and add the NoScript widget so they can fiddle with script permissions.
Finally, some users who previously used "Safest" security mode will not understand why their old flow is broken, and will resort to browsing on "Standard" mode, reducing the overall practical level of security.
Call to action:
The NoScript widget icon should be re-added to the Tor Browser toolbar by default.
I would also appreciate a pointer to the list archives or other documentation of how this change came to be in the first place.
Activity
Replying to cypherpunks:
Even in "Standard" security mode, many websites break without fiddling with permissions in the NoScript widget.
Do you have evidence for that? What does "break" here mean, given that NoScript's settings are basically not active at all at that level as we don't block any content on "standard" (anymore). Either way, the solution to such issues is not messing with NoScript but fixing the underlying issue in the browser. NoScript is just in Tor Browser to provide higher security levels.
That said, no, NoScript won't come back by default onto the toolbar but you are of course free to add it back yourself. That's been a conscious decision and as mentioned on our blog ther is an underlying proposal (https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt) which has been discussed on the tbb-dev mailing list for a while (see: https://lists.torproject.org/pipermail/tbb-dev/2018-February/000756.html for the start).
There is still a piece missing, the exposing of per-site settings in the UI, which is tracked in https://trac.torproject.org/projects/tor/ticket/30570. We hope to get soon to it.
Trac:
Resolution: N/A to wontfix
Status: new to closedOK, I see. I wasn't paying close attention and missed proposal 101.
Do you have evidence for that? What does "break" here mean, given that NoScript's settings are basically not active at all at that level as we don't block any content on "standard" (anymore).
I wasn't aware of changes in content blocking policy in "standard" mode. The impetus to posting this bug was actually a visit to https://www.starlink.com, which does not render in "standard" mode without fiddling with per-site permissions in NoScript. Perhaps this behavior is now generally better and such fiddling is less necessary in "standard" mode--but it remains necessary.
There is still a piece missing, the exposing of per-site settings in the UI, which is tracked in https://trac.torproject.org/projects/tor/ticket/30570. We hope to get soon to it.
This is the bigger issue. You pushed out an update to the toolbar UI when this proposal is not ready. This update broke an essential part of the workflow for "safest" mode, and at least until recently a usually-essential part of the "standard" mode workflow.
I am posting here, so I'm sure you won't question that I am a longtime Tor Browser user. This update broke my workflow. I had to revert to "standard" mode--which, again, quickly broke on starlink.com--because I could not figure out how to get my NoScript widget back. It took me, once I had spare time, about 10 minutes of exploring and fiddling until I figured out how to get it back, so my workflow wasn't totally broken.
Forget the issues with "standard" mode. For all your "safest" mode users, their workflow is now totally fucked, with no clear instruction or UI path to re-enabling that essential functionality. Would you have pushed out an 8.5 that completely removed "safest" mode? That's more or less the result of this update for a lot of users. I support proposal 101. It's a good idea. This sudden UI change was definitely premature. Please restore NoScript to the toolbar until the proper UI for per-site permissions is ready.
Trac:
Status: closed to reopened
Resolution: wontfix to N/AHere's another page that doesn't render in "standard" mode and requires permissions fiddling in the NoScript widget: https://www.nasa.gov/feature/goddard/2019/nasa-set-to-demonstrate-x-ray-communications-in-space
Hi, different cyberpunks here than parent in this thread. I posted a similar issue the other day but I think it may be more useful to just comment here?
I'd like to point out it's unclear whether adding custom icons reduces anonymity. (Either through the usual weird fingerprinting exploits - can someone programmatically detect url bar length? That's an open question.
Forcing us to add the icon back (and some people may put said icon in different places) is risky. Especially since people who are advanced enough to use safest probably have increased risks if fingerprinted or deanonymized.
Ex: if someone shares a screenshot it's something that makes them unique. (Ex: user collects something via Tor, shares with reporter, reporter shares screenshot, oppressive government notices both the leaked screenshots and the user's TBB setup have the icon placed to the left of the onion, whereas the other suspects either have no icon or have it in a different spot)
Also, if you right click then click "noscript" that menu only comes up if the button is in the toolbar.
Anyone who visits a social website may not want to use the "safer" security slider.
For example I maintain an anonymous social media account on a site with many external links - I do not trust every random thing linked to on the social media site, and strongly prefer to leave my browser on "safest" but allow only that site's JS, not everything it links to. I suspect there are many similar use cases where 1 site is trusted, but not the sites that may be linked to.
If the developers are deadset on removing the icon, I think at least we should be able to access that functionality via the right click menu as a compromise,.
I think it's reasonable to ask that either the control be present for safest users, or that the right click context menu work for advanced users if clutter is the concern.
(Test for yourself on this page. Right click, then click "noscript". If there is no button in your toolbar, nothing appears)
Trac:
Username: cyberpunks-
Replying to cypherpunks:
Here's another page that doesn't render in "standard" mode and requires permissions fiddling in the NoScript widget: https://www.nasa.gov/feature/goddard/2019/nasa-set-to-demonstrate-x-ray-communications-in-space
What permissions do you still need to adjust for that website in Tor Browser 8.5 (and probably on https://www.starlink.com/, too) in standard mode (not safer, nor safest)?
What permissions do you still need to adjust for that website in Tor Browser 8.5 (and probably on https://www.starlink.com/, too)
Why don't you visit these sites and find out?
FWIW, there are other sites which still partially or completely break in "standard" mode, but disclosing these sites might unacceptably reduce the size of my anonymity set.
Serious question: Do you ever actually use Tor Browser?
in standard mode (not safer, nor safest)?
I made very clear I was talking about these sites breaking in "standard" mode and was scrupulous in my usage of "standard" and "safest". Either your reading comprehension skills are worse than my interpersonal skills, or you're a fucking asshole.
-
It's sad that folks think they need to resort to ad hominem attacks, but that's not the level of interaction we think is appropriate. Please leave this ticket closed, otherwise I'll just ignore it like all the other ones where some cypherpunk thought they should just ignore my requests of leaving the tickets closed.
Trac:
Status: reopened to closed
Resolution: N/A to wontfix OK, Georg. It's really a pity. This is a serious technical mistake and the TBB userbase is suffering for it. I am reopening the ticket with the commitment that I am done commenting here. I will leave it to others, like cyberpunk above, to attempt to convince you of the error.
Trac:
Resolution: wontfix to N/A
Status: closed to reopenedReplying to gk:
It's sad that folks think they need to resort to ad hominem attacks, but that's not the level of interaction we think is appropriate. Please leave this ticket closed, otherwise I'll just ignore it like all the other ones where some cypherpunk thought they should just ignore my requests of leaving the tickets closed.
Excuse me, I made a comment earlier (comment 4) and am a different user of the nym.
Please don't ignore my polite post just because someone else used a bad word later in the thread.
It's frustrating to try to contribute to an open source project and told "well, someone else on the thread annoyed me, so your feedback will be ignored".
-
Replying to cypherpunks:
Replying to gk:
It's sad that folks think they need to resort to ad hominem attacks, but that's not the level of interaction we think is appropriate. Please leave this ticket closed, otherwise I'll just ignore it like all the other ones where some cypherpunk thought they should just ignore my requests of leaving the tickets closed.
Excuse me, I made a comment earlier (comment 4) and am a different user of the nym.
Please don't ignore my polite post just because someone else used a bad word later in the thread.
It's frustrating to try to contribute to an open source project and told "well, someone else on the thread annoyed me, so your feedback will be ignored".
I think nobody intended to ignore your feedback. If that's your impression then I am sorry for that.
-
Unfortunately, the 101 Redesign document referred to above https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt has not been followed.
As a result I created this ticket (in error): https://trac.torproject.org/projects/tor/ticket/31096
It seems that another ticket has been created regarding re-instating per site permission (aka NoScript). In the ticket I have outlined how the 101 Re-design document has not been followed and some UI suggestions: https://trac.torproject.org/projects/tor/ticket/30570
The ticket has a sponsor. I suggest we keep a level head and continue any discussions in the above ticket.
Trac:
Username: torlove -
Replying to torlove:
Unfortunately, the 101 Redesign document referred to above https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt has not been followed.
As a result I created this ticket (in error): https://trac.torproject.org/projects/tor/ticket/31096
It seems that another ticket has been created regarding re-instating per site permission (aka NoScript). In the ticket I have outlined how the 101 Re-design document has not been followed and some UI suggestions: https://trac.torproject.org/projects/tor/ticket/30570
The ticket has a sponsor. I suggest we keep a level head and continue any discussions in the above ticket.
Sounds good. Let's try closing this ticket again.
Trac:
Status: reopened to closed
Resolution: N/A to wontfix