AsYouWish is a browser add-on (currently Firefox only) to allow requests for browser privileges to be made from regular HTML.
OTHER License
Note: To the extent this add-on can be salvaged, some work is underway in a branch of WebAppFind to restore this functionality. If it is decided not to be included, it may be moved back to this repository.
Important note: This project is no longer functional in the latest Firefox versions. If someone is capable of addressing the complex JavaScript issues in Firefox as per this bug it is possible that the current problem can be overcome, but at this point it seems that I will not be able to fix it myself.
AsYouWish is a browser add-on (currently Firefox only) to allow requests for browser privileges to be made from regular HTML. The latest release should be at https://addons.mozilla.org/en-US/addon/as-you-wish/ .
Using this add-on is at this point still potentially quite dangerous, e.g., to your data (not only browser data) so don't install--especially at this time--unless you are willing to take the risks. It is hoped this may go through a thorough security vetting as part of the process to get the add-on accepted at AMO.
I recently encountered a privileged AsYouWish request while visiting Yahoo.com; it is possible that a malicious third-party added some code which Yahoo included (and sites not familiar with AsYouWish might not be familiar with the consequences of including code aimed for it). (I unfortunately rejected the request before noticing what exact privileges had been sought or which domain/code segment had been responsible for the request.) This points to the dangers of approving privileges on any site which is not actively prohibiting untrusted third-party code.
The current way this add-on may be tested is either through the built XPI file included with the source, or by using the SDK cfx tool.
Obviously allowing privileges may be dangerous if used by a malicious site (as with addons), so there needs to be a way to inform the user that there is a request and allow them to refuse or accept. AsYouWish tries to provide this.
No site can even ask for privileges until the user configures AsYouWish to allow requests from their site (or type of site). (See the "Usage of the options dialog" section below for more details.) So if the user effectively says through their options, "Go ahead and let any HTTPS site ask me for privileges", the addon will allow that, but the default is to require the site to be added to a whitelist before it can even ask the user for permission and then the user will need to agree.
While this makes it harder for developers to get users set up (as the users will first need to learn how to configure the addon to let the site even ask them), this is intended to provide some means of protecting users from themselves, especially those users who just click "ok" to dismiss warnings without first reading them. The privileges that can be granted to sites are as dangerous as being able to read the user's bank passwords, read and control what tabs they have open, visit other sites in their name, read or destroy their local files, etc. etc. Yes, this is dangerous stuff, but that capability is also available to regular addons, and can be used to provide useful functionality to users (e.g., a password manager, a file browser, etc.). This add-on makes explicit exactly what is being requested of users and somewhat easier for developers to create.
The API mirrors the Mozilla Add-ons SDK API, so there is little new for developers to learn who are familiar with this API. It is also hoped that this API might be mirrored in other browsers in the future.
Access is granted to specific URLs, not including the query string/hash. Privileges do not apply site or even folder wide (to allow a greater sense of security and choice in case a website allows third party add-ons which may seek their own privileges).
Before granting permission to any site to use AsYouWish, please note that even well-meaning websites may, if poorly designed (as with a poorly designed browser add-on), expose your system to exploitation. For example, if a website allows user comments but does not properly escape them according to standard security practices, it would be possible for a malicious individual to inject code into the site (whether scripts, links, etc.) for which you have granted AsYouWish privileges which could then abuse those privileges when you visit the site and do great harm to your system.
Another important risk to avoid is in the case of bookmarklets. Bookmarklets are links which you can drag to your browser's bookmarks toolbar which, when subsequently clicked from your toolbar, will run the code included as part of the link as if the code were running on the currently displayed page. So, it is important not to add bookmarklets from untrusted sources especially if you try to click them while visiting pages for which you have granted AsYouWish permissions.
You can see this in action (but in a safe way!) at the following site (also in the source of this repo).
Note: For greater security I have updated my password and SSH keys on Github (and updated email accounts) after the Heartbleed patches were applied by Github. No suspicious activity was found.
To see the options dialog icon (which must be clicked to see the options), you will need to open the Add-on Bar (View->Toolbars->Add-on Bar (or Options->Add-on Bar).
While I hope to simplify the dialog in the future for the average user, AsYouWish currently offers a rather high degree of control over exactly what privileges can be approved or even requested and from what sites or types of sites privileges may be requested.
A site can be allowed the ability to REQUEST a privilege (though you will still have to approve the request) by one of the following means:
If none of the above are enabled, the site cannot even ask you for privileges, let alone be granted them, but if any one of them is enabled, the site can at least ask for privileges.
If you want to live a little dangerously (you are not afraid of accidentally or mindlessly pulling the approval pulldown to say grant any site very dangerous privileges), you can select #2 and then any website can immediately request privileges without any extra hassle for you or the website; you can still disapprove, but it puts you a little closer to danger, so it is not allowed by default.
You could also select #1 to allow even sites like "http" websites to ask you for privileges, but this is inherently dangerous because non-secure protocols like "http" allow hackers to potentially get between your browser and even a trustworthy site. This is not recommended.
As far as the specific lists of websites shown in the options dialog:
Removing an item from the allowed list, will remove it from the allowed, approved, and addons lists (if present).
Removing from the approved list will only remove it from that list (since the user may still wish to allow sites the ability to request other privileges). Similarly, removing from the addon list, will only remove it there since the user may wish to still allow the site to request privileges without running on browser restart.
Finally, the whitelisting of specific privileges (if the checklist is enabled to enforce the whitelist) will prevent any privileges from being requested or granted (even if the site is otherwise allowed to request privileges). Tooltips are available to explain the APIs at some level, but these are only my layman's understanding of the API so if in doubt, please see the SDK documentation. Note that (when the checklist is enforced), requests to act as an addon can be enabled or prevented via the presence or absence of the "x-register" privilege in the whitelist (but this item will not disable or prevent already approved addons or explicitly added ones).
AsYouWish allows websites to be run as "addons". While these "addon" websites do not automatically gain additional privileges, they will be able to request additional privileges upon load and they are loaded in a hidden window immediately upon approval and upon each browser restart.
This can be used, for example, to add a ui
panel
to the add-on bar
(or say add to the context menu, etc.) to function similarly to normal
addons--except that you never need to zip up your HTML file (though the
site can take advantage of HTML5 features for offline caching).
Currently, "Allow as addon" does not automatically give privileges--though it can request them; it simply means it will be launched in a hidden window on each restart (and when first chosen).
Note however that even if a site has only asked for "addon" privileges, one might still consider it as a privacy concern for a site to know when you are loading your browser and may add a performance load.
Regarding the distinction between an addon and regular privileged site, normally the site will determine which way it will run. However, one can install from a local file, for example, and the file could be designed to be usable either as an addon and/or as a regular site, so that choice is made available (e.g., if you only want a global context menu to appear when you are ready to work on such a project, you can bookmark the page without adding the page as an "addon", while other users might wish to always see the functionality upon browser restarts).
One may use AsYouWish's options (its icon is in the add-on bar) to remove a site from being treated as an add-on, but if you have assigned privileges to an untrustworthy site, damages may have already been done.
For developer information on "addon" websites, see Add-on websites.
For the concept of a Browser-in-Browser (to allow a regular website to function as the browser UI) and the idea for it to become itself extensible with addons, see the section "Some additional intended use cases" below.
Web applications already are gaining potential access to dangerous features (e.g., Geolocation) and are thankfully starting to work more like desktop apps, with offline storage, caching manifests, desktop notifications, so it is, I think, a natural step to allow HTML to gain access to the browser ecosystem in an ideally eventually standard way since it is ALREADY POSSIBLE to write privileged code with easy installation by users--they're called browser add-ons. :)
For those who would accuse AsYouWish of introducing undue risks, I want to point out that third-party installation of addons is still possible at the time of writing (and that doesn't tell you what risks might be present; AsYouWish at least tries to tell you some of the risks that may be involved). Although Mozilla states they might make 3rd-party installation of addons more difficult in the future, I might point out that for a browser to remain open, it will presumably still need to at least allow some way for the user to opt in to allowing sites to allow privileged addons (so that Mozilla is not the exclusive gate-keeper). And refusing to allow an easy and potentially standard means of writing addons via regular websites strikes me as hardly being in the spirit of openness, especially when there does not appear to be any essential security difference between addons and AsYouWish-enabled sites.
But yes, as with add-ons I would hope such as Mozilla may be able to host such privileged HTML at their Marketplace as they do with add-ons and non-privileged web apps, providing added peace of mind to users that the apps they are installing are reviewed for security.
AsYouWish has also added its own support now for "addon" websites, thus allowing the benefits above to be available on each browser restart, with the user's permission.
While Open Web apps do have privileged potential, they currently do not appear open to exposing full addons privileges. Also, although the Mozilla Marketplace lets one target a website to install it, and one can have non-privileged apps installed from a site without packaging the file, there does not appear to be a way that a site can request privileges for itself to be installed with higher-than-website privileges (though privileges which are still limited in comparison to addon privileges) without the user creating a specially packaged file.
I'm hoping this can really turn into an API agreed on by the browsers so available by default. The add-on itself is written in JavaScript, so hopefully accessible enough to easy introspection. AsYouWish has no need for special file formats, HTML object tags, etc.
This is similar to these technologies, but the aim is to be potentially cross-browser (and enablePrivilege is out the door now in Firefox).
While this addon does not allow you to use the same old API, a similar level of trust with sites being able to request privileges if from a signed script, can be enforced by enabling the options checkbox "Allow privilege requests from all websites whose protocols are allowed". Then you will not need to first add sites to the allowed whitelist (see the "Usage of the options dialog" section though on security concerns).
While the concepts are similar, AsYouWish differs in these regards:
<HTA:application>
element for declarativelyActiveXObject
,execCommand
, and window.clipboardData
. While it should beAppJS (or Deskshell) and node-webkit offer a similar feature set to AsYouWish, i.e., client-side web language-based apps with privileged access. However, these operate as executables independent of the browser whereas AsYouWish operates within the browser.
The node-based projects of course offer access to the feature set of Node.js, while AsYouWish offers access to the Firefox Addon SDK (and through it, if necessary, to Firefox's XPCOM components). Both can be used for access to the file system (in fact, the SDK is moving to use the same API here as Node.js). Mozilla, moreover, is apparently open to using the Node.js API on a case-by-case basis so if one writes using the synchronous style, one may be able to write code which can readily be ported from AsYouWish (at least to node-webkit). The Addons SDK even has its own server API. AsYouWish, through the the Addons SDK, however, can, unlike Node.js, obtain potential access to privileged browser APIs (with user permission).
By working within the browser, AsYouWish can avoid extra installations (beyond Firefox and the AsYouWish add-on); the user simply has to approve a site.
AsYouWish allows HTML and will be treated as Firefox would treat any other HTML page with the exception of the privileged AsYouWish calls; it also does not require special packaging. The other projects do leverage Chromium, which may have some HTML5 features not present in Firefox (and vice versa): http://caniuse.com/
As far as the use case for independent executables to allow such programs to operate independently of one's browser profile (e.g., without having to open up Firefox with all of one's tabs, add-ons, etc.), Windows users might create shortcuts to cmd.exe which open a web app in Firefox under a new profile. But if one does wish privileged apps to be opened merely as new tabs or windows within Firefox, this is also possible (by avoiding the profile command line flag).
Work is planned for Executable Builder (work not yet ready for release) to assist in the creation of executables which can work in such a manner as well as be associated with the right-click "Open with" functionality of desktop files as with WebAppFind (and it is hoped that AsYouWish can then allow a custom module (or perhaps via command line instructions to Executable Builder) to allow Executable Builder functions such as associating desktop file extensions with web applications to be requested via the web).
XULRunner might also conceivably be used with WebAppFind instead of Firefox for a more light weight "executable" environment.
Sorry, I just love the analogy too much whereby the "Molecule Man" in Marvel comics discovers, courtesy of a God-like being, that it has only been a mental block keeping him from manipulating organic matter in addition to inorganic matter. While the danger there too is clear, there are similarly a potentially great many benefits.
My feeling is that inhibitions have kept the web from being opened up to a wider developer base as with the web, both with addons' cross-browser incompatibilities, need for dealing with zipping and installing special file formats, etc., as well as a helpless attidue that "The web is the web, the browser is the browser, and never the twain shall meet".
(Thanks to Marvel for great comic fun (the low-res image is from Marvel's copyrighted work) and thanks to the folks (Supermorff and m1shawhan) at the Marvel Database for finding and scanning the image!)
One particular reason I am interested in this is that I feel it is unfortunate that for current web applications, different third parties cannot access a shared database hosted privately in the user's browser (unless it "belongs" to one of the websites). For example, in an application I'm hoping to build, I'd like to let the user store books they have found and browsed offline, but I'd also like to expose the data so that other web applications could also access it (if the user permitted), allowing people to innovate into the future without requiring new ways of storing the data. I could provide an API specific to my site, but I'd like this to be doable in a neutral and familiar way.
I also like the idea of a browser-in-a-browser which could theoretically be done with privileges and shared databases (others have done a browser-in-browser using the Flash plugin, but I'd like to see it work without plugins--I'm hoping Mozilla may eventually come around to including something like AsYouWish by default since it now uses a whitelist, etc. by default). The advantage I see to this is that it may allow normal web developers the ability to use familiar and easier languages to innovate with user interfaces, while accessing the trickier and lower level plumbing handled by the browsers.
I'd also like to see support for PUT editing (for built-in publishing).
Also a browser as in a Gopher-like remote file browser.
If approach in https://github.com/brettz9/asyouwish/issues/4#issuecomment-11670998
using nsIPermissionManager doesn't work, when an AYW x-DOM request is made,
we might re-open the AsYouWish document in a chrome URL, gaining
chrome privs thereby (as per
https://developer.mozilla.org/en-US/docs/Displaying_web_content_in_an_extension_without_security_issues,
thus allowing the AsYouWish app in an iframe to have full privileges (though
also presumably any other child iframes unless there is a way around this),
allowing us to listen for events within iframes to be able to track frame
history (for the sake of backward/forward buttons); tracking in
issue 4? These browsers
might even be able to support their own "addons", e.g., via postMessage()
,
have their own "add-on bar", toolbar, pinned tabs, Panorama groups, etc.
(via (x-namespaced-)simple-storage; see the incomplete demo).
The browser-in-browser could work with the
Executable Builder--when
completed--as a separate executable (and accept its own command line
args via WebAppFind).
While the likes of Loomo or my Filebrowser-enhanced add-on are written as Firefox add-ons to provide file browsing within Firefox, AsYouWish also allows this possibility (see the file browser demo included in this AsYouWish repository). While users of web apps might not wish to replace their desktops (WebAppFind is designed for such users), such a HTML-based file browser could provide its own task bar for launching other AYW apps (and if run as an AsYouWish "add-on website", it could even--as with a Browser-in-Browser mentioned above--accept its own add-ons available on start-up). If Node APIs are brought over to the SDK, the same code base can be reused for a server-side file browser/editor. See the README of "Filebrowser-enhanced" for some possible todos here.
Ability to distribute web utility apps which read or write to files, so web apps which, for example, build configuration files, do not need to force the user to copy paste from a text box or depend on downloading and installing some bulky server-side language interpreter (possibly in a non-JavaScript language).
AsYouWish might even be used to make a server (given some support within Firefox for test servers) which could in turn be used in conjunction with WebAppFind (e.g., to pass privileged command instructions to the server) or to serve its own AsYouWish-privileged apps (which could listen for WebAppFind commands local to those visitors). A server connected to the administrator's browser privileges (including if an AsYouWish Browser-in-Browser were built) might be useful for the likes of displaying the songs the admin has downloaded and is listening to in a web app. Allow anyone to publish and administer!
This might be able to work as a file server as well as web server.
Make desktop file editing as interconnected as the Web (one can already make file:// links but create an AsYouWish tool for local WYSIWYG HTML editing which is new-page-wiki-linking friendly! Use the same code base for a server-side wiki (including a remote PUT-saving file-based one).
A macro program with differing levels of potential privileges. Could make command line requests, etc. for potential scripting of, and interaction with, outside apps. Might be expanded to do web-crawling and search indexing.
jQuery/XQuery-like reshaping of remote HTML, ideally via HTTPQuery using JavaScript.
Last but not least, a Git-accessible client-side web-based IDE/word processor... (Firefox can execute files and processes, so if nothing else, some kind of command-line interface, along the lines of the included command line demo).
For security reasons, I decided against allowing an entire folder hierarchy to gain privileges without the need to make additional requests. The reason for this is that if the site included any untrusted 3rd party libraries within the directory, the user could be at risk (and would also require internal code changes as we are currently depending on site-specific preferences).
There is no need to expose globals in the SDK of "self" (as it is only a part of content scripts, so page-mod can utilize within a string) or "addon" (which is for page-worker content scripts).
While it would be convenient to drop it, I decided to require the full "sdk/" path for consumers of all APIs since usage without it is to be deprecated.
Although we could potentially i18n-ize short priv names (and sort accordingly), since the tooltip gives the description, and since these are actual APIs, I felt it best to stay with the English for these.
ui
appears to be working
ok: function(v) !v || v instanceof panels.Panel || (v.show && typeof v.isShowing !== 'undefined') // Adding duck-typing to avoid wrapper complaining of instanceof
System.import()
(ES6 modules).postMessage
accessweb+mycalcapp
, it can open a specificThe name dervies from what it allows (so users and developers can have convenience in apps not excessively circumscribed, even while taking into account security concerns) and is also a nod to the 25th anniversary to the film Princess Bride where this line was used in the film.