I believe that if Ajax or other forms of dynamic scripting had been absent but were proposed today, people would probably say things like:

1. "What, you want to allow sites to have the ability out of the box to track my mouse movements?" 2. "You want sites to be able to know what I'm typing in a text box before I choose to explicitly submit?" 3. "You want to allow executable code, including third party code, to update itself without a means for a developer to review the source?" 4. "You want my generic offline build tool to cause users concern about whether the data I've added locally will be sent back to the server?"

While browsers will hopefully allow user-directed control of this regardless of standards, ala NoScript or the like, there is no means (to my knowledge), besides perhaps packaging the file as an add-on with limited privileges or a sandboxed site-specific_browser ( https://en.wikipedia.org/wiki/Site-specific_browser ), by which a website author can cause its own particular web app loaded over the web to be issued in such as manner as to allay privacy or cross-site scripting concerns by having the browser inform the user that a given type of (safe) app has been loaded, one which is either not able to:
    1. execute any scripts at all
    2. phone home at all
    3. phone home at all after the initial static HTML payload
4. phone home at all after the initial static HTML payload except to a list of origins indicated to the user

The above ought to also allay security concerns in the case that a script uses eval capabilities on a post-load network-delivered string.

*Proposed Solution:*

I would like to propose that HTTP headers, an internal HTML tag attribute (like the offline apps manifest attribute), and/or changes to the AppCache manifest structure be created which will cause desired security principal restrictions to be enforced, in particular either:

1. preventing all scripting
2. allowing scripting but prohibiting all Ajax or other networking requests (dynamic insertion of iframes, image or link tags with remote URLs, dynamic form submissions, etc.) 3. allowing scripting but prohibiting all Ajax or other networking requests except to URL origins or pages indicated within a whitelist (where the browser UI would display any such whitelist to users and/or prevent requests to the whitelist until the user approved, ideally providing them first a view of the proposed payload, and if approved, with a preview of the response payload and a choice as to whether to accept, and with the option to remember any such outgoing or incoming approvals in the future). Perhaps the AppCache manifest could be extended to provide this directive of prohibited or conditional updating. 4. optionally excluding loading of other resources within even the initial declarative HTML payload.

Data: URIs and blobs could, however, be allowed dynamically where scripting was allowed (e.g., whether through window.open(), a dynamic execution of an <a download=""> tag or the like) as well as statically without the need for a whitelist.


1. The designation by authors of this status could give assurance to users that privacy between page loads will not be violated on sites of general interest. This would be especially useful in apps utilizing IndexedDB where the user might make a lot of local modifications but not wish to share these back with the origin server.

2. It could also be a boon to web developers who wish to share generic build tools (whether ones that are online, offlinable via AppCache, and/or which run from file://) in a manner which does not raise privacy concerns.

Currently, many web apps are distributed along with OS-dependent build scripts or scripts using non-client-side languages such as Node.js, Python, or Java, and whose interpretation requires the downloading of additional tools. If the developer could create a tool which would not raise privacy concerns but would instead inform users that the code they have loaded locally will not be able to update itself without their permission (at least without giving consent to a proposed payload back to the server), developers may prefer to write in client-side JavaScript for their own convenience (given the ubiquity of client-side JavaScript), and with the benefit of facilitating modifications on their tools whether by paid developers or open source contributors who may be most likely to know at least some JavaScript. Their code could provide build functionality by compiling locally designated files or other content into a file download, texarea, etc.

3. If implemented, the sandboxing capability could be leveraged to blur the line between add-ons, web apps, and mobile apps and be used by site-specific browser implementations. Web app users would gain the same peace of mind and more granular privilege control of mobile apps.

As a result of users knowing there would be this sandboxing, the door could, moreover, be opened for websites to request any privilege allowed to add-ons without needing the step of special packaging and encouraging the development of standardized privileged APIs which would work across the web, mobile, and packaged add-ons*. A website may already currently ask users from the web whether they wish to install a privileged add-on, so there should be no net increase in security risk by allowing sandboxed websites from doing the same; on the contrary, the requirement of granting privileges granularly (unlike in some add-on systems), will ensure that users are well-informed as to the exact security or privacy implications of granting approval, as well as let websites be designed for progressive enhancement (e.g., an app might only ask for privileges as needed, a user might allow the app one high-level privilege but not another (e.g., granting arbitrary local file access on an app deemed by the user to be safe in its current snapshot, but disallow networking-related privileges), etc.).

My Firefox add-on, AsYouWish (at https://github.com/brettz9/asyouwish/ ), is meant as a current workaround in this regard for Firefox, https://github.com/brettz9/asyouwish/ , but while it offers granular privileges, it suffers from not being currently sandboxable and not being standard across browser.

Best wishes,

* Proposed to Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=848647

Reply via email to