11769 2011-01-15 07:54:55 +0000 I have just implemented a 'javascript sandbox' using iframes and postMessage, exactly as intended by the specification. Thank you! It works beautifully! Safe XSS at last! Of course, now the next problem comes into view: I have all these IFrames/Objects wi 2011-02-15 00:34:55 +0000 1 1 1 Unclassified WebAppsWG Web Messaging (editor: Ian Hickson) unspecified Other other RESOLVED LATER http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian ian mike public-webapps public-webapps-bugzilla oldest_to_newest 44369 0 contributor 2011-01-15 07:54:55 +0000 Specification: http://dev.w3.org/html5/postmsg/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: I have just implemented a 'javascript sandbox' using iframes and postMessage, exactly as intended by the specification. Thank you! It works beautifully! Safe XSS at last! Of course, now the next problem comes into view: I have all these IFrames/Objects with their sandboxed javascript coming from remote servers that I can talk to... but no idea how much CPU they are consuming, or when they crash. What's needed is something like "window.getCpuUsage()". Most of the rest of a reasonable scheduling system can then be built entirely within javascript. The next obvious step would be to generalize that to all important resources consumed by the embedded object; memory, bandwidth, and open connections. Views of these statistics are available within many browser debuggers, but not on reflection to the javascript itself. This information should probably be available to both the containing page, and the contained object. With this one simple problem solved (detecting abusive/broken 'sub-process' javascript by it's behavior) javascript is free to become, in many ways, a fully-fledged operating system. Or at the very least, slow down it's animations or entropy generator to not totally consume all my CPU. Jeremy Lee BCompSci(Hons) jeremy@unorthodox.com.au Posted from: 58.106.139.138 45517 1 ian 2011-02-15 00:34:55 +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: Partially Accepted Change Description: none yet Rationale: This might make sense and should be considered, but before we add it we should wait for the sandboxing features we've already specified to be move widely implemented, so as to not get away from the implementations.