<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>On the surface, this seems fairly reasonable., of course IE
doesn&#8217;t have any skin in the mutable __proto__ game.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Would you really associate this with Object.freeze or would you
make it a characteristic of the [[Extensible]] internal property&nbsp; being
false? Personally, I&#8217;d probably&nbsp; be inclined to go with the latter.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>My one concern also relates to you other message concerning
debugging APIs.&nbsp; Does no modification of [[Prototype]] really mean never.&nbsp;
I certainly can envision debugger APIs or other support for incremental/evolutionary
development tools that could make use of a mutable [[Prototype]] (as well as mutability
of other immutable states such as a false [[Extensible]] internal property) . &nbsp;I&#8217;m
quite happy to agree that these items should not be directly mutable from the internal
perspective of an application program but I&#8217;m less willing to agree that
a &#8220;privileged&#8221; tooling API (including possibly a mirrors
reflection&nbsp; based API) could never mutate such state. &nbsp;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
es-discuss-bounces@mozilla.org [mailto:es-discuss-bounces@mozilla.org] <b>On
Behalf Of </b>Mark S. Miller<br>
<b>Sent:</b> Monday, June 15, 2009 7:52 PM<br>
<b>To:</b> es-discuss; es5-discuss@mozilla.org<br>
<b>Subject:</b> Another de-facto insecurity we need to fix in ES5<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>As I just mentioned on the debugging API thread, at the last
EcmaScript meeting we agreed<br>
<br>
On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat &lt;<a
href="mailto:waldemar@google.com" target="_blank">waldemar@google.com</a>&gt;
wrote:<o:p></o:p></p>

<p class=MsoNormal>Rather than describing the evil things that implementations
do with F.caller, we agreed to just impose a blanket prohibition of code
peeking into the environment records or identity of strict functions on the
stack. &nbsp;This way a test suite can ensure that F.caller does nnot reveal
strict functions without us having to introduce the evil things into the
standard. &nbsp;I'll write up proposed wording.<o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
This is an example of a more general principle. The language we're evolving
from isn't ES3, it's ES3 as currently practiced. When browser vendors implement
ES5, they won't actually implement ES5 as speced. They will implement ES5 as
extended to preserve some of the defacto practices they currently support. When
these likely future defacto extensions would lose some of the integrity or
security gains we're trying to achieve with ES5, then we should find an
adjustment to the ES5 spec that does not break these defacto practices for old
code but still allows new code to defend itself from attackers using these
defacto extensions.<br>
<br>
The ES3 and ES5 specs both specify the implicit [[Prototype]] property as
something that is initialized once and then unchanged. All major browsers today
but IE alias this to the name &quot;__proto__&quot; (as if that's a named
property) and allow it to be mutated. None of the rest of the ES5 semantics has
been critically examined in light of the possibility that an implementation may
allow this mutation. So long as [[Prototype]] is pervasively mutable, then most
interesting behavior of an ES5 object won't be stable as well. I recommend:<o:p></o:p></p>

<div style='margin-left:24.0pt'>

<p class=MsoNormal>Object.freeze(foo) guarantees not only that all of foo's
named properties be frozen and that foo is non-extensible, but also that foo's
[[Prototype]] will not be changed.<o:p></o:p></p>

</div>

<p class=MsoNormal><br>
For non-frozen objects, we continue not to specify that [[Prototype]] can be
mutated or explain any means for mutating it. But neither can we prohibit such
mutations unless FF, Safari, and Opera are willing to give up this feature. The
proposal above won't break any old code that depends on mutating __proto__ but
will enable new code to protect itself. I would like to propose something
stronger, but don't know of anything stronger compatible with this constraint.<br
clear=all>
<br>
-- <br>
&nbsp; &nbsp;Cheers,<br>
&nbsp; &nbsp;--MarkM<o:p></o:p></p>

</div>

</div>

</body>

</html>