W3C home > Mailing lists > Public > public-html@w3.org > August 2011

RE: ISSUE-166 html-sandboxed: Chairs Solicit Proposals

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 2 Aug 2011 22:39:56 +0000
To: Maciej Stachowiak <mjs@apple.com>
CC: Paul Cotton <Paul.Cotton@microsoft.com>, 'HTML WG LIST' <public-html@w3.org>, "Sam Ruby (rubys@intertwingly.net)" <rubys@intertwingly.net>, Adrian Bateman <adrianba@microsoft.com>
Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE03405D3E@TK5EX14MBXC287.redmond.corp.microsoft.com>
Hi Maciej,

We have a test case that we know at least Internet Explorer 6.0 fails open. Here's how it can be reproduced:

1.  Create a page with the following markup:
	<!DOCTYPE html>
			<p>If an alert is displayed, then the browser does not support the sandbox MIME type and has failed open.</p>
			document.cookie = "somefakecookie=test; expires=Thu, 2 Aug 2012 20:47:11 UTC; path=/";
2. Save the file with a .sandboxed file extension.
3. Configure your server to send text/html-sandboxed for the .sandboxed file extension.
4. Browse to the page.

We know at least IE6 will sniff the type as text/html and render the content un-sandboxed. I believe that is sufficient evidence that the API is not truly fail-closed. 

Let me know if you need further information to validate the Change Proposal.


> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Monday, August 01, 2011 1:49 PM
> To: Jacob Rossi
> Cc: Paul Cotton; 'HTML WG LIST'; Sam Ruby (rubys@intertwingly.net); Adrian
> Bateman
> Subject: Re: ISSUE-166 html-sandboxed: Chairs Solicit Proposals
> On Jul 26, 2011, at 3:31 PM, Jacob Rossi wrote:
> > I overlooked a few more mentions of "text/html-sandboxed" in spec text,
> which would need to be removed if this proposal is accepted.
> >
> > Please see the addendum to the details inline below (See steps 7-12).
> Hi Jacob,
> We have reviewed your Change Proposal and found one issue:
> > While implementing the sandbox feature, we investigated addressing the issue
> using the text/html-sandboxed MIME type. The first spec issue we found was
> that it indicates using this in combination with a .sandboxed file extension will
> provide fail-closed sandboxing--that is, browsers which do not support sandbox
> will fail to render the content. We found this to not be true in certain legacy
> browsers due to MIME type sniffing behaviors.
> This portion of your rationale does not have sufficient detail to be able to
> confirm or evaluate the claim. Specifically, you don't say what legacy browsers
> will render content sent with a text/html-sandboxed MIME type or under what
> conditions they would do so. Giving a test case and naming the browsers would
> be very valuable.
> It seems like this piece of rationale is key to your whole argument, since it would
> establish that text/html-sandboxed does not meet its requirement of fail-closed
> semantics, and therefore we should consider other fail-open solutions.
> So it seems very important to provide enough detail for others to fully consider,
> and if necessary respond to, this argument.
> Please revise to address this comment by Monday, August 8th. If we do not
> receive a revision by then, we will close the issue without prejudice for lack of a
> valid Change Proposal.
> Note: We will start the Call for Counter-Proposals in parallel with the one-week
> review deadline. If the issue is closed without prejudice before the Call for
> Counter-Proposals is over, then we will cancel the Call for Counters. Should that
> occur, anyone can reopen the issue simply by providing a valid Change Proposal
> (either a revision of this one or a counter/alternate proposal of some sort).
> Regards,
> Maciej
Received on Tuesday, 2 August 2011 22:40:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:16 UTC