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.