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: Wed, 3 Aug 2011 06:11:17 +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: <D0BC8E77E79D9846B61A2432D1BA4EAE034065F4@TK5EX14MBXC287.redmond.corp.microsoft.com>
I've put the change proposal on the wiki and incorporated the test case:


To be clear, the incorrect advertisement of text/html-sandboxed is only part of our argument against it. The inability to specify allow-tokens or to sandbox content other than text/html severely limits the usefulness of the MIME type as well.



-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Tuesday, August 02, 2011 10:48 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

Can you incorporate this into the Change Proposal itself? You can either include it inline or as a link to a document with these contents.

Note: if you put your Change Proposal on the wiki, it will be much easier to revise it as you go than keeping it in email. I would suggest that approach for any but the simplest Change Proposals.


I'm also curious whether the fact that text/html-sandboxed does not prevent content from loading unsandboxed in IE6 affects the opinions of text/html-sandboxed advocates. If it does, then perhaps we could find consensus to remove it and move to an amicable resolution.


On Aug 2, 2011, at 3:39 PM, Jacob Rossi wrote:

> 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>
> 	<html>
> 		<head>
> 			<title></title>
> 		</head>
> 		<body>
> 			<p>If an alert is displayed, then the browser does not support the sandbox MIME type and has failed open.</p>
> 			<script>
> 			document.cookie = "somefakecookie=test; expires=Thu, 2 Aug 2012 20:47:11 UTC; path=/";
> 			alert(document.cookie);	
> 			</script>
> 		</body>
> 	</html>	
> 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.
> -Jacob	
>> -----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 Wednesday, 3 August 2011 06:11:59 UTC

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