Re: JSON.stringify

[Mike Samuel]

Without CDATA you have to encode script bodies properly.  With CDATA you
have to encode script bodies properly.  What problem did CDATA solve?

On Sep 28, 2016 8:03 PM, "Alexander Jones"  wrote:

> They do solve the problem. You encode your entire JS *before* pasting it,
> encoding `]]>` and nothing more, and the XML document's text node contains
> the unadulterated text, which the JS parser also sees. It's perfect layer
> isolation. Ye olde HTML can't do that because there is no escaping
> mechanism for `` that actually allows the JS parser to see the
> text (code) content unmodified.
>
> Viva la `` ;)
>
> On Wednesday, 28 September 2016, Mike Samuel  wrote:
>
>> I agree it's subideal which is why I work to address problems like this
>> in template systems but ad-hoc string concatenation happens and embeddable
>> sub-languages provide defense-in-depth without sacrificing correctness.
>>
>> CDATA sections solve no problems because they cannot contain any string
>> that has "]]>" as a substring so you still have to s/\]\]>/]]>]]/g.
>>
>> On Sep 28, 2016 2:32 PM, "Alexander Jones"  wrote:
>>
>>> That's awful. As you say, it's an antipattern, no further effort should
>>> be spent on this. JSON produced by JavaScript has far more general uses
>>> than slapping directly into a script tag unencoded, so no-one else should
>>> have to see this. Also, there are many other producers of JSON than
>>> JavaScript.
>>>
>>> Instead, use XHTML and CDATA (which has a straightforward encoding
>>> mechanism that doesn't ruin the parseability of the code or affect it in
>>> any way) if you really want to pull stunts like this.
>>>
>>> Alex
>>>
>>> On Wednesday, 28 September 2016, Michał Wadas 
>>> wrote:
>>>
 Idea: require implementations to stringify "" as
 "<\uscript>".

 Benefits: remove XSS vulnerability when injecting JSON as content of
 

Re: JSON.stringify

[Alexander Jones]

They do solve the problem. You encode your entire JS *before* pasting it,
encoding `]]>` and nothing more, and the XML document's text node contains
the unadulterated text, which the JS parser also sees. It's perfect layer
isolation. Ye olde HTML can't do that because there is no escaping
mechanism for `` that actually allows the JS parser to see the
text (code) content unmodified.

Viva la `` ;)

On Wednesday, 28 September 2016, Mike Samuel  wrote:

> I agree it's subideal which is why I work to address problems like this in
> template systems but ad-hoc string concatenation happens and embeddable
> sub-languages provide defense-in-depth without sacrificing correctness.
>
> CDATA sections solve no problems because they cannot contain any string
> that has "]]>" as a substring so you still have to s/\]\]>/]]>]]/g.
>
> On Sep 28, 2016 2:32 PM, "Alexander Jones"  > wrote:
>
>> That's awful. As you say, it's an antipattern, no further effort should
>> be spent on this. JSON produced by JavaScript has far more general uses
>> than slapping directly into a script tag unencoded, so no-one else should
>> have to see this. Also, there are many other producers of JSON than
>> JavaScript.
>>
>> Instead, use XHTML and CDATA (which has a straightforward encoding
>> mechanism that doesn't ruin the parseability of the code or affect it in
>> any way) if you really want to pull stunts like this.
>>
>> Alex
>>
>> On Wednesday, 28 September 2016, Michał Wadas > > wrote:
>>
>>> Idea: require implementations to stringify "" as
>>> "<\uscript>".
>>>
>>> Benefits: remove XSS vulnerability when injecting JSON as content of
>>> 

Re: Syntax Proposal: Anonymous Arguments

[Tab Atkins Jr.]

On Fri, Sep 23, 2016 at 10:38 AM, Kenneth Powers  wrote:
> I have a proposal for new syntax in ES inspired by the placeholder syntax in
> Scala Functions.
>
> Essentially, the idea would be to allow anonymous arguments. The most simple
> example would be a function which takes one argument (as far as the
> programmer is concerned):
>
> [1, 2, 3].map(@ + 1)
>
> This would be the same thing as:
>
> [1, 2, 3].map(n => n + 1)
>
> Just like in Scala, an anonymous function is created. This concept can be
> further extended in ES:
>
> [1, 2, 3].reduce(@0 + @1, 0)
>
> Which would be the same thing as:
>
>[1, 2, 3].reduce((sum, n) => sum + n, 0)
>
> Thoughts?

