On Fri, Nov 4, 2011 at 8:14 AM, Claus Reinke <claus.rei...@talk21.com>wrote:
>
>> Hm. A favorite pattern that I haven't thought about enough, it seems.
> My curiosity did cost me some sleep:-| My favorite work around for
> your constraints is this little shim:-)
>
> // dynamic language
> Object.freeze = function(obj){return obj};
>
> You imply that this is not intended, so I can show it without spoiling
> the fun. I was surprised that this works.
>
Since the primordials are already frozen, this assignment fails.
>
> The first solution that came to mind ought to be defeated by your
> "transitively frozen" constraint, and it is, in current JS implementations,
> though not all JS implementations in the wild are there yet - do you
> "feature-detect" old engines and issue warnings if they invalidate
> your base assumptions?
>
Yes, as shown by <
http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html>.
For example, Firefox 7.0.1 shows "Max Severity: Not isolated(4) is not
SES-safe."
Chrome 16 shows "Max Severity: Safe spec violation(1)."
Firefox Nightly 10.0a1 shows no Max Severity line because it encountered no
unrepairable problems.
If you do a view source, you'll see the text
// This severity is too high for any use other than development.
ses.maxAcceptableSeverityName = 'NEW_SYMPTOM';
For production use, depending on you're purpose, you'd probably let the max
acceptable severity default, in which case initSES.js will fail quickly as
soon as it detects that this platform cannot be made SES-safe. Once
initSES.js terminates, ses.ok() indicates whether the max acceptable
severity has been exceeded. The severity levels can currently be found at <
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#85
>
We are currently in the process of integrating SES in with the rest of
Caja. If you're only targeting SES-safe browsers you can still use
initSES.js by itself. Otherwise, if you deploy through Caja, the plan is
that Caja will detect whether this is a SES-safe platform, deploy without
translation using SES if so, and otherwise fall back to Caja's ES5-to-ES3
translator.
>
> The second approach took longer to find but relies on non-standard
> features (and again, I suspect a bug/interpretation issue).
>
What is your second approach?
>
> Both ideas are weak, in that they could be blocked by type checks.
How?
>
>
> If you've already seen this puzzle and know the answer, please don't
>> post. If no one else has posted the correct answer in 24 hours, I will.
>>
>
> Neither of my approaches seems to be the droid you are looking for,
> given your "no realistic fix" remark, so I'm curious what else I've missed.
I should take this opportunity to reveal that David Herman found a bug last
night with my challenge. Due to a "feature" of ES3 which ES5.1 preserves,
and which I keep forgetting about because it has always seemed only to be
annoyance, the attack I had in mind actually fails on an ES5.1 conformant
browser. Another reason I missed it is my attack succeeds on Chrome/v8,
because it does not implement this "feature". Dave found it because
FF/SpiderMonkey is ES5.1 conformant in this regard. After he rediscovered
the attack, it failed when he tried it on SpiderMonkey, reminding both of
us of this annoyance. Perhaps this annoyance really is a feature after all?
I asked him to keep quiet about it for the remainder of the 24 hours
because I was curious to see what people came up with.
Congrats to Dave!
>
>
> Note that I don't see any realistic way to fix problem #3 in the ES.next
>> language. My point is only that defensive programming is tricky even after
>> you've gotten all the formal properties you need. As ES.next introduces
>> various new abstraction mechanisms, whether classes, enhanced object
>> literals, proxies, modules, or private names, the design of these can
>> either help or hurt those attempting to write defensive abstractions. Any
>> class abstraction that is only useful for making indefensible instances is
>> worse than useless -- it is actively harmful, both to security and to
>> serious software engineering.
>>
>
> You also rely on you security base framework being the first to run,
>
Yes, absolutely.
> and on nobody trying to modify source on load, right?
>
I think the answer to this is "yes" as well, but first I should ask for
clarification: source to what?
>
> Claus
> http://clausreinke.github.com/
> http://clausreinke.github.com/**js-tools/<http://clausreinke.github.com/js-tools/>
>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
