TorBrowser's NoScript is breaking other addon

Ask for help about NoScript, no registration needed to post
alreadyasked

TorBrowser's NoScript is breaking other addon

Post by alreadyasked »

I've already asked for help at Tor, but they don't care so I am asking here.

Tor Browser is including NoScript, your addon, and it's breaking other add-on's functionality.

To reproduce:
1. Download latest Tor Browser from the Tor project(7.5).
2. Go to https://trac.torproject.org/projects/tor/ticket/24943 and download a ZIP file in description.
3. Extract the zip.
4. In Tor browser, open about:addon, Gear, Debug add-on.
5. "Load temporary add-on", select "local/manifest.json" to load this test add-on.
6. Try to save something. When you click Save, it clear everything.

The problem will go away if you disable NoScript in Tor Browser.
Can you do something about this? Other addons on AMO which use browser.storage.local is suffering by this.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
barbaz
Senior Member
Posts: 10834
Joined: Sat Aug 03, 2013 5:45 pm

Re: TorBrowser's NoScript is breaking other addon

Post by barbaz »

Do you have moz-extension: in your NoScript whitelist? It is supposed to be mandatory (i.e. greyed out in the whitelist & you can't remove it) for exactly this reason.
*Always* check the changelogs BEFORE updating that important software!
-
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

I didn't modify anything. Just downloaded a fresh Tor Browser.
All I changed is setting a "High" level in TorButton.

Besides why the user have to do something in order to use other people's addon?
Breaking other addon is not acceptable.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

barbaz wrote:Do you have moz-extension: in your NoScript whitelist? It is supposed to be mandatory (i.e. greyed out in the whitelist & you can't remove it) for exactly this reason.
Yes there is, and it's gray.

So what now?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
barbaz
Senior Member
Posts: 10834
Joined: Sat Aug 03, 2013 5:45 pm

Re: TorBrowser's NoScript is breaking other addon

Post by barbaz »

Guest wrote:Besides why the user have to do something in order to use other people's addon?
Breaking other addon is not acceptable.
I agree with you.
Guest wrote:So what now?
I think this is likely a Tor browser specific issue. I don't know Tor browser at all, so I probably can't help more, sorry.

Giorgio, do you know if Tor browser does anything to NoScript that could prevent NS from properly applying its whitelist?
*Always* check the changelogs BEFORE updating that important software!
-
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

Re: TorBrowser's NoScript is breaking other addon

Post by Pansa »

Guest wrote:I didn't modify anything. Just downloaded a fresh Tor Browser.
All I changed is setting a "High" level in TorButton.

I'm guessing you are going by Cypherpunks over there?
Maybe if you had a less "agressive" tone, that would work better?

If Tor is not supposed to do certain things, because it is a risk, and you even choose to run it on "high", that might prevent foreign unkown things to run.
They provide a specific bundle to work in a specific way, and if you want something different, then maybe they don't agree with opening a Layer-8 vulnerability by default.
Besides why the user have to do something in order to use other people's addon?
Breaking other addon is not acceptable.
Because maybe the user wants something that isn't supposed to be allowed by default.

In a sense that is like arguing that Noscript shouldn't by default block scripts, "break" pages and require the user to do something to view other people's webpages.
Is that sensible?

I mean I hope there is a workaround for you to get what you want, but acting like a browser-bundle focused around security is completely "off base" in enforcing that (for instance) unknown things don't get to write to a file/filesystem in that manner is maybe a bit "demanding".
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

Pansa wrote: I'm guessing you are going by Cypherpunks over there?
Maybe if you had a less "agressive" tone, that would work better?
OK look, I'm tired of not receiving any help. That's why I wrote this here.
I will leave if you felt annoyed by this. Sorry about this.
Pansa wrote: If Tor is not supposed to do certain things, because it is a risk, and you even choose to run it on "high", that might prevent foreign unkown things to run.
Are you working at Tor? I already know that and I know what I am installing add-on X.
Pansa wrote: Because maybe the user wants something that isn't supposed to be allowed by default.
If this is true, then they must add a code to stop downloading ANY addon from mozilla add-on page.
Pansa wrote: In a sense that is like arguing that Noscript shouldn't by default block scripts, "break" pages and require the user to do something to view other people's webpages.
Is that sensible?
You're misleading because I'm not talking about websites' script. This is about Add-ons.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

Pansa wrote:
Guest wrote:I didn't modify anything. Just downloaded a fresh Tor Browser.
All I changed is setting a "High" level in TorButton.

I'm guessing you are going by Cypherpunks over there?
Maybe if you had a less "agressive" tone, that would work better?

If Tor is not supposed to do certain things, because it is a risk, and you even choose to run it on "high", that might prevent foreign unkown things to run.
They provide a specific bundle to work in a specific way, and if you want something different, then maybe they don't agree with opening a Layer-8 vulnerability by default.
Besides why the user have to do something in order to use other people's addon?
Breaking other addon is not acceptable.
Because maybe the user wants something that isn't supposed to be allowed by default.

In a sense that is like arguing that Noscript shouldn't by default block scripts, "break" pages and require the user to do something to view other people's webpages.
Is that sensible?

I mean I hope there is a workaround for you to get what you want, but acting like a browser-bundle focused around security is completely "off base" in enforcing that (for instance) unknown things don't get to write to a file/filesystem in that manner is maybe a bit "demanding".

Here's an example.

User X downloaded add-on A from mozilla page.
It didn't work on Tor Browser because of this bug.

X wrote a 1-star review on AMO, saying this addon didn't work.

Tor Browser is based on Mozilla Firefox, and your add-on is completely breaking the add-on.
Can't you call this a bug?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

Pansa wrote: Is that sensible?
Okay you helped me.
https://trac.torproject.org/projects/tor/ticket/25018
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

Re: TorBrowser's NoScript is breaking other addon

Post by Pansa »

Guest wrote:
Pansa wrote: In a sense that is like arguing that Noscript shouldn't by default block scripts, "break" pages and require the user to do something to view other people's webpages.
Is that sensible?
You're misleading because I'm not talking about websites' script. This is about Add-ons.
I was talking about security standards in general, and then gave an analogy.
Your point was that regardless of a security default of a security software, if you want to do something, that should be the standard, so that nothing is preventing you to do what you want without user interaction.

It works for any context.
If a firewall doesn't allow incoming connection by default, but you want to run a server, the default should be to allow servers without user interaction instead of breaking the ability to connect, regardless of whether that is less secure.
If No script blocks scripts by default, but you want a website to run, the default should be to allow scripts, because otherwise it breaks the website for you, requiring user interaction.
If Tor blocks writing to the file system by default, breaking the saving of settings in not included addons, the default should be not doing that, because it requires user interaction to get what you want.
Are you working at Tor? I already know that and I know what I am installing add-on X.

If this is true, then they must add a code to stop downloading ANY addon from mozilla add-on page.
A) No, and I don't think I acted like I did.
B) That is marvellous that you know what you want to install, but that doesn't change anything about a "default" position a provider might implement.
C) If Tor only blocks specific access to the file system, seeing that as vulnerability, they wouldn't block ALL addons, just the ones that want to write their config in a specific way.
User X downloaded add-on A from mozilla page.
It didn't work on Tor Browser because of this bug.

