As promised:
Security was an important part of the design of Fabric. What security means depends on whether Fabric is running standalone from the command-line or as a browser plugin.
When Fabric is run from the command line, we are in general unconcerned with security. This is because Fabric is run like any other program on a computer where the software is deliberately installed by the user. Fabric runs as a module for Node.js or for Python, and runs with the same security credentials as Node.js and Python. Like Node.js and Python, Fabric will only do what you explicitly tell it to. Let us be clear: this is the context in which you might use Fabric for server-side work, much as one does with Node.js, Python or Ruby.
When Fabric is run as a browser plugin, security is a major concern because a Fabric application (or, more precisely, an in-broswer application that wants to use the computer the browser is running on to run code) specifies code that is compiled and executed on the machine running the browser. To prevent the usual types of exploits, the language KL in which the Fabric operator code is written is both pointer-free (like Ruby, Javascript and Python) and provides bounds checks for all array accesses, throwing an exception for any out-of-bounds accesses (like Ruby and Python). Access to third-party code, which does not adhere to the same pointer-free and bounds-checked rules, is done through our extension mechanism, and extensions, besides the default extensions provided with Fabric (that are just wrappers for common open-source libraries), must be explicitly installed by the user -- it is not possible to make the user's browser automatically "download" an extension.
Of course, you are wise to question whether you can "trust" our security model. Fortunately, if you're really in doubt, you can simply look at our code, which is open-source; we believe this already places us ahead of common browser plugins, such as Flash, to which could be posed the same questions but for which one cannot audit the code.
When Fabric is run from the command line, we are in general unconcerned with security. This is because Fabric is run like any other program on a computer where the software is deliberately installed by the user. Fabric runs as a module for Node.js or for Python, and runs with the same security credentials as Node.js and Python. Like Node.js and Python, Fabric will only do what you explicitly tell it to. Let us be clear: this is the context in which you might use Fabric for server-side work, much as one does with Node.js, Python or Ruby.
When Fabric is run as a browser plugin, security is a major concern because a Fabric application (or, more precisely, an in-broswer application that wants to use the computer the browser is running on to run code) specifies code that is compiled and executed on the machine running the browser. To prevent the usual types of exploits, the language KL in which the Fabric operator code is written is both pointer-free (like Ruby, Javascript and Python) and provides bounds checks for all array accesses, throwing an exception for any out-of-bounds accesses (like Ruby and Python). Access to third-party code, which does not adhere to the same pointer-free and bounds-checked rules, is done through our extension mechanism, and extensions, besides the default extensions provided with Fabric (that are just wrappers for common open-source libraries), must be explicitly installed by the user -- it is not possible to make the user's browser automatically "download" an extension.
Of course, you are wise to question whether you can "trust" our security model. Fortunately, if you're really in doubt, you can simply look at our code, which is open-source; we believe this already places us ahead of common browser plugins, such as Flash, to which could be posed the same questions but for which one cannot audit the code.