User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Extensions can read and write to the saved passwords file. (Tools -> options -> privacy -> saved passwords.) The Gmail notifer extension does this. I've not got the skills to do so, but couldn't an extension copy this data and send it back to a remote server? This of course wouldn't be detected by many firewalls as access has been granted to Firefox. If so, then there are two solutions. 1) All extensions submitted to UMO should be tested to see if they're phoning home. or 2) Extensions may only read from saved passwords which they create. Reproducible: Always Steps to Reproduce:

Fixing security group.

#1 is a non-starter, a truly malicious extension would find a way to evade whatever limited testing we could afford to do (wait 6 months to get maximum spread before doing any detectible evil?). Unless by "tested" you meant a code audit, but I'm not sure how much of that we could do in practice. Any extension that contains binary components would not be auditable. #2 is not possible with the current architecture. When chrome script is running we haven't kept track of where it has come from. We should definitely make #2 part of UMO policy though, as well as limits on what "phoning home" extensions can do. Or since some extensions must make server contacts to do what they do (WeatherFox, Google pagerank) I'd settle for clear disclosure to users of what network connections each extension initiates.

The ability of extensions to be able to read this information is, IMHO, an inherent problem with Firefox. The extension API should not allow that. Trying to push the burden of this work onto the UMO staff is just plain crazy because a) we can't keep up with the number of extensions and b) no matter how hard we try, somebody is bound to get _something_ through. We can definitely make #2 a policy but it will be extremely difficult to enforce until after the fact. Many of the developers already have their apps phone home. For example, some do it for an image in the extensions panel. This way they can gather statistics about how many people are using the application, etc. We can create a policy or even limit the applications that do this but if they *can* do it within the extension API, they *will* do it. We can ask that the developers disclose this information but again, its hard to enforce this until after the fact. UMO is a beast but its going to be one of the most critical components of Firefox that differentiates it from competing products. IMHO we have to embrace the community and trust them first and ask questions later (see "The Cathedral and the Bazaar" -- UMO is no Cathedral). We can put all the policy we want in place, but we want to encourage development of extensions and more importantly their listing on UMO.

By "policy" I mean clearly posted ethical guidelines for non-evil extensions. Not everyone has the same understanding and posted guidelines will help keep the well-intentioned extension authors within reasonable limits. Diclosure of the borderline bits will warn away users who aren't comfortable with those actions rather than have a controversy later when it's discovered. > The ability of extensions to be able to read this information is, IMHO, an > inherent problem with Firefox. The extension API should not allow that. Gecko knows the distinction between "chrome" and "content", that's all. The "Extension API" is strictly a way to tell Gecko to load more chrome. There is no way to sandbox this and we should not sugarcoat the fact that installing an "extension" is INSTALLING SOFTWARE with all the risks that entails. Community policing is OK as long as there's an easy-to-use mechanism for doing that (e.g. ebay's feedback mechanism: # of feedbacks, % negative, ability to list just negative ones to avoid being swamped by shills, etc. are all aids in trying to gauge reliability and safety).

http://www.mozilla.org/projects/security/security-bugs-policy.html "However we will ask all individuals and organizations reporting security bugs through Bugzilla to follow the voluntary guidelines below: ... Please try not to keep bugs in the security-sensitive category for an unreasonably long amount of time." What do you folks want to do with this?

The update security group might have a separate policy for security bugs, but I suppose if it doesn't the client security bug policy is a good default. This bug probably shouldn't have been private to start with, there is no exploit described here and I wouldn't think our policy discussion is private either since we'll have to get community buy-in on any such policy.

-> Wontfix?

I wouldn't WONTFIX this, this is a perfectly reasonable expectation for an AMO-hosted (assumed trusted by users) extension. Could be duped to any "AMO extension review policy" bug we might have, I suppose. As a practical matter we won't be able to review all extensions at this depth. This is one of the reasons we need a multi-tier AMO and should steer most normal users toward the "trusted/reviewed/polished" tier and completely hide the alpha-quality unreviewed extension tier from non-developers. I assume there'd be a middle "beta" quality tier that's not hidden, but not the first thing you see either. But I'm getting pretty offtopic for this bug.

*** This bug has been marked as a duplicate of 245198 ***