8849 2010-01-31 18:46:26 +0000 The ability for an author to completely disable javascript on their webpage - an html scripts="no" attribute 2010-10-04 13:55:02 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All CLOSED WONTFIX P2 enhancement --- 1 mac ian ian jackalmage mac mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 31372 0 mac 2010-01-31 18:46:26 +0000 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. 31374 1 jackalmage 2010-01-31 21:03:46 +0000 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. 31379 2 mac 2010-02-01 08:41:51 +0000 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) 31985 3 ian 2010-02-14 06:50:23 +0000 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/ 35464 4 mac 2010-05-06 14:55:32 +0000 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.