|User since||June 16, 2010|
|Number of add-ons developed||0 add-ons|
|Average rating of developer's add-ons||Not yet rated|
Java? Why it there no information given about recent Java security concerns? Rated 2 out of 5 stars
Quiz: How many users do read the update notes each time BEFORE they let Firefox update their add-on installations?
You might ask why I am asking this question. It is about something that is known as “social engineering” …
I think of AMO automated updates that this feature shall bring me versions of well-known and familiar add-ons. If an add-on is not functional after such update, quick ‘repair’ is what we all want, if we are frequently using such item.
Fast ‘up and running again’ in your case means reading your instructions, installing an additional (!) component which is NOT hosted at AMO (why?) and it makes use of Java … Java?
Wait a minute! Weren’t there security bulletins recently about why and how to disable Java because of serious security problems including that these possible attack vectors are frequently used by malware which have already let to successful attacks even against well-known businesses?
So while your efforts to deliver useful add-on-functionality might be worth 5 stars ...
Java engine developers seem at this time to be in something that might be looked at something like a continuous flow of fixing security holes. Currently security experts advice users to disable Java plugins FOR ALL BROWSERS or even to uninstall Java completely.
By the design of AMO automated updates for Firefox add-ons there is no dialog which informs me beforehand that a new version suddenly needs additional software installed to be functional.
Especially because of Firefox fast paced version renumbering there are quite frequently version compatibility updates for add-ons which leads quite often to new add-on versions … (which may be a reason not to read every and each add-on update note?).
Now there is one new “version” of an add-on which is not functional right of the box. In my opinion a new version being delivered via auto-update should not need user intervention to be functional via this path (this means inconvenience). New requirements in my opinion might be better suited on a new add-on page of AMO e.g.?
More seriously about this special update here is that users are asked to install a non AMO hosted add-on and to make use of Java which at first glance seem to be contradicting concurrent security advices.
So you want users to install or activate Java functionality in conjunction with browsers (at first glance) against the advice of security experts, at least without giving information to users about the current presence of known and important security concerns about Java? And there are no statements about whether the Java plugin for Mozilla browser has to be activated in order to give Java functionality to your add-ons. Well, this might be worth 2 stars?
It might be looked at as negligence when you are not giving instructions on how users have to secure their Java installation or without giving them links to well established security sites where there is this type of instruction for everyone (everyone should really disable Java plugins and do so centrally).
What bothers me much more is that there is an automated update which may bring users to install Java without being aware of the serious security problems which they might encounter because Java browser plugins are not disabled by default (which might even be contra productive for your add-ons?). And the process of how to disable really all means by which Java plugins might be activated is not just a one-click operation. So the common user might not only gain new functionality but also ‘gain’ already well known security problems?
Above I mentioned “social engineering”. You might have decided to deliver your whole new functionality as a new add-on on AMO (for which you could have placed ads e.g. by delivering a updated add-on icon as new version feature of your ‘legacy’ add-on and show users this ad after post-update browser restart). An inconvenience for you but a way to do it secure by default?
Users who are simply following your instruction might end up with non-deactivated Java browser plugins which may expose them to serious security problems? (And who does disable Java plugin ends up with non-functional add-ons of yours?)
Because I am not able to foresee possible ‘side effects’ which may be caused by using Java together with fresh (unknown, new) non AMO hosted add-ons I will stay with version 3.3.2. ("legacy").
I need exactly one thing for privacy software: TRUST. Rated 1 out of 5 stars
And TRUST is what do not have for those who forced a beta software through TACO's update channel onto my machine.
That's why I downgraded to Version 2 of TACO. I used the REAL TACO V2 from Mozilla's version history at addons.mozilla.org/en/firefox/addons/versions/11073.
To Abite employees: Please try to be mature and responsible, stop being adolescent by hiding your work behind the trusted TACO add-on, draw back your beta software from TACO's add-on-page and resubmit it your experimental software as new, experimental add-on with its own name. This is what you could have done, you even may earn your own merits that way. By the way: Mozilla's add-on system is all about adding bits of functionality one by one, a cluster of "suite" functionality is exactly what Mozilla's add-on functionality is NOT all about.
And if you add a suite, then it should be mature one. A natural way of beta testing your "privacy" software functionalities could e.g. be to spread your modules over different add-ons and give users the chance to try them individually - and after making each individual module you can put together your the trusted modules into one single supra add-on; with one great advantage over crash attempt we have to suffer from now: as users with trust in you they would have given you another chance ...
Users of TACO: You may stay happy with V2 of TACO from the above mentioned url (Mozilla version history of TACO), as I did. I downgrading to V2 of the untouched TACO version. If you e.g. MR TECH's Toolkit add-on installed, like me, you may opt to disable the update check for 'TACO' alone. This way the browser will simply not check for updates of that single add-on TACO anymore.
Perhaps this is not what those talkactive ('chat with us!...') "Abite" people want us to do, but none of us has spoiled the trust of those masses who possibly could have grown from happy users to a informed and listening set of customers.