While I like really concise callbacks for simple cases like this, the
win over arrow functions is *so tiny* here.  map(@+1) vs map(x=>x+1)
is *3 characters* different; map(@0+@1) vs map((x,y)=>x+y) is 5.
Having to learn a new syntax for tiny functions that only gains an
extremely miniscule benefit in terms of code size is an extremely hard
sell.

Compound this with the fact that the @ glyph is already spoken for,
and you have an extreme uphill battle to deal with.

I suggest just living with the few extra characters that arrow
functions impose, and being happy we no longer have to type out
"function ... { return }". ^_^

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.stringify

[Mike Samuel]

I agree it's subideal which is why I work to address problems like this in
template systems but ad-hoc string concatenation happens and embeddable
sub-languages provide defense-in-depth without sacrificing correctness.

CDATA sections solve no problems because they cannot contain any string
that has "]]>" as a substring so you still have to s/\]\]>/]]>]]/g.

On Sep 28, 2016 2:32 PM, "Alexander Jones"  wrote:

> That's awful. As you say, it's an antipattern, no further effort should be
> spent on this. JSON produced by JavaScript has far more general uses than
> slapping directly into a script tag unencoded, so no-one else should have
> to see this. Also, there are many other producers of JSON than JavaScript.
>
> Instead, use XHTML and CDATA (which has a straightforward encoding
> mechanism that doesn't ruin the parseability of the code or affect it in
> any way) if you really want to pull stunts like this.
>
> Alex
>
> On Wednesday, 28 September 2016, Michał Wadas 
> wrote:
>
>> Idea: require implementations to stringify "" as
>> "<\uscript>".
>>
>> Benefits: remove XSS vulnerability when injecting JSON as content of
>> 

Re: JSON.stringify

[Kris Siegel]

ECMAScript, while highly used in web browsers, should really not care about
HTML constructs. That's where WHATWG and W3C come in. I suggest this type
of feature should come from one of those groups, not ECMA.

On Wed, Sep 28, 2016 at 11:54 AM, Alexander Jones  wrote:

> Hi Michał
>
> Embedding a JSON literal into HTML involves first encoding to JSON then
> encoding that into HTML. Two stages which must not be confused. The
> 'encoding into HTML' part is best done in XHTML with CDATA, and the
> encoding method is taken care of by whichever XML-generating library you're
> using. If you hint it to use CDATA for such a text node, or if for any
> other reason it chooses to use CDATA, rather than merely converting every
> `<` to ``, etc., then it will (or should) "escape" `]]>` as
> `>". Mike Samuel has
>> a very strong point here.
>>
>> And by saying "it's antipattern, don't do this" we will not make old
>> vulnerable code go away. And we have a very good way to stop people from
>> shooting their own feet - for free.
>>
>> On 28 Sep 2016 8:31 p.m., "Alexander Jones"  wrote:
>>
>> That's awful. As you say, it's an antipattern, no further effort should
>> be spent on this. JSON produced by JavaScript has far more general uses
>> than slapping directly into a script tag unencoded, so no-one else should
>> have to see this. Also, there are many other producers of JSON than
>> JavaScript.
>>
>> Instead, use XHTML and CDATA (which has a straightforward encoding
>> mechanism that doesn't ruin the parseability of the code or affect it in
>> any way) if you really want to pull stunts like this.
>>
>> Alex
>>
>>
>> On Wednesday, 28 September 2016, Michał Wadas 
>> wrote:
>>
>>> Idea: require implementations to stringify "" as
>>> "<\uscript>".
>>>
>>> Benefits: remove XSS vulnerability when injecting JSON as content of
>>> 

Re: JSON.stringify

[Alexander Jones]

Hi Michał

Embedding a JSON literal into HTML involves first encoding to JSON then
encoding that into HTML. Two stages which must not be confused. The
'encoding into HTML' part is best done in XHTML with CDATA, and the
encoding method is taken care of by whichever XML-generating library you're
using. If you hint it to use CDATA for such a text node, or if for any
other reason it chooses to use CDATA, rather than merely converting every
`<` to ``, etc., then it will (or should) "escape" `]]>` as
`>". Mike Samuel has a
> very strong point here.
>
> And by saying "it's antipattern, don't do this" we will not make old
> vulnerable code go away. And we have a very good way to stop people from
> shooting their own feet - for free.
>
> On 28 Sep 2016 8:31 p.m., "Alexander Jones"  wrote:
>
> That's awful. As you say, it's an antipattern, no further effort should be
> spent on this. JSON produced by JavaScript has far more general uses than
> slapping directly into a script tag unencoded, so no-one else should have
> to see this. Also, there are many other producers of JSON than JavaScript.
>
> Instead, use XHTML and CDATA (which has a straightforward encoding
> mechanism that doesn't ruin the parseability of the code or affect it in
> any way) if you really want to pull stunts like this.
>
> Alex
>
>
> On Wednesday, 28 September 2016, Michał Wadas 
> wrote:
>
>> Idea: require implementations to stringify "" as
>> "<\uscript>".
>>
>> Benefits: remove XSS vulnerability when injecting JSON as content of
>> 

