Re: Super-references
The question I tried to answer was: Now, how transpilers are going to solve Object.mixin super call? 'cause once again, that should be solved runtime and I am curious, without caller, how transpilers are thinking to solve that. I assumed you didn’t know, which is why I wrote an answer. On Mar 9, 2013, at 8:14 , Andrea Giammarchi andrea.giammar...@gmail.com wrote: I CAN find super via this, the qwhole point about caller since this morning was about the fact I could do stuff I cannot do anymore. That said, in 2010: http://webreflection.blogspot.com/2010/01/javascript-super-bullshit.html late 2009 wrote early 2010: http://webreflection.blogspot.com/2010/01/better-javascript-classes.html And benchmark about all this in February 2009: http://webreflection.blogspot.com/2009/02/on-javascript-inheritance-performance.html So, just in case, have an extra look too on what developers wrote before your blog did, thank you. Thanks for your examples in any case. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Identifying ECMAScript identifiers
The functions I proposed accept both numbers and strings. http://wiki.ecmascript.org/doku.php?id=strawman:identifier_identification Ah, I see. I missed what is intended at step 2. Looks very nice, thanks. On Sat, Mar 9, 2013 at 6:29 AM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Mar 8, 2013, at 2:35 , Yusuke SUZUKI wrote: In Esprima and Acorn, because of performance issue, their identifier identification functions require a code point as number, not string[2][3]. So I suggest accepting a code point number as an argument. The functions I proposed accept both numbers and strings. http://wiki.ecmascript.org/doku.php?id=strawman:identifier_identification Norbert -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Identifying ECMAScript identifiers
On 9 March 2013 01:59, Ariya Hidayat ariya.hida...@gmail.com wrote: If you check Yusuke's links, that is exactly what Esprima is doing. The use of regular expression is reserved only for the slow/uncommon code path. Yeah I can see you are converting a char code into a string using fromCharCode and comparing it against a regex which is slower and I showed you a function that checks non-alpha variables using charcodes. BTW your isWhiteSpace function also calls to functions indexOf/fromCharcode when it doesn't need to and also indexOf starts at 0 so you have to check if it's greater than -1. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
On 09/03/2013, at 00:54, Andrea Giammarchi wrote: Mark, that is an exhaustive list of links and talks but how many real use cases where we let the user inject any sort of script code in the website and we inject malicious libraries we are not aware, compared with the number of all website that would never suffer any problem with this ? Comparing Java Applets with JavaScript is a no-go, Java had privileged access to the system, nothing caller could achieve in all it's possible evil forms, neither eval could do much there. I think there are no real use cases where caller is dangerous if not few academic purpose attempts to make it safer, and you seemed to work in probably all of them ... ask devs out there how many are using those libraries. As summary, you ask us to bring real cases where caller is needed, I would do the other way around: bring real cases in the real world where caller could be such disaster because trusting user inputs and blindly include external libraries are not, again, real world use cases ... not the majority of them, am I wrong ? I see this like don't use SQKL ever because there could be SQL injections ... sense? None for me :-/ I think the key terms are cooperation under mutual suspicion, mashups, and object capability: the idea is that you'd *want* to be able to run untrusted possibly evil code side by side with your code in your page (e.g. an ad and a payment gateway). Other links: Gears and the Mashup Problem: http://www.youtube.com/watch?v=qfBL2sc2zUU/ Web Forward: http://www.youtube.com/watch?v=yh7TeoEwNyI#t=15m40s Securing JavaScript: http://www.youtube.com/watch?v=T6TTQoqln7c We'd much rather play with unloaded guns than in hopes that nobody else pulls the trigger? -- (Jorge)(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Identifying ECMAScript identifiers
Norbert, Can you explain why you think these should be functions on String rather than part of a more general character classification facility that might be associated with some more specialized object? The latter approach would seem to be to have modularity advantages at both the implementation and usage level. Allen On Mar 7, 2013, at 11:35 PM, Norbert Lindenberg wrote: ECMAScript is used to implement a variety of tools that check code for conformance with the ECMAScript specification, minimize it, perform other transformations, or generate ECMAScript code. These tools have to be able to recognize ECMAScript identifiers, taking the identifier specification and the underlying Unicode specification into consideration - not quite easy given the ever-growing Unicode character set. While looking at support for Unicode character properties in general, I realized that this use case is shaped differently from others, fundamental to ECMAScript, and amenable to a fairly simple solution, and so there's now a strawman: http://wiki.ecmascript.org/doku.php?id=strawman:identifier_identification I'd like to discuss this at next week's TC 39 meeting, but also invite earlier comments. Thanks, Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
but then again, the list of problems is massive here if it's about
trustiness.
Object.prototype can be enriched or some method changed, parseInt and
parseFloat can be redefined to change payment details and stuff,
String.prototype.trim can be faked to read all written fields before these
are sent if the app does the cleanup, Function.prototype.apply/call can be
redefined too so access to unknown functions is granted again ... and all
we worry about is a caller able to access without changing a thing a
possibly unknown and private scope that if executed all it could do is
causing an error?
I am sorry but this looks/sounds/feels like an academic exercise without
concrete and reasonable facts on where this can be a problem. Drop call and
apply too then or think about putting back the powerful caller please,
thanks.
Here how any function can be trapped somewhere else, invoked, and analyzed,
during an app lifecycle.
'use strict';
(function(FunctionPrototype){
function analyze(callback, method, args) {
alert([
callback,
method,
cBound([].slice, args)
].join(\n));
return aBound(callback, args);
}
function call() {
return analyze(this, 'call', arguments);
}
function apply() {
return analyze(this, 'apply', arguments);
}
var
$call = FunctionPrototype.call,
cString = + $call,
cBound = $call.bind($call),
$apply = FunctionPrototype.apply,
aString = + $apply,
aBound = $apply.bind($call)
;
call.toString = function toString() {
return cString;
};
apply.toString = function toString() {
return aString;
};
FunctionPrototype.call = call;
FunctionPrototype.apply = apply;
}(Function.prototype));
// test
(function(){
var pvt = {};
function test(a, b) {
return this.sum = a + b;
}
alert(test.call(pvt, 1, 2)); // 3
alert(pvt.sum); // 3
}());
Best Regards
On Sat, Mar 9, 2013 at 3:58 AM, Jorge Chamorro jo...@jorgechamorro.comwrote:
On 09/03/2013, at 00:54, Andrea Giammarchi wrote:
Mark,
that is an exhaustive list of links and talks but how many real use
cases where we let the user inject any sort of script code in the website
and we inject malicious libraries we are not aware, compared with the
number of all website that would never suffer any problem with this ?
Comparing Java Applets with JavaScript is a no-go, Java had privileged
access to the system, nothing caller could achieve in all it's possible
evil forms, neither eval could do much there.
I think there are no real use cases where caller is dangerous if not few
academic purpose attempts to make it safer, and you seemed to work in
probably all of them ... ask devs out there how many are using those
libraries.
As summary, you ask us to bring real cases where caller is needed, I
would do the other way around: bring real cases in the real world where
caller could be such disaster because trusting user inputs and blindly
include external libraries are not, again, real world use cases ... not the
majority of them, am I wrong ?
I see this like don't use SQKL ever because there could be SQL
injections ... sense? None for me :-/
I think the key terms are cooperation under mutual suspicion, mashups,
and object capability: the idea is that you'd *want* to be able to run
untrusted possibly evil code side by side with your code in your page (e.g.
an ad and a payment gateway).
Other links:
Gears and the Mashup Problem: http://www.youtube.com/watch?v=qfBL2sc2zUU/
Web Forward: http://www.youtube.com/watch?v=yh7TeoEwNyI#t=15m40s
Securing JavaScript: http://www.youtube.com/watch?v=T6TTQoqln7c
We'd much rather play with unloaded guns than in hopes that nobody else
pulls the trigger?
--
(Jorge)();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
Le 08/03/2013 22:19, Andrea Giammarchi a écrit : This opens doors to debuggers (introspection) and APIs magic quite a lot. If you want to write a debugger, use a debugger API [1] which is only executed in privileged environments, no? Debuggers are useful, but pierce encapsulation which is useful for program integrity. I don't think making a debugger API available to all programs is a good idea. David [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Identifying ECMAScript identifiers
Norbert, for the sake of completeness; ZeParser (http://github.com/qfox/zeparser) does support complete unicode identifiers ZeParser2 (http://github.com/qfox/zeparser2) doesn't (I simply didn't bother) - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Questions on Proper Tail Calls
1. Will proper tail calls only happen in strict mode, and if not are we ok with losing backwards compatibility re. [function].caller and [ callingFunction].arguments? 2. Will tail call behavior apply regardless of the tail call syntax? (fn(), fn.call, fn.apply)? 3. Will tail call behavior apply even when the tail call is not recursive? 4. If function fn has a function call in the tail position and is then bound (fn2 = fn.bind(x)), will fn2 also support proper tail calls? (I think this is only relevant if (3) is true) thanks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
I do NOT want to write a debugger and yet I need caller, can you imagine ? Andrea On Sat, Mar 9, 2013 at 10:44 AM, David Bruant bruan...@gmail.com wrote: Le 08/03/2013 22:19, Andrea Giammarchi a écrit : This opens doors to debuggers (introspection) and APIs magic quite a lot. If you want to write a debugger, use a debugger API [1] which is only executed in privileged environments, no? Debuggers are useful, but pierce encapsulation which is useful for program integrity. I don't think making a debugger API available to all programs is a good idea. David [1] https://developer.mozilla.org/**en-US/docs/SpiderMonkey/JS_** Debugger_API_Guidehttps://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
I really don't understand why the debugger thing is being trotted out again. It was addressed at the beginning of the thread: There are lots of real world applications that use debugger-style introspection (in particular, stack walking) for purposes that are not debugging. Now, to be fair, that may not justify exposing any of those features if the security threat posed by having introspection is so incredibly dire. But 'just use a debugger API' isn't really a solution for any of these applications. Debugger APIs are heavyweight and usually have tremendous performance consequences, preventing their use for solving Application Problems. In reality, the answer will have to be 'you can't do that in JavaScript', which probably isn't the end of the world since that's the current answer to anything that needs weak references. -kg On Sat, Mar 9, 2013 at 4:54 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I do NOT want to write a debugger and yet I need caller, can you imagine ? Andrea On Sat, Mar 9, 2013 at 10:44 AM, David Bruant bruan...@gmail.com wrote: Le 08/03/2013 22:19, Andrea Giammarchi a écrit : This opens doors to debuggers (introspection) and APIs magic quite a lot. If you want to write a debugger, use a debugger API [1] which is only executed in privileged environments, no? Debuggers are useful, but pierce encapsulation which is useful for program integrity. I don't think making a debugger API available to all programs is a good idea. David [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- -kg ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
Mark S. Miller wrote: It feels a dramatic divergence from the origin-based security model, Indeed! Origin-based security has been a nightmare. Any access control system with hand-coded access monitoring in a big C++ codebase will be. In SpiderMonkey + Gecko in Firefox, and probably in other browsers, we actually use OCap under the hood and have for years. In HTML5, the WindowProxy/Window distinction was finally specified, as an ad-hoc instance of OCap membranes. Any time we deviate from OCap, we regret it for both security bug and access-checking overhead reasons. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on Proper Tail Calls
On Mar 9, 2013, at 3:00 PM, Angus Croll wrote: 1. Will proper tail calls only happen in strict mode, and if not are we ok with losing backwards compatibility re. [function].caller and [callingFunction].arguments? Apparently yes, there is a note in the draft that we reached that conclusion at a TC39 meeting 2. Will tail call behavior apply regardless of the tail call syntax? (fn(), fn.call, fn.apply)? yes, assuming that the actual call to fn is in a tail position within the call or apply function implementations. I'll review to spec. to make sure. 3. Will tail call behavior apply even when the tail call is not recursive? yes 4. If function fn has a function call in the tail position and is then bound (fn2 = fn.bind(x)), will fn2 also support proper tail calls? (I think this is only relevant if (3) is true) yes, it is only based upon the syntactic structure of the function making the call, not it's bindings thanks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on Proper Tail Calls
Thanks Allen, those are the answers I wanted to hear :) Seems like ES 6 proper tail calls will be a good for CPS too. On Sat, Mar 9, 2013 at 5:22 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Mar 9, 2013, at 3:00 PM, Angus Croll wrote: 1. Will proper tail calls only happen in strict mode, and if not are we ok with losing backwards compatibility re. [function].caller and [ callingFunction].arguments? Apparently yes, there is a note in the draft that we reached that conclusion at a TC39 meeting 2. Will tail call behavior apply regardless of the tail call syntax? (fn(), fn.call, fn.apply)? yes, assuming that the actual call to fn is in a tail position within the call or apply function implementations. I'll review to spec. to make sure. 3. Will tail call behavior apply even when the tail call is not recursive? yes 4. If function fn has a function call in the tail position and is then bound (fn2 = fn.bind(x)), will fn2 also support proper tail calls? (I think this is only relevant if (3) is true) yes, it is only based upon the syntactic structure of the function making the call, not it's bindings thanks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
On Sat, Mar 9, 2013 at 4:56 PM, Kevin Gadd kevin.g...@gmail.com wrote: I really don't understand why the debugger thing is being trotted out again. It was addressed at the beginning of the thread: There are lots of real world applications that use debugger-style introspection (in particular, stack walking) for purposes that are not debugging. Now, to be fair, that may not justify exposing any of those features if the security threat posed by having introspection is so incredibly dire. But 'just use a debugger API' isn't really a solution for any of these applications. Debugger APIs are heavyweight and usually have tremendous performance consequences, preventing their use for solving Application Problems. Another way to view the phrase debugging API is properly stratified privileged reflection API. Indeed, the famous Mirrors paper used JPDA as an example of a properly stratified reflection system. The key thing about debugging APIs is they get the privilege separation right -- because they must. A well designed mirror system or mirror-like system could as well. I have discussed this repeatedly with the co-authors of that paper -- Dave Ungar and Gilad Bracha (cc'ed) -- and IIRC they enthusiastically agree. The KeyKOS operating system had an operation for rights-amplifying a start key or resume key to a domain key. In our terms, a start key is like a closure reference and a domain key is like a reference to the reified lexical environment captured by that closure, i.e., a mirror on the state of that closure. A resume key is like a continuation, so reflecting on resume keys -- if you have the privileges needed to do so -- enables one to effectively walk back the stack of outstanding IPC requests. The logic by which KeyKOS (and its descendants EROS, CapROS, GuardOS, Coyotos) managed the right-to-reflect could be a good starting point for doing likewise with language-based mirrors. This would be an excellent research topic for someone to take on. If someone takes it on seriously, I may well be interesting in advising the effort. However, the work of TC39 is not the right place to do this kind of research (unless its crucial to an urgent goal, which this one isn't). Once such research bears fruit, we can then consider whether to take this to TC39 as a proposal for ESx, for some future x. In reality, the answer will have to be 'you can't do that in JavaScript', which probably isn't the end of the world since that's the current answer to anything that needs weak references. I expect to propose weak references for ES7. I think I have an adequate answer to the security issues that took this off the table for ES6. More later. -kg On Sat, Mar 9, 2013 at 4:54 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I do NOT want to write a debugger and yet I need caller, can you imagine ? Andrea On Sat, Mar 9, 2013 at 10:44 AM, David Bruant bruan...@gmail.com wrote: Le 08/03/2013 22:19, Andrea Giammarchi a écrit : This opens doors to debuggers (introspection) and APIs magic quite a lot. If you want to write a debugger, use a debugger API [1] which is only executed in privileged environments, no? Debuggers are useful, but pierce encapsulation which is useful for program integrity. I don't think making a debugger API available to all programs is a good idea. David [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- -kg ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
It should be pointed out that KeyKOS resume keys could, like
proper tail-call optimization, eliminate the ability to walk
the stack to determine the caller. In KeyKOS, the process had
direct control over usage of the resume key. It could pass it to
an object is was calling in place or creating a resume key to
itself with a normal call. This loss of ability to walk the
stack is much like tail-call optimization of:
function a(args) {
... some calculation
return b(otherargs);
}
Where the optimization passes the address of a's caller as the
return address for b and b can't see a's activation record on
the stack.
Cheers - Bill
On 3/9/13 at 6:57 PM, erig...@google.com (Mark S. Miller) wrote:
Another way to view the phrase debugging API is properly stratified
privileged reflection API. Indeed, the famous Mirrors paper used JPDA as
an example of a properly stratified reflection system. The key thing about
debugging APIs is they get the privilege separation right -- because they
must. A well designed mirror system or mirror-like system could as well. I
have discussed this repeatedly with the co-authors of that paper -- Dave
Ungar and Gilad Bracha (cc'ed) -- and IIRC they enthusiastically agree. The
KeyKOS operating system had an operation for rights-amplifying a start
key or resume key to a domain key. In our terms, a start key is like a
closure reference and a domain key is like a reference to the reified
lexical environment captured by that closure, i.e., a mirror on the state
of that closure. A resume key is like a continuation, so reflecting on
resume keys -- if you have the privileges needed to do so -- enables one to
effectively walk back the stack of outstanding IPC requests. The logic by
which KeyKOS (and its descendants EROS, CapROS, GuardOS, Coyotos) managed
the right-to-reflect could be a good starting point for doing likewise with
language-based mirrors.
---
Bill Frantz| Concurrency is hard. 12 out | Periwinkle
(408)356-8506 | 10 programmers get it wrong. | 16345
Englewood Ave
www.pwpconsult.com |- Jeff Frantz | Los Gatos,
CA 95032
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Nuking misleading properties in `Object.getOwnPropertyDescriptor`
Given that `defineProperty` uses properties on the prototype of the
descriptor[1] and `getOwnPropertyDescriptor` returns an object which inherits
from `Object.prototype`, the following use-case is volatile:
function copy(from, to) {
for (let name of Object.getOwnPropertyNames(from))
Object.defineProperty(to, name,
Object.getOwnPropertyDescriptor(from, name));
}
If a third party script happens to add `get`, `set`, or `value` to
`Object.prototype` the `copy` function breaks.
Object.prototype.get = function() { };
var x = { foo: 1 };
var y = { };
copy(x, y); // TypeError: property descriptors must not specify a value or
// be writable when a getter or setter has been specified
It's misleading that you can't trust `getOwnPropertyDescriptor` to give you a
descriptor which you can use to define a property with `defineProperty`.
A script which doesn't use `defineProperty` could very well define a `get`
property on `Object.prototype`, unknowingly breaking other scripts which do use
`defineProperty`. This is a hazard in the language.
I think one of the following would be an appropriate solution:
(1) Nuke the special properties (`get`, `set`, and `value` when any of them
is not defined) on a descriptor returned by `getOwnPropertyDescriptor` which
shouldn't be inherited through the descriptor's prototype. By nuke them, I
mean specify that they be defined as `undefined`, much like `callee` and
`caller` in strict mode. (I don't think strict mode is required in this case,
though, since I highly doubt anyone could be relying on this behavior.)
(2) Use the introduction of `Reflect.defineProperty` as an opportunity to fix
this function to only inspect own properties on the property descriptor so that
the descriptor's prototype doesn't matter. This is similar to the addition of
`Number.isNaN` to fix the broken `isNaN`.
Nathan
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026705.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Nuking misleading properties in `Object.getOwnPropertyDescriptor`
(1) Nuke the special properties (`get`, `set`, and `value` when any of them is not defined) on a descriptor returned by `getOwnPropertyDescriptor` which shouldn't be inherited through the descriptor's prototype. By nuke them, I mean specify that they be defined as `undefined`, much like `callee` and `caller` in strict mode. (I don't think strict mode is required in this case, though, since I highly doubt anyone could be relying on this behavior.) Naturally, `defineProperty` would also have to be rewritten a little to ignore properties set to `undefined`. If `get`, `set`, and `value` are all set to `undefined`, then `value` would be assumed to be `undefined`. In addition, `writable` would also have to be nuked for accessor descriptors. I think it's workable? Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
