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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 01 Aug 2011 13:49:06 -0700
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: <0EEFB340-E119-4ED4-A80D-C4FCBA728DFC@apple.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>

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 Monday, 1 August 2011 20:50:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:37 GMT