Re: JSON.stringify

[Michał Wadas]

Actually CDATA suffer the same issue - for string "]]>". Mike Samuel has a
very strong point here.

And by saying "it's antipattern, don't do this" we will not make old
vulnerable code go away. And we have a very good way to stop people from
shooting their own feet - for free.

On 28 Sep 2016 8:31 p.m., "Alexander Jones"  wrote:

That's awful. As you say, it's an antipattern, no further effort should be
spent on this. JSON produced by JavaScript has far more general uses than
slapping directly into a script tag unencoded, so no-one else should have
to see this. Also, there are many other producers of JSON than JavaScript.

Instead, use XHTML and CDATA (which has a straightforward encoding
mechanism that doesn't ruin the parseability of the code or affect it in
any way) if you really want to pull stunts like this.

Alex


On Wednesday, 28 September 2016, Michał Wadas  wrote:

> Idea: require implementations to stringify "" as
> "<\uscript>".
>
> Benefits: remove XSS vulnerability when injecting JSON as content of
> 

Re: JSON.stringify

[Alexander Jones]

That's awful. As you say, it's an antipattern, no further effort should be
spent on this. JSON produced by JavaScript has far more general uses than
slapping directly into a script tag unencoded, so no-one else should have
to see this. Also, there are many other producers of JSON than JavaScript.

Instead, use XHTML and CDATA (which has a straightforward encoding
mechanism that doesn't ruin the parseability of the code or affect it in
any way) if you really want to pull stunts like this.

Alex

On Wednesday, 28 September 2016, Michał Wadas  wrote:

> Idea: require implementations to stringify "" as
> "<\uscript>".
>
> Benefits: remove XSS vulnerability when injecting JSON as content of
> 

Re: JSON.stringify

[Mike Samuel]

I think defining an easy way to produce embeddable JSON is a great
idea, but it's not quite that simple.

https://github.com/OWASP/json-sanitizer#output captures some
requirements that I came up with for embedding JSON in HTML:

"""
The output is well-formed JSON as defined by RFC 4627. The output
satisfies these additional properties:

* The output will not contain the substring (case-insensitively)
"" so can be embedded
inside an XML CDATA section without further encoding.
* The output is a valid Javascript expression, so can be parsed by
Javascript's eval builtin (after being wrapped in parentheses) or by
JSON.parse. Specifically, the output will not contain any string
literals with embedded JS newlines (U+2028 Paragraph separator or
U+2029 Line separator).
* The output contains only valid Unicode scalar values (no isolated
UTF-16 surrogates) that are allowed in XML unescaped.
"""

