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

I've put the change proposal on the wiki and incorporated the test case:

http://www.w3.org/html/wg/wiki/ChangeProposals/text_html_sandboxed 

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.

Thanks,

Jacob

-----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.

http://www.w3.org/html/wg/wiki/

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.

Regards,
Maciej


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