Re: JSON specification WAS: Re: JSON Duplicate Keys
On 7 June 2013 11:43, Brendan Eich bren...@mozilla.com wrote: ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3. Oh that makes it better then =) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON Duplicate Keys
On 7 June 2013 15:19, Jason Orendorff jason.orendo...@gmail.com wrote: On Thu, Jun 6, 2013 at 10:21 AM, gaz Heyes gazhe...@gmail.com wrote: That is totally stupid. IMO the JSON spec should support comments like // and /**/ and also support single quotes for string values. It's JavaScript for christ sake. It makes no sense to invent and support this crappy syntax. Please use respectful language on this list. Good sir that is totally stupid. IMO the JSON spec should support comments like // and /**/ and also support single quotes for string values. It's JavaScript for heavens sake. It makes no sense to invent and support this rather than ideal syntax. Thank you sir. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON Duplicate Keys
On 6 June 2013 12:29, Douglas Crockford doug...@crockford.com wrote: The JSON RFC says The names within an object SHOULD be unique. Sadly, there are people in the JavaScript community who interpreted SHOULD to mean DON'T HAVE TO. In a perfect world, we would change the SHOULD to MUST, but we can't. Interoperability and security concerns demand that we specify what happens when keys are duplicated. So we may end up with something like this: The names within an object SHOULD be unique. If a key is duplicated, a parser SHOULD reject. If it does not reject, it MUST take only the last of the duplicated key pairs. Does anyone see a problem with this? That doesn't make sense should should be must because if it's taking the last key then you can overwrite someone else's data. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
JSON specification WAS: Re: JSON Duplicate Keys
Hey all
Since Doug is here I thought I'd use the opportunity to discuss the broken
JSON spec.
When ES5 introduced line/para separators for valid new lines in JavaScript
this broke the JSON specification. The code sample used within the RFC is
also broken since line/para separators would cause eval to fail. It needs
to be fixed IMO. While taking this opportunity to fix the specification by
forcing line/para to unicode escapes e.g \u2028, \u2029 we should also
force into \x3c and into \x3e. I propose the following changes:
1. Remove the awful invalid code sample.
2. The string section instead of Any character may be escaped. there
should be some exceptions. and must be encoded with hex/unicode
escapes. Line/Para separators must be encoded to unicode escapes and
finally right-to-left and left-to-right mark should also required to be
encoded in unicode escapes.
I think we also need to discuss the keywords present in json keys for
example:
{__proto__:[]}
Should proto be a banned keyword in JSON keys? I think giving data the
ability to control it's type could break things when it's used elsewhere.
There is also an argument for requiring hex escapes for characters lower
than 0x09 but I guess a lot of people will be against that.
Thanks
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JSON specification WAS: Re: JSON Duplicate Keys
On 6 June 2013 14:25, Jeremy Darling jeremy.darl...@gmail.com wrote: Thinking about this for JSON that means that if you were wanting to serialize a complete object (prototype, setters, getters, etc) you would then have to escape all of those as well. Since JavaScript doesn't really have a standard symbol for stating This is a control key then dev's would have to code for all possible key words in their escape/unescape sequence. Or the spec would have to be amended to contain some type of isReservedKey statement. This just introduces a whole new can of worms and more breaking points. Yeah I agree it's a can of worms but I wanted to throw it out there for discussion. As we get more keywords and functionality it could bite in the butt in a few years time. I don't exactly understand your point in bullet 2? Why do and have to be encoded, they are perfectly valid values inside of a string today, and again many libraries make use of this functionality for transporting HTML, XML, and Text fragments. To Crockfords point, should not break becomes the issue with changing what should and should not be encoded. For two reasons 1) Some browsers will render json as html (sniffing) 2) Inline JSON data will be parsed in a different order than it's intended. For example will be parsed first as html and then javascript. Encoding and will have no effect on passing xml/html data but will prevent those issues. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON Duplicate Keys
On 6 June 2013 16:13, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Some that should be pointed out is that one reason JSON needs to accept
duplicate field names is that some people currently use them to add
comments to JSON datasets:
{
//: This is a comment about my data,
//: that takes more than one line,
field1 : 1,
field2 : 2
}
That is totally stupid. IMO the JSON spec should support comments like //
and /**/ and also support single quotes for string values. It's JavaScript
for christ sake. It makes no sense to invent and support this crappy
syntax.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JSON Duplicate Keys
On 6 June 2013 16:29, Allen Wirfs-Brock al...@wirfs-brock.com wrote: No it's not JavaScript! It a file format for storing and interchanging data. Preserving existing data is a key requirement. It's syntax is based on JavaScript but crippled for no reason other than to follow a outdated specification. It's so frustrating to be at this end of a keyboard to see awful syntax being promoted just to follow the RFC which is clearly flawed. It's so much more logical to change and fix the problems in the specification so that in future code will work correctly and JSON parsers would be much easier and consistent. Don't break the web shouldn't ever become Keep the web broken code will never evolve if the core is rotten. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A Precedent
On 12 April 2013 09:01, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
// all Mobile WebKit browsers
*if* ('__proto__' *in* Object.create(*null*)) {
console.log('you gonna have hard time');
}
If this is true that means it breaks the *only *way of creating a secure
lookup table.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Machine readable specifications
Hi all
I'd like to discuss a radical change on how JS specifications and others
are constructed. I suggest int based rules are used to define language
behaviour. I know this works with last state and next state tracking and
expected states too maybe other behaviour could be defined this way as
well. The first part of the specification should define a list of ints that
correspond to the state starting from 0 with 0 being a start state of
Nothing. The initial states should be specified as follows:
initalStates = {0:Nothing,1:FunctionExpression, 2:FunctionStatement,
3:FunctionStatementIdentifier ...
Once every state is defined as an int, each state can be used in a lookup
table to determine the allowed last state and/or expected states. The
lookup table is used for error messages by the parser to convert the
corresponding int to human readable form. To define that FunctionStatement
can follow Nothing but FunctionExpression can't follow nothing and
FunctionStatementIdentifier is expected after FunctionStatement.
rules = {
//FunctionStatement State
2:{
lastStates: {
//FunctionStatement is allowed
after last state Nothing
0: true
},
expectedStates: {
//FunctionStatement expects the
next state to be FunctionStatementIdentifier
3:true
}
}
};
lastStates and expectedStates would also be ints but I added the text
for clarity, true could be shortened to 1 for compression. To use these
rules the parser can simply check the state machine which was the last
state and if the next state is valid. E.g.
lastState = 0;//Last state was Nothing
state = 2;//FunctionStatement state
if(rules[state].lastStates[lastState]) {
// FunctionStatement is allowed to follow Nothing
}
lastState = 0;//Last state was Nothing
state = 1;//FunctionExpression state
if(!rules[state].lastStates[lastState]) {
//FunctionExpression is not allowed to follow Nothing
error();
}
The same technique could be used for expected states since you'd just need
to lookup the next state with the assigned expected state from the last
state.
Once a machine readable specification has been done we could then generate
a human readable form of it based on the rules and it could be checked that
it conforms to what was intended. Both specifications (human readable and
machine readable) could be used by the implementer, when a specification
changes the parsers could automatically update based on the machine
readable form. Emulation for older parsers could be added within the
browser itself by using the new specification rules in a parser shim.
Thoughts?
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:33, Andreas Rossberg rossb...@google.com wrote: Aren't you confusing machine readable specification with machine readable syntax specification? Syntax is only a small part of a language spec, and quite frankly, the least interesting one by far. Also, I don't see the benefit of your format. The EcmaScript spec actually goes to quite some length to give a grammar that is LR(1). The whole point is to keep it de facto machine readable. But unlike yours, it also is human readable. That was the reason to discuss, I think it could be applied to more than just syntax rules. You don't like it and that's fine with me I just wanted to post my ideas. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:36, Wes Garland w...@page.ca wrote: The specification is hard enough to digest for average developers now; I'd hate to point one of my guys at a machine-readable document when he's having trouble with some corner-case. You wouldn't do that, you'd point them to the human readable form. The machine version is specifically designed to be read by machines with low overhead to update functionality without touching code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:57, Wes Garland w...@page.ca wrote: Is there a formalized way to translate between the human and machine-readable specifications? If they are found to have different meanings (not hard to imagine), which specification would be considered authoritative? The human readable form would be generated from the machine readable form. The human form should be a descriptive representation of the actual rules defined by the machine readable form. There should be no confusion only human error in understanding the descriptive text. The machine readable form should be authoritative since the idea is to implement whatever code based on the rules from the machine readable specification. To translate what I wrote in the initial mail into human form would be something like: Function Statement can follow Nothing and then expects Function Statement Identifier to follow. and Function Expression cannot follow Nothing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Sandboxing and parsing jQuery in 100ms
Hi all I thought I'd share an update of my mental js work. I have since reduced the parse time of mental and now added a DOM sandbox that uses ES5 to allow safe manipulation of the DOM. This is so cool because it means that mental can take control over your dom and then we can choose what we allow. Want to restrict images to same origin? No problem, want to prevent script nodes from the ability to call external resources no problem :) There's a cool demo on modsecurity where they have an injection hole and inject mental into the response to prevent harmful xss. http://www.modsecurity.org/demo/demo-deny-noescape.html?test=%3Cscript%3Ealert%28location%29%3C%2Fscript%3E I managed to get the parse time of jQuery to min of 24ms on chrome, on Firefox it can parse and sandbox jQuery in about 90ms although there are a couple of problems with the selectors which I need to debug. Any comments or suggestions are welcome. Cheers Gareth ___ 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: Identifying ECMAScript identifiers
You forgot to include MentalJS. I can parse 120k identifier in 5ms on Firefox on my crappy machine. My method is much faster than any of the parsers you listed and I handle unicode escapes too. http://businessinfo.co.uk/labs/MentalJS/MentalJS.html On 8 March 2013 07:35, Norbert Lindenberg ecmascr...@lindenbergsoftware.com 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: Identifying ECMAScript identifiers
On 8 March 2013 10:35, Yusuke SUZUKI utatane@gmail.com wrote: Yeah. We, Esprima developers, parse UnicodeData.txt to generate identifier identification functions. I wrote simple UnicodeData.txt parser and generated RegExp[1]. These functions are also used in Acorn. RegEx is slower. I suggest using if statements on char codes and and to check it's within the range of z-a etc and then separate functions to handle higher ascii variables only when needed and then compare the char codes are within the ranges of allowed identifiers. https://code.google.com/p/mentaljs/source/browse/trunk/MentalJS/javascript/Mental.js#504 I still have to optimize that function further by removing = and = and maybe separating each identifier range into their own function since higher non-alpha variables take longer to parse since they are at the end of the if statement. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How can a lexer decide a token to be get, IdentifierName or Identifier ?
On 4 February 2013 23:44, Brendan Eich bren...@mozilla.com wrote:
What's confusing?
The fact that you can have an object property without a colon and a
function without a function keyword. Then a property descriptor uses a
completely new syntax to define the same thing. Why?
Object.defineProperty(window,'x',{set:alert});
x=1;
To me this seems hacked together.
({'get'x(){return 123;}}).x
That's not legal ES5.
Some engines support it though and I'm pretty sure Firefox did at some
point.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How can a lexer decide a token to be get, IdentifierName or Identifier ?
On 4 February 2013 21:56, Michael Dyck jmd...@ibiblio.org wrote:
Brendan Eich wrote:
Don't forget method definition shorthand syntax, if the next token is
(. Then the method is named get, of course.
I find the syntax of set/get confusing:
({'get'x(){return 123;}}).x
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Paper: Parsing JavaScript by counting character pairs
Hi all,
I'm terrible at writing papers but I thought I'd share this because I think
the technique is good I just want it out there. Hopefully it makes sense
but probably not.
Parsing JavaScript by counting character pairs
==
Abstract
The traditional way to parse JavaScript is using a lexer and converting
characters to tokens first and then use those tokens to define the grammar.
The paper describes a unique way of parsing JavaScript allowing
tokenization on the fly and obtaining the current state by using pairs of
characters and their positions when the last state occurred. This paper
challenges the accepted norm of parsing and hopes to introduce new ideas
and improve how fast JavaScript engines can execute code.
Language symmetry
-
The parsing technique described requires a certain level of symmetry in
order to be effective and it would work best when the characters used to
describe the language are unique. JavaScript isn't completely symmetrical
in the fact that it's syntax overlaps with other parts. A good example of
this is the ternary operator it overlaps when using the colon character
with a labeled statement or object literal identifier however the parsing
speed would be more effective if the language had chosen characters that
didn't overlap and were always symmetrical.
Defining character pairs
Pairs of characters refers to when a character requires another character
in order to be valid syntax, for example an array literal opening character
is [ and it's closing character is ] which this paper refers to them as
a pair and the opening and closing of that pair is used to track state.
The ending character of each pair can know it's starting character's last
state therefore determining it's current state based on what happened
before it's starting character by using the counts of every pair of
characters you can use this method to obtain states from not only the
starting character but the current executing block of code.
The following characters are character pairs in JavaScript [ and ], (
and ), { and }. Each character pair requires a lookup variable to
store the current state being tracked relative to the position count.
The count position is obtained by incrementing a counter for when each pair
opens and decrementing it when it closes. We will refer to the pair [] as
square lookup (when wanting to obtain current JavaScript state) and square
count when changing the count of the opening and closing state. Likewise
() will be referred to as paren lookup and paren count and {} will be
referred to as curly lookup and curly count.
Left flag
-
A left flag variable is used when the previous state has a value that can
be used in conjunction with the next state. A good example of this is the
divide operator as it requires a valid object on the left hand side in
order to be valid or it is not an operator. If the left flag is not set for
the / character then it assumed that this character is a regular
expression and not a divide operator when other states have been take into
account. The left flag always starts at zero or false and is set to true or
1 when the current state is finished and it's a valid object. If we take
the following syntax example: /a/ here we have a regular expression, the
left flag is zero when the / is encountered if the next character is not
* or / then it will be detected as a regular expression and parsed
until complete. Then when the regular expression is closed the left flag is
set to 1 since the regular expression is a valid object and can be used
with the next state.
Storing state
-
To track the state of a square pair we use the left flag to determine the
current state of the opening character if the left flag is 1 then the
starting state is an object accessor, if the flag is 0 when the starting
state is an array literal. When the starting state is determined the
square lookup state is set using the current counter positions of all
available pairs of characters. E.g. the square pair counter (SQ) will be
set as 1, the paren pair counter (PA) will be set as 0 and the curly pair
(CU) will be set as 0. The lookup square will then concatenate each counter
pair (or other method) and set the state based on that position.
squareLookup[''+SQ+PA+CU]=state. It is important to use every pair count
since there could be n number of nested array literals or other statements.
When the ending character is encountered it can know it's partners state by
decrementing it's counter or reading then decrementing.
//[ opening character encountered
Left = 0
SQ = 0
PA = 0
CU = 0
(SQ++) + PA + CU
squareLookup[''+SQ+PA+CU]='Array literal';
//] ending character encountered
currentState = squareLookup[''+SQ+PA+CU];
SQ--
left = 1
Non-symmetrical syntax
--
As mentioned previously syntax that is non-symmetrical such as object
literals or ternary operators present
Re: Paper: Parsing JavaScript by counting character pairs
On 16 January 2013 12:58, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: This sounds similar in the abstract to the way Lisp systems work, with a reader that comes before parsing and builds a simple structure based on (), , and []. This has been implemented in JS by Tim Disney for his sweet.js project [1], but I don't think they have parsing speed in mind there. Sorta similar but the read step occurs real time and the counts of each pair are used as a reference. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
I'd say String.replace needs to be there: http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design/ Also the fact that no built in html encode/decode exists. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
On 14 December 2012 16:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
No, the whole point of Number.isNaN is to provide a definitively test for
NaN number values which cannot be tested for in the usual way using ===.
The definitiveness of the test would be lost if other values such a Number
wrapper instance also returned true when passed as the argument for
Number.isNaN.
Why is it needed? Can't we just simply do:
function isReallyNaN(o) {
return o!=oisNaN(o);
}
I don't get the point of detecting Object(NaN) since it's type is an object
not number.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Sandboxing and parsing jQuery in 100ms
For entertainment purposes I used MentalJS to parse itself. I found that I
had trailing commas in a couple of my object literals. Then I decided to
execute itself inside the sandbox:
eval(js=MentalJS();alert(js.parse('1+1')));
I added an inception button to show how it does this. Parse time moves
slower inside dreams..I mean sandboxes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Sandboxing and parsing jQuery in 100ms
Hi all
Check this out:
http://www.thespanner.co.uk/2012/11/07/sandboxing-and-parsing-jquery-in-100ms/
I have written a complete parser/sandbox based on tracking opening and
closing characters (I will be writing a paper on this in more detail) it
works by using the opening and closing states to store the current state.
For example:
o={
};
Here my parser looks at the state before { and labels it as a object
literal. I track that state and when a } is encountered I can use the
balanced nature of javascript to my advantage by looking up the current
count of characters which allows me to identify that } is in fact a
closing object literal. It isn't that simple I here you say and there are
complicated cases such as:
var xyz, xyz
{}
Here my parser takes an additional step using the characters it tracks such
as { and ( etc I can use that to uniquely identify the var statement
context by using indexes of these characters to know the comma is in fact
part of a var statement. Lets look at another example and I'll illustrate
with comments how the tracking works.
//C = curly
//P = Paren
//C 1
{
function x
//P1
()
//P0
{//C2
var x, y // C2 + P0 = Var statement
//C3
{
}//C2
; // C2 + P0 = '';
}//C1
}//C0
By using these reference points no matter how many nested expressions you
have you can still know the statement it's part of or the character should
be a particular state. Please let me know your comments and I'll post the
paper when it's done.
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Sandboxing and parsing jQuery in 100ms
On 7 November 2012 21:37, Peter van der Zee e...@qfox.nl wrote:
How would you deal with cases like `foo(/)/);` and `foo(5//)/g);` ?
So how would you deal with combinations of regular expressions and
divisions in awkward places? Or are you already using a tokenizer and
hardcoded rules on when to parse for regex/div?
The first stage I use is to assign a left value for example if an
expression occurs then I give it a value of true if not then false. If the
left value is false then it's a regex. Where it isn't as easy is when you
have var statements or need to know what a colon is. Is it a case colon or
label or ternary. I decided to hardcode the entire js syntax into a series
of very specific rules for example:
var rules = {
ArrayComma:createRule('NewExpressions,Expression,Postfix'),
ArrayOpen:createRule('Statements,Operators,NewExpressions,Prefix'),
ArrayClose:createRule('ArrayComma,ArrayOpen,Expression,Postfix'),
.
The property name is the current state and the values are the previous
state. This allows you to control what certain statements do what they are
allowed to follow. I tokenize and parse simultaneously.
Both your cases are invalid javascript in the browser. So they will never
reach the MentalJS parser because I do a syntax check in the browser first
before passing it to MentalJS. However if I turn off this check here is how
Mental JS parses `foo(/)/);`
Identifier$foo$/IdentifierFunctionCallOpen(/FunctionCallOpenRegExp/)//RegExpFunctionCallClose)/FunctionCallCloseEndStatement;/EndStatement
I could fix your invalid syntax automatically in the regex state machine by
rewriting /)/ to /\)/ and then it would execute :)
The second example would fail mental js syntax check because the comment
removes the paren and so the opening and closing parens are uneven which
will result nicely in a syntax error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
undefined cast to a string with regex test
This wasn't totally unexpected but seriously made me go WTF. It appears
that arguments to regexp.test are cast to a string. This was bad for me
since I was writing a js parser at the time and checking the argument to
see if it matched one of the reserved words. See the example below:-
if(/^(?:undefined|ok|wtf|js)$/.test(undefined)){
alert('WTF');
} else {
alert('NO WTF');
}
That's pretty much all I got but if you didn't go WTF then I apologise for
the wasted thread.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Experimental implementation of Object.observe JS Utility library now available
Hi Rafael Would this proposal work on the Object prototype? If so then it could be used for JSON hijacking. I'd recommend it didn't. Cheers Gareth ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Experimental implementation of Object.observe JS Utility library now available
On 17 August 2012 10:57, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
the Notifier is lazily instantiated and I believe not enumerable so
JSON.stringify should ever expose this property.
Moreover, it does not look like there is a {}.__notifier__ property
anywhere, Object.getNotifier(obj) is required indeed so a WeakMap that
relates the obj, and its notifier, cannot be serialized in a meaningful way
via JSON.stringify neither.
Ah no I wasn't talking about the JSON object but remotely hacking JSON
feeds themselves using external scripts and hijacking the Object prototype
with Observe.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicitly escaped $ (or not) in quasis?
On 27 June 2012 15:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I don't see why the above issue would be a problem with this quasi
proposal, as quasi do no implicit evals or implicit reevaluation of
substitution values.
Consider this code:
var USER_INPUT = getUserInput(); // assume the value returned is
${globalVariable}
var message = `USER_INPUT`; //The value of message is the string
USER_INPUT, no substitution occurred
var messageWithSub = `${USER_INPUT}`; //The value of messageWithSub is
the string ${globalVariable}, literally. No eval is performed.
I understand the syntax now and I was correct with my initial assumptions.
Although eval isn't performed on the placeholder text, you can access
variables from outside the scope intended. For example:
!function(){
var cookie=document.cookie, x =1;
func`${cookie}`;
}();
If an injection occurs within the Quasi-Literal then you can use unintended
variables because there is no strict definition of which variables
substitution should occur. I also wonder if the syntax is extended to
support access object properties if this is a further security risk.
!function(){
var x =1; //intended to use this variable
func`${arguments.callee.caller()}`;
func`${arguments[0]}`;
}();
It seems to me this is similar to having variable access inside string
literals and presents a real security risk even when a developer escapes a
quasi literal correctly.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicitly escaped $ (or not) in quasis?
On 26 June 2012 17:19, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I'm working on incorporating quasis into the ES6 draft and there is an
issue I want to discuss:
In the wiki proposal[1] $ is used as the prefix for substitutions that
may be of two forms:
`xyz$foo 1234` //$foo substitues the value of the variable foo
`xyz${foo} 1234`${expr} generally substitues the result of
evaluating expr, so ${foo} substitutes the value of foo
I have to say I disagree with the whole feature, this will introduce a new
class of DOM based XSS attacks since developers in their infinite wisdom
will use this feature to place user input inside multi-line strings. e.g.
message = `USER_INPUT` and the attack being ${globalVariable}. A list of
variable substitutions would mitigate that risk like how the printf
function works but allowing any variable reference is a bad idea IMO. I
would also like to see how the context aware escaping would work since in
order to provide such a mechanism you would have to render the content at
some point and the context could change and the user input could change
when the content is rendered. The fact that CSS doesn't provide any way to
safely escape user input in property names/values without fully white
listing the whole specification I fail to see how a context aware escaping
would work in that instance.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicitly escaped $ (or not) in quasis?
On 27 June 2012 10:06, Brendan Eich bren...@mozilla.org wrote:
What's the difference between
`lit1 ${exp1} lit2 ${exp2} lit3`
and
sprintf(lit1 %s lit2 %s lit3, exp1, exp2)
A list of variables would have to appear outside the backticks somehow like
the earlier example using a function call. If not even context aware text
could be used to expose variables and dom objects on the page if the
developer allows content inside backticks. A developer will assume that a
backtick is just another way to declare strings across multiple lines and
will probably (in most cases) account for escaping backticks but will fail
to account for variables being used inside backticks.
Another thing to consider is in server side languages such as PHP backticks
is an eval like construct and if a dev misplaces the backticks then instead
of XSS they will have remote code execution. Also in IE a backtick is a
valid attribute quote this would introduce new XSS vectors by reusing the
existing backticks with an injection.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicitly escaped $ (or not) in quasis?
On 27 June 2012 12:38, Brendan Eich bren...@mozilla.org wrote:
You assume a developer will assume something. We need evidence.
Lots of languages, e.g. CoffeeScript after Ruby, or bash after the Bourne
shell (sh), use embedded expressions in ${...} or #{...} brackets in
distinguished string (e.g., double-quoted strings).
These languages don't obviously have more injection attacks based on
failure to sanitize than languages with printf-style format strings. Indeed
the mismatch problem makes the latter actually unsafe (even memory-unsafe)
in too many languages.
I don't know how to provide evidence on a feature that doesn't exist yet
but here goes:
http://x10hosting.com/forums/scripts-3rd-party-apps-programming/70485-send-multiline-php-variable-javascript.html#post_401282
This has a XSS hole obviously but a dev wanted a multiline string from php
to JavaScript. Same thing could happen with this feature but if the php
variable was escaped correctly in the code sample to escape backticks then
it would still contain a XSS hole using a variable reference ${}.
Another thing to consider is in server side languages such as PHP
backticks is an eval like construct and if a dev misplaces the backticks
then instead of XSS they will have remote code execution.
Yes, that's a drag. We lack good options that anyone can type, though. If
I recall correctly, an earlier proposal used
format ...
I would prefer that syntax.
Also in IE a backtick is a valid attribute quote this would introduce new
XSS vectors by reusing the existing backticks with an injection.
Insane. What version(s) of IE? You mean in HTML? That's not standard, of
course it never was but with HTML5 and new IE releases, is this still
supported?
= IE9 and supported in IE10 using compat mode. You can also force a web
page into compat mode using a parent web page and a child iframe of a
target page.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicitly escaped $ (or not) in quasis?
On 27 June 2012 15:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
var messageWithMSGSub = Msg`${USER_INPUT}`; //The value of
messageWithMsgSub is the result of calling Msg.
Here, Msg, is a application or library provided quasi substitution handler
function. Think about it as the DSL compiler. In this case Msg might be
designed to do an explicit eval of the the substitution text containing the
attach code. However, that fact that Msg evals some of its inputs really
should be documented as part of the its contract. It essentially is just
like any other function you might call and pass a string to as an argument.
If you don't know or don't trust the function to not do an eval of its
parameters then you better not pass any strings into it that originated
from untrusted sources.
Ah sorry I misunderstood the syntax, I've also tried the demo but it isn't
clear to me how placeholders are assigned. Please could someone explain how
to pass the correct variable to a placeholder?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ and JSON
On 30 May 2012 14:52, Brendan Eich bren...@mozilla.com wrote:
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse
JSON. Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially, per ES5. What's the problem
you see?
__proto__ can remove all methods for an object, this could cause a whole
block of code to fail when using a property from the JSON object. For
example using valueOf/toString with any property that has a null proto.
x={y:{__proto__:null}};
x=x.y+''; // I'm gonna bail because I have no toString
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
On 18 April 2012 19:13, Geoffrey Sneddon gsned...@opera.com wrote: I've just had it pointed out to me that my original email made little sense, so let's try again: const has historically been needed in non-strict/strict code for web compatibility on non-IE code (typically either down to server-side UA sniffing or just explicitly non-support of IE). IE still doesn't support it, which may suggest it's not needed for compatibility any more, but as far as I can tell removing it would break enough to make it infeasible. As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. IE has consts, use execScript with vbs. I think Andrea did a blog post on it: http://webreflection.blogspot.co.uk/2007/10/cow-javascript-define-php-like-function.html The const keyword is a little freaky overall, Firefox seems to support it yet Opera (last time I checked) supports the keyword but doesn't perform a const operation. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fun impossible Firefox JS challenge
On 13 April 2012 08:38, Lasse Reichstein reichsteinatw...@gmail.com wrote: I guess that depends on the version. I was testing in Firefox 9.0.1, and it runs your function. Ah I'm testing on FF11 if it works on your version then it's a valid answer :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fun impossible Firefox JS challenge
Hey all
Just thought I'd post a bit of fun related to the Firefox JS parser.
!function(){
function true(){alert('Call me');};
/* YOUR CODE */
}();
The trick is to execute the function true from within the function
expression.
Rules:
1. Your code must be within the function expression as indicated by the
comment.
2. You cannot redefine true anywhere else including window etc.
3. You must call the actual function as defined in the original code.
This is just for fun and should be impossible but it does highlight a
couple of things, 1) JavaScript has no way to reference inner functions
that are not a property of the object without directly calling their name.
2) Mozilla JS devs are crazy (in a nice way)
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Fun impossible Firefox JS challenge
On 12 April 2012 14:51, Lasse Reichstein reichsteinatw...@gmail.com wrote:
On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes gazhe...@gmail.com wrote:
function true(){alert('Call me');};
Is this a deliberate Mozilla change, or just a bug (true being a
keyword and not valid as a function name in plain ECMAScript)?
And, btw,
/* MY CODE */
tru\u0065();
Haha nice try even with unicode escapes it still refers to true the
boolean not the function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Fun impossible Firefox JS challenge
On 12 April 2012 15:12, Andreas Rossberg rossb...@google.com wrote: That's another FF deviation from the standard, though. Well it's possible to do as I've just done it but deviation from the standard isn't a valid answer sorry :P ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fun impossible Firefox JS challenge
On 12 April 2012 15:34, crypticswarm crypticsw...@gmail.com wrote:
!function(){
function true(){alert('Call me');};
/* YOUR CODE */
new Function('(' + ('' +
arguments.callee).match(/function.+?\{\s*([\s\S]*?\})/)[1] + '())')()
}()
It calls *a* function `true` but maybe not *the* function `true`
That is lame. Try harder.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Third parameter for String.replace
On 6 March 2012 05:35, Biju bijumaill...@gmail.com wrote:
So I have proposal, can we have 3rd parameter for replace() function?
like
haystack.replace(needle, newText, regexpFlag);
where regexpFlag is the flag part of the RegExp.
And if needle is a string will be used to make the match characters
after escaping special characters like *?.()[]{}\^$|/
No no no no no. This is already one of the best functions
in JavaScript but has been really badly designed. This suggestion makes it
worse.
http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design/
Even Twitter devs seemed to struggle with using it correctly to fix a DOM
xss issue.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Wouldn't it be easier to extend JSON to support a getter with a function
that refers to this?
o={a:123, get b(){return this.a}};o.b
On 5 March 2012 10:50, 程劭非 csf...@gmail.com wrote:
Hi, everyone,
As you know, JSON API will throw a syntax error when trying to stringify a
object with circular reference.But indeed the feature
serializing/unserializing object with circular reference is needed.(eg.
when storing a graph,or status machine)
I am working on a JS implement of parse/stringify to support a “path
grammar” in JSON. It looks like the following:
// this will produce a object with it's property “x” reference to it self
{
x:path(/)
}
//also relative path is supported
{
x:{
a:path(../x),
b:path(x)
}
}
//ref to deeper object
{
x:{
a:{
obj:[]
},
b:path(/x/a/obj)
}
}
// path could also point to a none-object value
{
a:11,
b:path(/a)
}
// path ref to a path node will get undefined, there is no way to recurse
{
a:path(/), //the root object
b:path(/a) //undefined
}
--
( The project is located at https://github.com/wintercn/JSONplus
. in which JSON.pareseEx and JSON.stringifyEx passes all test262 API cases
except the ones related to circular reference. )
I was wondering if the future version of ECMAScript could support this
grammar or something like this to enable serializing/unserializing object
with circular reference. It will be a good news for ones working on complex
data structure.
PS. Another known way of descripting object with circular reference is
using sharp
variablehttps://developer.mozilla.org/en/Sharp_variables_in_JavaScript in
object literal . But there are several problems:
1. The id in sharp variable has to be unique. Combining two objects with
conflicted ids will be hard work.
2. Sharp variable is sensitive to the order of object properties. A
assignment must appear before its first usage. But path do not have such
requirement.Since the order of properties defined in JSON would
(especially) affect enumerate (for.. in) order, making a order-independent
reference grammar is a must.
3. Sharp variable requires assignment operator, and hence assignment
expression and even continuous assignment expression. Adding this feature
to JSON increases the complexity of its grammar a lot.
Thanks,
Shaofei Cheng
___
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: Consider extending JSON grammar to support objects with circular reference
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
On 5 March 2012 12:16, 程劭非 csf...@gmail.com wrote:
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to implement
it in my library.
But I guess the problem is we have no way to refer to its parent. Do you
have any ideas?
You could have something like this:
{
a:123,
b: function circular() { return this.a; }
}
and then obj.b(); would result in 123
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
I was pondering about this on twitter, at first I thought using cycrllic
variables to resolve references to object within the JSON object but
actually we just need this to work within object literals and be allowed
in the specification. For example this works currently :
({a:function(){
return this.b;
},b:123}).a()
But it would be nicer to resolve this inside a object literal property to
be itself rather than window or undefined:
({a:this,b:123}).a.b
This would make JSON much smaller and allow circular references without
losing data.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How to clean up __proto__ (was: Why we need to clean up __proto__)
On 30 December 2011 17:05, John J Barton johnjbar...@johnjbarton.comwrote: On Fri, Dec 30, 2011 at 3:53 AM, David Bruant bruan...@gmail.com wrote: How did this competition begin? A use case for JS security environment is loading app components cross-site. The other site is 'trusted' in that you believe it has code helpful to the user. But you want to limit its control, for reliability rather than security in the normal sense. Is this what you have in mind? What I've said before applies and even against an XSS attack, you can prevent cookie theft as long as you run first. I can't see a way for the browser to enforce that trusted code run before untrusted code. What causes 'untrusted' code to run at all? You must be doing something to cause the browser to load code outside of normal methods. That 'cause' is running first. To put this another way, what ever runs first *is* the trusted code. I believe me and Mario Heiderich have solved this problem with JSLR: http://www.businessinfo.co.uk/labs/jslr/jslr.php As long as the javascript is executed first then you can protect the page from untrusted javascript execution by whitelisting allowed scripts using randomized tokens. Even when the site is vulnerable to type 1 XSS and DOM based XSS, even within href attributes. I have also developed a whitelisted Javascript environment that can extended by simulating real dom objects making it difficult to discover you are in a protected environment. http://www.businessinfo.co.uk/labs/jsreg/jsreg.html It might be of interest to the people of this list to check out Mario Heiderich's slides as he discussed how to use ES5 methods to create a safe js environment. https://www.owasp.org/images/a/a3/Mario_Heiderich_OWASP_Sweden_Locking_the_throneroom.pdf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
I'd also like to add that __proto__ allows valid JSON to change it's object
type and allow functions within properties. There isn't a compelling
exploit scenerio for this yet but who knows what is possible if setters
come into the equation.
alert(({__proto__:[]}).sort)
alert(({__proto__:function::['parent']}).location)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array extras and Objects
On 1 December 2011 07:47, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
Let's say this is an attempt to bring some new, easy to implement, method
for the native Object.prototype
Specially about forEach, the most used Array.prototype method out there,
it's quite clear JS developers would like to have similar method to iterate
over objects, as key:value pairs rather than index:value.
You can sorta do this now but it only accepts numeric indexed properties.
E.g.
({0:1,1:2,__proto__:[],length:2}).forEach(alert)
and
[].forEach.apply(({0:1,1:2,length:2}),[alert])
So I agree to be able to do this with any property type would be useful
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: (Almost) everything is expression
11/11/2011 08:07, Dmitry Soshnikov :
Hi,
(unfortunately Twitter is again doesn't fit for a more than 140 ch
discussion, so moving here)
I'd like to still notice the possibility of accepting the almost
everything is expression approach for JS. After Erlang I very often miss
this possibility.
The idea is to make most of current complex statements as expressions.
Dave mentioned the proposal with `do { ... }` -- yeah, it's fine, but
much nicer is to have all of them as expressions. CoffeeScript adopted
this style as well.
Besides, I'd like to note, that the thing is not just interesting
theoretical stuff, but really is very convenient and useful in practice.
Examples:
1. Switch-expression (as addition, I eliminated `break`)
let a = switch (foo) {
case 10: 100;
default: 200;
};
2. If-expression:
let a = if (foo) {
print('a is foo');
foo;
} else {
// do some longer stuff
};
I think this is a bad idea, the difference between a block and expression
is difficult enough to decide (from a sandboxing perspective). It would
also make missing semi-colons continue the expression and make it really
hard for the developer to track down the error and cause unintended
behaviour. It adds to the complexity of deciding if a curly is a block or
literal and if a / is a divide or regexp (which is difficult enough in
JavaScript). How on earth would this be backwards compatible too?
We of course already have for years the expression sugar for this -- ? :
operator, but it doesn't allow to conveniently have longer bodies of
consequent and alternative nodes of if-expression.
I'm pretty sure it does: 0?0:0?0:2
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: (Almost) everything is expression
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block statement and a object
literal? Surely it becomes an expression once an assignment occurs anyway.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: (Almost) everything is expression
On 11 November 2011 17:13, David Herman dher...@mozilla.com wrote: Your idea of mandatory parens is still valid (if, IMO, a bit unsatisfyingly verbose) for most statement forms. It's only the block-statement-expression that doesn't work. Hence my do-expressions It should also apply to function expressions IMO too as there are instances especially in for loops where there is confusion between the two. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: (Almost) everything is expression
On 11 November 2011 18:01, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to work
within expressions since you'd probably want to do:
x=loop:for(i=0;i10;i++){
}
but then what if you do:
x=1/loop:for(i=0;i10;i++){
}
Is 1 divided by the result of the for loop or is it divided by undefined?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: (Almost) everything is expression
On 11 November 2011 18:29, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
This is why the topic is called *(Almost)* everything In general
case we may not include this case with label-statement into proposal, since
the construction you wrote isn't practice IMO. But, we should consider also
theoretical things and this case it can be better to avoid the case at all
then to solve it -- especially if there is no much profit in practice from
it. Though, if we can manage it, why not?
Another thing isn't a block statement a no-op? So :
x={};
x wouldn't be undefined or anything since a blank block statement shouldn't
return anything. Then if it returns undefined then how would a block
statement actually work:
{}/1
You'd have to make a block statement return undefined to make sense.
So as you can see you are adding complexity to the syntax in both the
developer level and the sandboxing level. There are a ton of problems this
would create.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
