This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8849 - The ability for an author to completely disable javascript on their webpage - an html scripts="no" attribute
Summary: The ability for an author to completely disable javascript on their webpage -...
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-31 18:46 UTC by Mac Clemmens
Modified: 2010-10-04 13:55 UTC (History)
6 users (show)

See Also:

Attachments

Description Mac Clemmens 2010-01-31 18:46:26 UTC 
Given the inevitable complexities surrounding DOM Scripting, it seems wise to provide the ability to include a global "javascript disable" tag or attribute in the document, disabling javascript completely for that page and preventing other browser scripting activity from accessing or manipulating it in any way. 

Despite obvious limitations, it would provide instant and inherent immunity to XSS and XSRF attacks. Authors who suddenly found an crippling XSS vulnerability on their site could add this tag to the affected page, forcing javascript to disable on all clients until the vulnerability is repaired. 

A bank, for example, could use this feature on their login page to prevent any script from reading, writing, or manipulating anything on that page under any circumstance. The author would be limited to HTML and CSS only.  

Here's an example implementation:

<!DOCTYPE html><html lang="en-US" scripts="no">

In order for it to work, it would need to block scripts before they are loaded and were able to change the DOM in any way. The client would proceed to load the page but treat the page as if javascript were disabled on the client, but just for that page.

I see this feature as a simple, easy-to-grasp measure of last resort for web authors, and I strongly encourage its consideration and adoption.
Comment 1 Tab Atkins Jr. 2010-01-31 21:03:46 UTC 
We already have a mechanism for turning off scripts in @sandbox.  This also lets you apply more fine control than just shutting off scripts entirely.

Putting an entire page into sandbox mode is an interesting idea.  By itself, it doesn't work - <html sandbox> fails open in legacy browsers.  But if you then serve that page with text/html-sandboxed mimetype, it would have all the behaviors we want.  It would fail closed in legacy browsers, and give you full sandboxing control over the entire page.

So, counter-proposal!  Allow @sandbox on <html>.  Recommend that it be served with text/html-sandboxed to prevent unwanted execution in legacy clients.
Comment 2 Mac Clemmens 2010-02-01 08:41:51 UTC 
Re: #1 From Tab Atkins Jr.

I appreciate your counter-proposal. I would like to call for allowing @sandbox on <html> and recommending that it be served with text/html-sandboxed so it fails closed and prevents unwanted execution in legacy clients. 

It's an excellent point you make regarding the mimetype. Right now it browsers would just download the page instead of opening it. 

Here's an interesting question I stumbled upon while reading more on the matter:

For the content to be sent as this MIME-type youd have to be the one controlling the server sending the content. Why would you use an iframe to include content from your own site?

(http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox/comment-page-1#comment-41070)
Comment 3 Ian 'Hixie' Hickson 2010-02-14 06:50:23 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I agree that this would be a good idea, but HTML is the wrong level for it. This is the kind of thing we should do at the HTTP layer.

It turns out that there's already work on this front:
   https://wiki.mozilla.org/Security/CSP

I recommend subscribing to the public-web-security@w3.org mailing list and discussing this there:
   http://lists.w3.org/Archives/Public/public-web-security/
Comment 4 Mac Clemmens 2010-05-06 14:55:32 UTC 
Thank you, Ian. I am very impressed with the Origin header format proposal and I believe it provides a better and more comprehensive solution to the problem I described. I'll mark this as closed.