These apply equally well to RFC 7159 IIUC.  The latter few constraints
are required to allow embedding of JSON in HTML in a foreign content
context ( https://www.w3.org/TR/html5/syntax.html#cdata-sections ).

Those rules are sufficient to allow embedding in HTML without breaking
token boundaries in the embedding language.

To preserve semantics when embedding in HTML you also need to escape '&'.
To prevent exfiltration via external entities in SVG & other XML
variants, you should probably also escape '%'.



On Wed, Sep 28, 2016 at 10:06 AM, Michał Wadas  wrote:
> Idea: require implementations to stringify "" as "<\uscript>".
>
> Benefits: remove XSS vulnerability when injecting JSON as content of
> 

Re: Proposal: add an option to omit prototype of objects created by JSON.parse()

[Michał Wadas]

Have you ever encountered performance issue because of copying object on
deserialization?

https://gist.github.com/Ginden/381448a17f50c7669b9a3693742e3a3d For me
results are:

Simple JSON.parse, 10 iterations: 39.5947526ms
JSON.parse with copy, 10 iterations: 184.56997ms
JSON.parse with __proto__ change, 10 iterations: 89.755102ms



On Wed, Sep 28, 2016 at 5:49 PM, 段垚  wrote:

> 在 2016/9/28 22:59, Danielle McLean 写道:
>
> From: 段垚 (mailto:duan...@ustc.edu)
>> Date: 28 September 2016 at 16:36:52
>>
>> [I]mplementors warn that mutating prototype causes "performance
>>> hazards".
>>>
>> You don't actually need to mutate any prototypes to get prototypeless
>> objects out of `JSON.parse` - the reviver function is allowed to
>> return a new object instead, so you can create a fresh one with the
>> correct prototype. For example:
>>
>> ```js
>> JSON.parse(string, function(k, v) {
>>if (v && typeof v === 'object' && !Array.isArray(v)) {
>>  return Object.assign(Object.create(null), v);
>>}
>>return v;
>> });
>> ```
>>
>
> Yes, but creating a copy also has performance penalty. This proposal is
> made for performance.
>
> How about adding an option to omit prototype of objects created by
>>> JSON.parse()?
>>>
>>> JSON.parse(str, { noPrototype: true });
>>>
>> While you can achieve the appropriate result already without extra
>> language support, I think this particular situation is common enough
>> that such an option might be a good idea.
>>
>> How would you expect this new parameter to interact with the existing
>> second parameter to `JSON.parse`, the reviver function? I'd suggest
>> that the cleanest way to add the options would be for the second
>> parameter to be either an object or function, like this:
>>
>> ```js
>> JSON.parse(str, someFunc);
>> // equivalent to
>> JSON.parse(str, {reviver: someFunc});
>> ```
>>
> Looks reasonable.
>
> Maybe we can simply add another method, say `JSON.parseWithoutPrototype()`.
> This makes feature detection easier.
>
>
>
> ___
> 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: Proposal: add an option to omit prototype of objects created by JSON.parse()

[段垚]

在 2016/9/28 22:59, Danielle McLean 写道:


From: 段垚 (mailto:duan...@ustc.edu)
Date: 28 September 2016 at 16:36:52


[I]mplementors warn that mutating prototype causes "performance
hazards".

You don't actually need to mutate any prototypes to get prototypeless
objects out of `JSON.parse` - the reviver function is allowed to
return a new object instead, so you can create a fresh one with the
correct prototype. For example:

```js
JSON.parse(string, function(k, v) {
   if (v && typeof v === 'object' && !Array.isArray(v)) {
 return Object.assign(Object.create(null), v);
   }
   return v;
});
```


Yes, but creating a copy also has performance penalty. This proposal is made 
for performance.


How about adding an option to omit prototype of objects created by
JSON.parse()?

JSON.parse(str, { noPrototype: true });

While you can achieve the appropriate result already without extra
language support, I think this particular situation is common enough
that such an option might be a good idea.

How would you expect this new parameter to interact with the existing
second parameter to `JSON.parse`, the reviver function? I'd suggest
that the cleanest way to add the options would be for the second
parameter to be either an object or function, like this:

```js
JSON.parse(str, someFunc);
// equivalent to
JSON.parse(str, {reviver: someFunc});
```

Looks reasonable.

Maybe we can simply add another method, say 
`JSON.parseWithoutPrototype()`. This makes feature detection easier.



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: add an option to omit prototype of objects created by JSON.parse()

[Danielle McLean]

From: 段垚 (mailto:duan...@ustc.edu)
Date: 28 September 2016 at 16:36:52

> [I]mplementors warn that mutating prototype causes "performance
> hazards".

You don't actually need to mutate any prototypes to get prototypeless
objects out of `JSON.parse` - the reviver function is allowed to
return a new object instead, so you can create a fresh one with the
correct prototype. For example:

```js
JSON.parse(string, function(k, v) {
  if (v && typeof v === 'object' && !Array.isArray(v)) {
    return Object.assign(Object.create(null), v);
  }
  return v;
});
```

> How about adding an option to omit prototype of objects created by
> JSON.parse()?
>
> JSON.parse(str, { noPrototype: true });

While you can achieve the appropriate result already without extra
language support, I think this particular situation is common enough
that such an option might be a good idea.

How would you expect this new parameter to interact with the existing
second parameter to `JSON.parse`, the reviver function? I'd suggest
that the cleanest way to add the options would be for the second
parameter to be either an object or function, like this:

```js
JSON.parse(str, someFunc);
// equivalent to
JSON.parse(str, {reviver: someFunc});
```

Another approach would be to use two separate optional parameters,
i.e., `JSON.parse(text[, reviver][, options])`, but generally that
style is very messy.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: use "One More Point" to handle async functions

[Jason Orendorff]

On Tue, Sep 27, 2016 at 10:23 AM, Li Xiaolong <898310...@outlook.com> wrote:

> 3: the async function calls identically with sync functions, makes it hard
> to check out if the function is async without jumping to the definition.
> But OMP can easily be recognized.
>

Usually, async calls will be marked with `await`, which to me seems
somewhat easier to spot.

On the other hand it's true that the function call itself is just a
function call. One nice consequence is that you can call an async function
without immediately blocking and waiting for it to finish. For example,

let p1 = start_download();// start two things at once
let p2 = start_query();
let file = await p1;// wait for results
let result = await p2;

Is that possible with OMP syntax?

In your proposal, what would happen if you called an OMP async function
(one that ends with a `.return`) using `plain.method()` call syntax? What
if you call a sync function or method using OMP call syntax?

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Array.prototype.first() and Array.prototype.last()

[段垚]

在 2016/9/28 14:42, Claude Pache 写道:



Le 28 sept. 2016 à 07:38, 段垚 > a écrit :


Because `foo.bar` is equivlant to `foo['bar']` in JS so far, and 
`array.-1` could break this consistency.



On the other hand, `array.first()` seems not necessary because 
`array[0]` is even more handy; `array.last()` looks fine to me.



If someone prefer a more general solution, I recommand `array.get(n)`:

  * if n >= 0 && n < array.length: equivlant to array[n]
  * if n < 0 && -n < array.length: equivlant to array[array.length + n]
  * if n <= -array.length || n >= array.length: throw or return undefined
  * if n is not a integer or not a number: throw or return undefined

The last 2 rules make `array.get(n)` less error prone than 
`array[n]`. I prefer throwing, but maybe returning undefined is more 
JS-style?


For consistency with the rest of the builtin library, `array.get(n)` 
should be equivalent to `array.slice(n)[0]`, which means: convert `n` 
to an integer, and: return `undefined` for out-of-bound index.
I regard such converting behavior a bad legacy of JS, and want to avoid 
it in new APIs.




—Claude



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Array.prototype.first() and Array.prototype.last()

[Claude Pache]

> Le 28 sept. 2016 à 07:38, 段垚  a écrit :
> 
> Because `foo.bar` is equivlant to `foo['bar']` in JS so far, and `array.-1` 
> could break this consistency.
> 
> 
> On the other hand, `array.first()` seems not necessary because `array[0]` is 
> even more handy; `array.last()` looks fine to me.
> 
> If someone prefer a more general solution, I recommand `array.get(n)`:
> 
>   * if n >= 0 && n < array.length: equivlant to array[n]
>   * if n < 0 && -n < array.length: equivlant to array[array.length + n]
>   * if n <= -array.length || n >= array.length: throw or return undefined
>   * if n is not a integer or not a number: throw or return undefined
> 
> The last 2 rules make `array.get(n)` less error prone than `array[n]`. I 
> prefer throwing, but maybe returning undefined is more JS-style?

For consistency with the rest of the builtin library, `array.get(n)` should be 
equivalent to `array.slice(n)[0]`, which means: convert `n` to an integer, and: 
return `undefined` for out-of-bound index.

—Claude

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: add an option to omit prototype of objects created by JSON.parse()

[段垚]

It is usually a bad practice to let a map-like object (an plain object 
used as a key-value map) have a prototype.


Objects created by JSON.parse() have a prototype by default, and we can 
get rid of them by:



JSON.parse(str, function(k, v) {

 if (v && typeof v === 'object' && !Array.isArray(v)) {

v.__proto__ = null;

 }

 return v;

});


However, implementors warn that mutating prototype causes "performance 
hazards" [1].


How about adding an option to omit prototype of objects created by 
JSON.parse()?


E.g.:


JSON.parse(str, { noPrototype: true });


[1] 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_performance_hazards_of__%5B%5BPrototype%5D%5D_mutation



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss