*Problem:*
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.
*Benefits:*
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,
Brett
* Proposed to Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=848647