X wrote a 1-star review on AMO, saying this addon didn't work.

Tor Browser is based on Mozilla Firefox, and your add-on is completely breaking the add-on.
Can't you call this a bug?
If an addon requires features that are disabled in a security focused browser, because that feature is evaluated as security risk, then it not working in said browser is not a bug, but a incompatibility based on divergent visions of security.
I agree with you that said browser should have a feature to disable this security feature at their own risk (or make an exception), but that has to be implemented by requiring user interaction.
The base position that no software should have any security standards (by default), because it might prevent a user from automatically doing something that specifically is seen as risky, or else call it a bug is in my opinion untenable.

And btw your example user is quite frankly not a reasonable person, with unhealthy expectations, and the exaggerated ego to back it up.

And may I add that I think you have a flawed perspective on "open source"? Just because Tor is built on Firefox doesn't mean it should behave EXACTLY like FF. If it did, there'd be no point for the fork. Tor exists because of people NOT wanting it to behave exactly like Firefox; just in this instance you'd prefer it to, and their default position is that what you'd expect to work only works if they allow a security risk by default.
OK look, I'm tired of not receiving any help. That's why I wrote this here.
I will leave if you felt annoyed by this. Sorry about this.
But you aren't asking for help, exactly.
You are demanding a fix to a supposed failure on someone's part, and insisting on them being wrong, before they get to address the issue.
That is a huge difference.

You don't have to leave, I hope someone knows/finds a workaround to allowing you to run the addon.
But you have to be open to the idea that how it works by default is not "wrong", it is just not what you want.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

> And btw your example user is quite frankly not a reasonable person, with unhealthy expectations, and the exaggerated ego to back it up.

Actually this happened on MY addon I developed last year.
It's 100% WebExtensions, can work with 52+, and available on mozilla site with 1000+ users.
(I don't say which one for the sake of anomity)

He asked me to "fix" the add-on because I use 'storage.local' API and Tor Browser
clearly flush the form each time the user tried to save the config.

I told him it's not my fault because I use plain vanilla API and asked him to talk about this on Tor forum.
Result? One star. "Not Working".

Give me a break.

Seriously though, when I tried Tor Browser for the first time I thought 'WTF'.
My code is not a problem but yours, because as I wrote above, any add-ons including
mine work exactly AFTER I disabled your NoScript addon.


If Tor Browser really blocking the add-on, any attempt to install the addon should fail
with or without NoScript. This is clearly NoScript problem.


Georg, Admin, or whatever. Someone say something already.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Guest

Re: TorBrowser's NoScript is breaking other addon

Post by Guest »

It's okay to ignore, but many add-on developers will suffer 1-star review - "NOT WORKING".
I know some Tor users using uBlock or other 'add-ons'.

You also can try to convince Tor Browser to forbid installation of any Firefox add-on from any source, including file://.

That's all. I just hope I don't get another 1-star related to this bug.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
MacLover

Re: TorBrowser's NoScript is breaking other addon

Post by MacLover »

Hello, I can confirm this issue too. I have updated my TBB to 7,5 and all other add-ons stopped working.
I've disabled NoScript and installed uMatix for script blocking. 7,5's NoScript bought me a headache.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
MacLover

Re: TorBrowser's NoScript is breaking other addon

Post by MacLover »

Hillarious.

If only if you scroll down a bit, you should realize this is YOUR problem.

https://addons.mozilla.org/en-US/firefox/addon/noscript/reviews/1040126/ wrote: It's a Tor Browser issue, why are you doing this?

This is not even a NoScript bug, but a Tor Browser one, see
https://trac.torproject.org/projects/to ... #comment:2

And it's been reported less than 3 days ago, what's exactly your standard for bug fixing times in a project like Tor?
Last edited by barbaz on Sat Jan 27, 2018 4:31 am, edited 1 time in total.
Reason: Add source for the quote
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Post Reply