[whatwg] Self-imposed script or networking restrictions (toward privacy and XSS-protection, and stimulating offline tool creation and increased but safer privilege escalation)

*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

Received on Sunday, 13 April 2014 03:14:22 UTC