canmove, Confirmed users
737
edits
Line 133: | Line 133: | ||
'''Why can't my add-on code access web content directly? ''' | '''Why can't my add-on code access web content directly? ''' | ||
The | The SDK and Builder enforce a separation between: | ||
This | * the main add-on code, which has access to SDK APIs and even XPCOM objects, but can't access web content | ||
* content scripts, which can interact directly with web content, but don't get access to the SDK APIs or XPCOM | |||
This is for two reasons: | |||
<strong>Security</strong> | |||
Code that interacts directly with web content is more likely to become compromised by malicious web pages. If this code is given access to powerful APIs, then a malicious web page can do much more damage, including access to the user's local file system and cross-domain network requests. See [http://blog.mozilla.com/addons/2011/10/14/security-mechanisms-in-the-add-on-sdk/ this blog post on the SDK's security mechanisms], and this [http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-185.html study on browser extension security]. | |||
<strong>Security</strong> | |||
The Mozilla platform intended to move towards a model in which it uses separate processes to display the UI, handle web content, and execute add-ons. This is expected to improve the responsiveness of the UI, application stability, and performance, especially on multi-core machines. | |||
In this architecture the main add-on code will run in the add-on process and will not have direct access to any web content. | In this architecture the main add-on code will run in the add-on process and will not have direct access to any web content. | ||
At the moment this work is on hold: but it is still likely to happen in the future. Add-on SDK and Add-on Builder are designed to be forward compatible with the change, so that when this happens you won't need to rewrite add-ons written using the Add-on SDK / Add-on Builder. | |||
'''What's a content script? ''' | '''What's a content script? ''' |