W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > January 2010

[Bug 8849] New: The ability for an author to completely disable javascript on their webpage - an html scripts="no" attribute

From: <bugzilla@wiggum.w3.org>
Date: Sun, 31 Jan 2010 18:46:26 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-8849-2486@http.www.w3.org/Bugs/Public/>

           Summary: The ability for an author to completely disable
                    javascript on their webpage - an html scripts="no"
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: mac@digitaldeployment.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org

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.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 31 January 2010 18:46:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC