-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:
On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <[email protected]>
wrote:
On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
I suspect we'll see some de-facto stuff come out of one or two
vendors who
aren't active in TC39 (Apple, Google V8).
Google is quite active in TC39. Google's representatives to TC39
(including me) are now in close coordination with our v8 team.
However, v8
remains committed to following WebKit. Fortunately, AFAIK, WebKit
has not
yet taken any stance on whether [[Prototype]] will be mutable in
their ES5
implementation. Maciej?
Your phrasing of the question strikes me as odd, because changing
behavior
of de facto extensions like this seems orthogonal to supporting a new
version of the spec. If getting rid of or restricting mutable
__proto__
turns out to be feasible and a good idea, then we would not tie it to
implementation timeline for ES5 features.
The tie to ES5 is that ES5 introduces the notion of frozen objects.
Together
with ES5/Strict function's encapsulation being protected even from
non-strict code, this enables the creation of tamper-proof objects.
But only
if frozen objects cannot have their [[Prototype]] property changed
out from
under them.
The fact that ES5 has the provision for frozen objects doesn't mean
that all (or substantially most) objects in the system will be frozen.
I think it's worth considering how useful killing __proto__ will be
should the Harmony class system NOT freeze objects by default. I
suspect not very.
Regards
As to the substantive issue: mutable __proto__ is something we
would prefer
not to have, but we are concerned about the compatibility issues.
We look
forward to hearing about Mozilla's experience with changing it.
In case this experiment does run into problems, what do you think
about
Allen's proposed restriction: "That [[Prototype]] is guaranteed not to
change on an object for which [[Extensible]] is false."? This takes
care of
the security issue I'm concerned about and won't break any old code.
Personally, I think leaving "distasteful" but cross-browser
features like
this out of the spec in the hopes that they will wither away from
neglect is
a poor approach. If browsers feel pressured to implement such
extensions for
Web compatibility then we are not doing anyone any favors by
leaving them in
the domain of mutual reverse-engineering. I would prefer to see such
features explicitly specified (with suitable restrictions) or
explicitly
forbidden, and perhaps explicitly deprecate them with the plan for
further
limits or outright removal in future versions of the spec. But it
seems too
late to make big changes in this regard for ES5.
Agreed.
Maybe in the next version.
+100. An exhaustive list of such features should at least be
enumerated in a
non-normative appendix. If they had, it wouldn't have taken us so
long to
catch the mutable [[Prototype]] and F.caller issues. What other such
issues
might we have missed?
In a closely related matter, we also need to tighten the Chapter 16
exemptions, as the presence of these exemptions precludes *any* sound
reasoning about JavaScript security. However, I have no clever ideas
of what
such tighter language should say. Suggestions appreciated.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
- --
Alex Russell
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFKOb3Mz3jiQlnDlyMRAjs4AKDGJVIMRmDbidcLxHcLh3abwlEtjACgsyty
76mkqqKjDCJNmK0du23n0aE=
=DPv/
-----END PGP SIGNATURE-----
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
