My first reaction to this assertion is to say: "so?" It's a rather moot
argument to suggest that code which can be altered before it's run isn't
trustable... of course it isn't. [...] because any malicious script (if
it's first on the page) can completely hijack another part of the page?
Yup, I agree.
That was my point. Since you agree, I don't understand your point:
My point was that your argument was deflecting from the premise of the
original request in a way that makes the conversation impossible to proceed.
If you re-define the premise/assumptions to an unreasonable level, you make
logical reasoning impossible. For instance, arguing that a virus could
infect the JS engine of the browser is a *possible* scenario, but not a
useful one to discuss in this context, because it fundamentally violates the
premise. Similarly, arguing that a network router could be hacked to change
code in-transit is conceivable, but moot and pointless to the spirit of my
question.
The premise of the question is, whatever the state of the code on the page
is (or how it got there), is there a way to prevent some piece of code from
intentionally or unintentionally altering some important behaviors of native
objects such that subsequent code could be tricked or tripped up?
Furthermore, the spirit of the question was, granted there is no 100% system
for that, but can we move the ball a little closer to the goal line with a
very narrow idea of restricting a few things, in opt-in modes of JavaScript?
What protections do you have in mind?
Specifically, I think:
1. All changes to Object.prototype.* should be ignored/error'd, such that
the predefined members of Object.prototype.* (the native built-ins) are
immutable. This would not necessarily prevent extensions to
Object.prototype, simply prevent redefinitions of existing native
functionality.
2. OR; Let Object.prototype.* members continue to be mutable, but let those
effects ONLY affect user objects, and not built-in native objects (like
String, Array, etc). However, a few of Object.prototype.*'s members should
still be considered for immutability, like for instance `toString()`, which
is commonly used in the scenario of borrowing its functionality via
`.apply()`, as described earlier with `window.opera`.
3. OR; There are other more exotic ideas I could advance, such as keeping
Object.prototype.* mutable, but then exposing an additional interface like
Object.__prototype__ (which is the original prototype, and is immutable).
And how, were your protections to be adopted
I was specifically suggesting they be part of one of the future opt-in
modes, either for Harmony/Next, or more appropriately even, perhaps a future
"strict mode"... or even call it "safe mode". `"use safe";` has a nice ring
to it.
would all bets no longer be off when loading a virtuous library into a
frame in which malicious code had already run first?
in the narrow context of what I'm suggesting, the protections afforded by
the JavaScript engine would limit the ability of prior-malicious (or stupid)
code from influencing some of the natives which my code might need to rely
on.
As for accident, it depends how dumb that earlier piece of code was. If
it modifies primordial methods so that they no longer satisfy their
contracts in way that later code is ignorant of and unprepared for
Not all modifications are easily feature-testable such that later code would
have any hope of preventing its own ignorance.
OTOH, if these earlier dumb scripts are not that dumb, then the later
smart library should still be able to succeed.
To me, the notion of a "smart library" (even for the purposes of safety) is
rather absurd. A fundamental assumption here is that there are in fact a
certain subset of things which no JavaScript code should be allowed to do,
so as to "play nicely" with other code. Extending Object.prototype has
almost universally been taken as one such thing. Circumventing
`location.href` inspection would be another good candidate.
We can't then say "well, we'll make an exception for this one smart library,
and let him much with that stuff"... because then the "smart library"
becomes the single-point-of-failure(aka attack).
That's why I approached this narrow question as specifically opt-in
protections from the engine (non-circumventable), rather than in the
user-space.
--Kyle
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
