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: Tue, 02 Aug 2011 22:47:34 -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: <CD3C1670-7202-49DC-A7C9-FDA4C31417F5@apple.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>

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 05:48:04 GMT

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