AMO:Editors/EditorGuide/AddonReviews: Difference between revisions

Jump to navigation Jump to search

AMO:Editors/EditorGuide/AddonReviews (view source)

Revision as of 21:09, 19 January 2011

1,248 bytes removed ,  19 January 2011
→‎Policies and Actions
Line 259: Line 259:
| Remote code download or execution, custom updates   
| Remote code download or execution, custom updates   
| Reject  
| Reject  
|  
| Add-ons should not download remote code in any way. They are free to interact with web APIs as long as all that is being transmitted is data, not code. Add-ons are allowed to insert local scripts into webpages (within reason), but are not allowed to insert remote scripts.
|-
|-
| Security violations  
| Security violations  
Line 267: Line 267:
| Bad or no namespacing  
| Bad or no namespacing  
| Preliminary Review  
| Preliminary Review  
|  
| All scripts that are included in the main window overlay should have proper namespacing to avoid name conflicts with other add-ons. The name should normally correspond to the add-on name in order to guarantee its uniqueness.
|-
|-
| Preference names without "extensions." prefix"  
| Preference names without "extensions." prefix"  
| Preliminary Review  
| Preliminary Review  
|  
| Add-on preferences should use the "extensions." prefix, and should also have a reasonable namespace.
|-
| Privacy issues
| Preliminary Review
| An add-on can claim to work with a popular website like Twitter, but then send the user data through some other site, most likely owned by the developer. There needs to be a justified reason to handle user data in this manner, and the privacy policy and add-on descriptions need to be very clear about this. Passwords should never be handled in this way, and they should only be transmitted directly to the original API provider.
|-
|-
| Performance problems  
| Performance problems  
Line 279: Line 283:
| Not using prefwindow for preferences  
| Not using prefwindow for preferences  
| Add Note  
| Add Note  
|  
| If an add-on has a preferences window, we recommend that authors do 2 things: 1) use the ''prefwindow'' element, 2) add the line in install.rdf that enables this window to be opened from the Add-ons Manager window.
|}
|}


<br> During the code review, you should check all code files, and you should look for all of the following:<br>
In general you should apply your judgement and try to identify code that may appear suspicious or out of place. Try to understand what everything does and how it all fits together.<br>
 
*Namespacing. All scripts that are included in the main window overlay should have proper namespacing to avoid name conflicts with other add-ons. The name should normally correspond to the add-on name in order to guarantee its uniqueness.<br>
*Default add-on preferences should use the "extensions." prefix, and should also have a reasonable namespace. Application preferences should not be changed in the default preferences file.<br>
*Remote code downloading or execution. Add-ons should not download remote code in any way. They are free to interact with web APIs as long as all that is being transmitted is data, not code. Add-ons are allowed to insert local scripts into webpages (within reason), but are not allowed to insert remote scripts.<br>
*Privacy issues. An add-on can claim to work with a popular website like Twitter, but then send the user data through some other site, most likely owned by the developer. There needs to be a justified reason to handle user data in this manner, and the privacy policy and add-on descriptions need to be very clear about this. Passwords should never be handled in this way, and they should only be transmitted directly to the original API provider (for example, Twitter).<br>
*Custom updaters. Add-ons are not allowed to have custom update mechanisms or tamper with the update mechanism in the application. Any code that indicates the add-on is fetching or installing updates should be rejected.<br>
*Possible performance problems. Running inefficient code during important events like startup or page load should be discouraged, but it's not a reason for rejection, unless the problem is serious or it has been noted to the author before.<br>
*Using [https://developer.mozilla.org/en/XUL/prefwindow prefwindow]. If an add-on has a preferences window, we recommend that authors do 2 things: 1) use the ''prefwindow'' element, 2) add the line in install.rdf that enables this window to be opened from the Add-ons Manager window. It's not mandatory to do this, but it's always worth noting to the author.<br>
*Binary, obfuscated and minified code. Some of it may not appear in the validator, so keep an eye for it. Known libraries that pass the checksum should be no concern. In the case of updates, if none of the binary, obfuscated or minified files have been updated and were previously approved, it's OK to approve if everything else passes review.<br>
*In general you should apply your judgement and try to identify code that may appear suspicious or out of place. Try to understand what everything does and how it all fits together.<br>


By the end of the code review, you may have a series of notes that will require the add-on to be significantly rewritten. If you think that's the case, it's OK to reject the add-on without proceeding with the next step. If the add-on needs work but is safe to use, it can be given a preliminary review approval without performing the testing step.
By the end of the code review, you may have a series of notes that will require the add-on to be significantly rewritten. If you think that's the case, it's OK to resolve the review without proceeding with the next step. If the add-on needs work but is safe to use, it can be given a preliminary review approval without performing any testing.


=== Step 4: Feature Review<br>  ===
=== Step 4: Feature Review<br>  ===
Jorge.villalobos
canmove, Confirmed users
1,448

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/278540"

Navigation menu