Parisista

HTML started simple. TimBL’s first mention of HTML Tags in www-talk mailing list:

Most of the tags are just style tags: this goes for the headings H1 to H6, the lists UL and OL with list elements LI, the glossary DL with elements DT and DD.

Since then, HTML has evolved beyond the original 22 tags; and so has evolved the web and the supporting infrastructure around consuming HTML. Things are getting even more interesting with content being published (and micro-published) and then embedded (videos, widgets, scripts) as content within content. The content within the content (or micro-content) is (a) infrastructure driven, like embedding of scriptlets for web tracking (b) consumption driven, like widgets for news, weather, jobs (c) interaction driven, like videos, slideshows, micro-documents, spreadsheet snapshots and (d) submissions like search forms, data-capture fields, etc.

The micro-content in large part is distributed as a code fragment wrapped either in <script>  or an <object>/<embed> tag. As the offering of these services grow, together things will become sophisticated and mature in coming years. How far this script should be trusted? At the onset, the following questions need answering:

• Can the embedded script read the DOM of the page it is hosted in?
• Can the script make further calls to the remote server using the script transport?
• Can the script manipulate the CSS of the page it is hosted in?
• Can the script attach event handlers?
• Can the script call window.close() or document.replace() ?
• Can the script launch a pop-up window while being rendered?
• Is the script allowed to render non-textual content like video, audio, etc.?

In today’s HTML and the User-Agent world, all the questions may be answered as YES.

The proposal is for a new tag called <sandbox> . <sandbox> provides hints to the user-agent for a fine grained and portable permission control of embedded content. Don’t want the script to capture user events? Only wanna allow page manipulation while being rendered? Say so in the attribute for the element. The proposed tag takes the browser security to a new level. The hints in the sandbox tag would inform the user-agent what the embedded script can/can’t do.

The IDL may look like this:

interface HTMLSandboxElement : HTMLElement {
readonly attribute allowRemoting;
readonly attribute allowStyleChange;
readonly attribute allowDOMScripting;
readonly attribute allowEventHandler;
readonly attribute allowSubmit;
boolean checkPermission(in DOMString attributeName);
}


A sample HTML fragment (Web-Analytics example)


<sandbox allowRemoting="0" allowStyleChange="0"
allowEventHandler="1" allowSubmit="0">
<script src="http://www.example-analytics.com/tracker.js" mce_src="http://www.example-analytics.com/tracker.js" >
</script>
<script type="text/javascript">
_uacct = "UA-XXXXX";
Tracker();
</script> 
</sandbox>

Another example HTML fragment (news widget in sidebar). By default allows content which is plain HTML with links, text and associated styles.

<sandbox>
<script src="http://example.com/dailyheadlines.js" mce_src="http://example.com/dailyheadlines.js"
</script>
</sandbox>


Benefits:

• Fine-grained control while composing content (or application output) from multiple sources
• Shared responsibility between page author and user-agent
• Takes the browser security to a new level
• Portable permissions instead of relying on individual user-agent configuration options for various permutations and combinations.

Under what circumstances the new tag may not make sense:

• User-agents take full resposibility of such fine grained permissions through their own implementations and user configuration options
• Micro-content, content inclusion etc. become passé