text/html-sandboxed should just be a sandboxed MIME type attribute

(Including public-web-security for their feedback on this as well.)

The iframe sandbox attribute is a self-described defense in-depth security feature. As such, there's no need to use a full MIME type to protect against non-supporting browsers (http://dev.w3.org/html5/spec/Overview.html#text-html-sandboxed). The spec text under "Security Considerations" makes it sound like text/html-sandboxed is the resolution to the sandbox attribute being defense in-depth, which is untrue. Furthermore, if web sites view this feature as "just send this mime type to be safer," then users of non-supporting browsers will experience file downloads or (in the case where another program/browser has registered to handle the type)the launch of part of the website in another program/browser. That's just a bad user experience IMO.

What about other existing MIME types that might need to be sandboxed (image/svg+xml, application/xhtml+xml, etc.)? Do we really want to add new sandboxed MIME types for each of these? Really, these aren't new types. Rather, they're existing types with the caveat of a flag being set. A better option would be to use a MIME type attribute to indicate the content should be relegated to a unique domain (text/html;sandboxed or application/xhtml+xml;sandboxed). This would allow any existing (or future) type to be sandboxed. Additionally, it avoids the false impression that text/html-sandboxed is a definitive method of restricting the content from accessing the rest of the site.

I've opened a bug to track this:  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12390

-Jacob Rossi