Re: Proposal: export ** from './FooBar'

[Mike Samuel]

On Fri, Mar 1, 2019 at 1:35 AM Cyril Auburtin 
wrote:

> Sometimes, (particularly in React codebases) you have to write many lines
> like:
> ```js
> export { default as FooBar } from './FooBar';
> ```
> It could be automated of course
>
> It could also be tuned into
> ```js
> export * from './FooBar';
> ```
> only if FooBar is also a named export in that file, but usually files with
> one export just use a default export
>
> --
> This proposed syntax:
> ```js
> export ** from './FooBar';
> ```
> Would do:
> ```js
> export * from './FooBar';
> export { default as FooBar } from './FooBar';
> ```
> the filename is used as default export name.
>
> If the filename isn't a valid JS identifier, like 'foo-bar' for example,
> it would throw
>

ES doesn't impose many constraints on the string content of a module
specifier but in practice it maps fairly directly to a URL per
https://html.spec.whatwg.org/multipage/webappapis.html#hostgetimportmetaproperties
so filename is probably broadly available.

Would this use the filename from the module specifier or from the URL
(assuming import.meta.url)?
IIRC, only the module specifier is available within ES currently.
The translation between specifiers and URLs (if that happens) is up to a
host callback (HostResolveImportedModule) and does not surface inside the
ES engine.
That import.meta.url exists is up to another host callback so assuming it's
existence might require constraining host implementations of
HostGetMetaProperties(?).

What would this do when import.meta.url/specifier has a query part, or that
look like a non-hierarchical URL?
export ** from "path?foo=bar";
export ** from "?foo=bar";
export ** from "data:application/javascript+module,export default null;"

Does anyone know if existing CDNs use the path component for something
other than the path contributed by the uploader and expect the original
filename in the query, like
host.cdn/path/to/tarball?p=path/within/tarball.js ?



> ___
> 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: String identity template tag

[Mike Samuel]

Kai, that there may be some tenuous connection to ux-workflow does not
support your sweeping claims. Also please stop with the personal attacks.

On Wed, Dec 19, 2018, 10:40 AM kai zhu  *everything* using javascript is ultimately meant to solve a UX-workflow
> problem (including js-code in servers, IoT, satellites, etc.).  if you're
> so caught up in low-level js library-code that you can't see how the piece
> fits/integrates into that big-picture, then you should go back to
> general-purpose programming in java/c++/c#/etc.
>
> but of course, much of industry these days prefer hiring business-oriented
> programmers focused on solving UX-workflow problems rather than
> general-purpose programming ones.
>
>
>
> On Wed, Dec 19, 2018 at 6:52 AM Isiah Meadows 
> wrote:
>
>> Could you bring that up in a different thread instead of driving this
>> off-topic? Also, please don't forget that a *very* significant chunk
>> of JS doesn't even run in a GUI environment (consider: servers, IoT,
>> satellites, etc.).
>>
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>> On Wed, Dec 19, 2018 at 1:33 AM kai zhu  wrote:
>> >>
>> >> I could go with an iterator equivalent, but I'd like to defer that to
>> >> the seemingly-planned "iterlib" thing that's been considered since
>> >> before ES2015 was released.
>> >
>> >
>> > i'm against iterator-based design-patterns and libraries, as they lack
>> a clear fit in most javascript solutions.  the vast majority of looping in
>> UX-workflows (javascript’s primary problem-domain) are over [serializable]
>> JSON lists/dicts/strings, where Array/Object/String looping-methods will
>> suffice.
>> >
>> > all other use-cases are uncommon/complicated enough that custom
>> for/while loops are usually better suited than custom-iterators.
>> >
>> > -kai
>> >
>> >
>> >
>> > On 18 Dec 2018, at 16:42, Mike Samuel  wrote:
>> >
>> > Fair enough.
>> >
>> > On Tue, Dec 18, 2018, 5:29 PM Isiah Meadows > wrote:
>> >>
>> >> I could go with an iterator equivalent, but I'd like to defer that to
>> >> the seemingly-planned "iterlib" thing that's been considered since
>> >> before ES2015 was released. Something that works with arrays is good
>> >> enough for now.
>> >>
>> >> BTW, your `ziperator` isn't really the same as my `Array.interpolate`
>> >> (which is better named `Array.interleave`). It needs to be this:
>> >>
>> >> ```js
>> >> function *ziperator(...iters) {
>> >> for (let i = 0; i < iters.length; i++) {
>> >> iters[i] = iters[i][Symbol.iterator]()
>> >> }
>> >> while (true) {
>> >> for (let i = 0; i < iters.length; i++) {
>> >> const {done, value} = iters[i].next()
>> >> if (done) return undefined
>> >> yield value
>> >> }
>> >> }
>> >> }
>> >> ```
>> >>
>> >> The optimized version is pretty straightforward (using private fields
>> >> + methods here):
>> >>
>> >> ```js
>> >> function ziperator(...iters) { return new InterleavedIterator(iters) }
>> >>
>> >> class InterleavedIterator {
>> >> #iters, #index
>> >> constructor(iters) { this.#iters = iters; this.#index = 0 }
>> >>     [Symbol.iterator]() { return this }
>> >> next(value) { return this.#invoke("next", value) }
>> >> throw(value) { return this.#invoke("throw", value) }
>> >> return(value) { return this.#invoke("return", value) }
>> >> #invoke(method, value) {
>> >> if (this.#iters == null) return {done: true, value: undefined}
>> >> const index = this.#index
>> >> this.#index = (index + 1) % this.#iters.length
>> >> const {done, value} = this.#iters[index][method](value)
>> >> if (done) this.#iters = undefined
>> >> return {done, value}
>> >> }
>> >> }
>> >> ```
>> >>
>> >> -
>> >>
>> >> Isiah Meadows
>> >> cont...@isiahmeadows.com
>> >> www.isiahmeadows.com
>> >> On Fri, Dec 14, 2018 at 2:55 PM Mike Samuel 
>> wrote:
>&g

Re: String identity template tag

[Mike Samuel]

Fair enough.

On Tue, Dec 18, 2018, 5:29 PM Isiah Meadows  I could go with an iterator equivalent, but I'd like to defer that to
> the seemingly-planned "iterlib" thing that's been considered since
> before ES2015 was released. Something that works with arrays is good
> enough for now.
>
> BTW, your `ziperator` isn't really the same as my `Array.interpolate`
> (which is better named `Array.interleave`). It needs to be this:
>
> ```js
> function *ziperator(...iters) {
> for (let i = 0; i < iters.length; i++) {
> iters[i] = iters[i][Symbol.iterator]()
> }
> while (true) {
> for (let i = 0; i < iters.length; i++) {
> const {done, value} = iters[i].next()
> if (done) return undefined
> yield value
> }
> }
> }
> ```
>
> The optimized version is pretty straightforward (using private fields
> + methods here):
>
> ```js
> function ziperator(...iters) { return new InterleavedIterator(iters) }
>
> class InterleavedIterator {
> #iters, #index
> constructor(iters) { this.#iters = iters; this.#index = 0 }
> [Symbol.iterator]() { return this }
> next(value) { return this.#invoke("next", value) }
> throw(value) { return this.#invoke("throw", value) }
> return(value) { return this.#invoke("return", value) }
> #invoke(method, value) {
> if (this.#iters == null) return {done: true, value: undefined}
> const index = this.#index
> this.#index = (index + 1) % this.#iters.length
> const {done, value} = this.#iters[index][method](value)
> if (done) this.#iters = undefined
> return {done, value}
> }
> }
> ```
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> On Fri, Dec 14, 2018 at 2:55 PM Mike Samuel  wrote:
> >
> >
> >
> > On Fri, Dec 14, 2018 at 2:26 PM Isiah Meadows 
> wrote:
> >>
> >> The main difference with that loop is that it's generalized to any
> number of arrays, not just two with the second array having length one less
> than the first. Otherwise, it'd look exactly the same. BTW, I like this
> route (`Array.interleave`) better since it doesn't have to result in just a
> single string result - it could just be an array of strings plugged into
> some API instead, or it could be procedurally streamed out in chunks.
> >
> >
> > Fair enough.
> > If you're not looking for something template tag specific then a simple
> zip over iterators should do it?
> >
> > function *ziperator(iterators) {
> > let progressed;
> > do {
> > progressed = false;
> > for (let iterator of iterators) {
> > for (let element of iterator) {
> > yield element;
> >     progressed = true;
> > break;
> > }
> > }
> > } while (progressed);
> > }
> >
> > console.log(Array.from(ziperator([ ['a', 'b', 'c'][Symbol.iterator](),
> [1, 2][Symbol.iterator]() ])).join(''));
> > // -> a1b2c
> >
> > (but optimized :)
> >
> >
> >
> >>
> >> On Fri, Dec 14, 2018 at 14:04 Mike Samuel  wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows 
> wrote:
> >>>>
> >>>> I'll point out Kai could be on to something, although I disagree
> `zip` would be the right abstraction. Maybe `Array.interleave(...arrays)`?
> You could do `Array.interleave(template, args).map(String).join("")` for
> similar effect, and it'd be more generally useful.
> >>>>
> >>>> The key here is that iteration would stop after the index hits any
> array's length, so it'd be polyfilled kinda like this:
> >>>>
> >>>> ```js
> >>>> Array.interpolate = (...args) => {
> >>>> let ret = []
> >>>> let lengths = []
> >>>> let count = 0
> >>>> for (let i = 0; i < args.length; i++) {
> >>>> lengths[i] = args[i].count
> >>>> }
> >>>> for (let index = 0; ; index++) {
> >>>> for (let i = 0; i < args.length; i++) {
> >>>> if (index === lengths[i]) return ret
> >>>> ret[count++] = args[i][index]
> >>>> }
> >>>> }
> >>>> }
> >>>> ```
> >>>>
> >>>> (This could be optimized, t

Re: String identity template tag

[Mike Samuel]

On Fri, Dec 14, 2018 at 2:26 PM Isiah Meadows 
wrote:

> The main difference with that loop is that it's generalized to any number
> of arrays, not just two with the second array having length one less than
> the first. Otherwise, it'd look exactly the same. BTW, I like this route
> (`Array.interleave`) better since it doesn't have to result in just a
> single string result - it could just be an array of strings plugged into
> some API instead, or it could be procedurally streamed out in chunks.
>

Fair enough.
If you're not looking for something template tag specific then a simple zip
over iterators should do it?

function *ziperator(iterators) {
let progressed;
do {
progressed = false;
for (let iterator of iterators) {
for (let element of iterator) {
yield element;
progressed = true;
break;
}
}
} while (progressed);
}

console.log(Array.from(ziperator([ ['a', 'b', 'c'][Symbol.iterator](), [1,
2][Symbol.iterator]() ])).join(''));
// -> a1b2c

(but optimized :)




> On Fri, Dec 14, 2018 at 14:04 Mike Samuel  wrote:
>
>>
>>
>> On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows 
>> wrote:
>>
>>> I'll point out Kai could be on to something, although I disagree `zip`
>>> would be the right abstraction. Maybe `Array.interleave(...arrays)`? You
>>> could do `Array.interleave(template, args).map(String).join("")` for
>>> similar effect, and it'd be more generally useful.
>>>
>>> The key here is that iteration would stop after the index hits any
>>> array's length, so it'd be polyfilled kinda like this:
>>>
>>> ```js
>>> Array.interpolate = (...args) => {
>>> let ret = []
>>> let lengths = []
>>> let count = 0
>>> for (let i = 0; i < args.length; i++) {
>>> lengths[i] = args[i].count
>>> }
>>> for (let index = 0; ; index++) {
>>> for (let i = 0; i < args.length; i++) {
>>> if (index === lengths[i]) return ret
>>> ret[count++] = args[i][index]
>>> }
>>> }
>>> }
>>> ```
>>>
>>> (This could be optimized, though.)
>>>
>>
>> As a data point, something like this loop appears in most of the template
>> tags I've written but
>> it's never had these precise semantics so I didn't bother putting it into
>> template-tag-common <https://www.npmjs.com/package/template-tag-common>.
>>
>> That library makes it easy to split the operation of a template tag into
>> 3 stages:
>> 1. An optional configuration stage accessed by calling the template tag
>> as a regular function: mytag({ /* options */)`...`
>> 2. Static analysis over the strings.   This is memoized.
>> 3. Computing a result from (options, strings, results of step 2,
>> interoplated values)
>>
>> The final loop (step 3) in the template tags I maintain tends to looks
>> like
>>
>> function computeResult(options, staticState /* from step 2 */, strings,
>> ...values) {
>>   let n = values.length;  // Could do Math.max(strings.length - 1,
>> values.length);
>>   let result = strings[0];  // Usually strings.raw
>>   for (let i = 0; i < n;) {
>> const interpolatedValue = f(options, staticState[i], values[i]);
>> // Sometimes code here looks backwards at the result to see if it
>> needs to avoid token-merging hazards.
>> result += interpolatedValue;
>> result += strings[++i];
>>   }
>>   return wrapResult(result);  // Produce a value of a type that
>> encapsulates the tag's security guarantees.
>> }
>>
>>
>>
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String identity template tag

[Mike Samuel]

On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows 
wrote:

> I'll point out Kai could be on to something, although I disagree `zip`
> would be the right abstraction. Maybe `Array.interleave(...arrays)`? You
> could do `Array.interleave(template, args).map(String).join("")` for
> similar effect, and it'd be more generally useful.
>
> The key here is that iteration would stop after the index hits any array's
> length, so it'd be polyfilled kinda like this:
>
> ```js
> Array.interpolate = (...args) => {
> let ret = []
> let lengths = []
> let count = 0
> for (let i = 0; i < args.length; i++) {
> lengths[i] = args[i].count
> }
> for (let index = 0; ; index++) {
> for (let i = 0; i < args.length; i++) {
> if (index === lengths[i]) return ret
> ret[count++] = args[i][index]
> }
> }
> }
> ```
>
> (This could be optimized, though.)
>

As a data point, something like this loop appears in most of the template
tags I've written but
it's never had these precise semantics so I didn't bother putting it into
template-tag-common .

That library makes it easy to split the operation of a template tag into 3
stages:
1. An optional configuration stage accessed by calling the template tag as
a regular function: mytag({ /* options */)`...`
2. Static analysis over the strings.   This is memoized.
3. Computing a result from (options, strings, results of step 2,
interoplated values)

The final loop (step 3) in the template tags I maintain tends to looks like

function computeResult(options, staticState /* from step 2 */, strings,
...values) {
  let n = values.length;  // Could do Math.max(strings.length - 1,
values.length);
  let result = strings[0];  // Usually strings.raw
  for (let i = 0; i < n;) {
const interpolatedValue = f(options, staticState[i], values[i]);
// Sometimes code here looks backwards at the result to see if it needs
to avoid token-merging hazards.
result += interpolatedValue;
result += strings[++i];
  }
  return wrapResult(result);  // Produce a value of a type that
encapsulates the tag's security guarantees.
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Object.assign interaction with __proto__ field.

[Mike Samuel]

Might it be a spec bug that in the below, o's prototype changes, and o.x
!== b.x?

const a = makeIntercepter();
const b = { x: 1 };
const o = Object.assign(
  {},
  a,
  b);

console.log(`o is plain Object: ${ Object.getPrototypeOf(o) ===
Object.prototype }`);

console.log(`b.x=${ b.x }, o.x=${ o.x }`);

function makeIntercepter() {
  return JSON.parse(
// Get an object that has an actual "__proto__" property.
'{ "__proto__": {} }',
// Replace the __proto__ property's value with one that
// traps assignment to x.
(key, value) => (
  (key === '__proto__')
? {
set x(v) {
  console.log(`intercepted ${ v }`);
},
get x() {
  return 2;
},
  }
: value));
}

In modern Chrome, Firefox, Safari I get
intercepted 1
getPrototypeOf(o)===Object.prototype: false
b.x=1, o.x=2
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Submitted for your approval, JSOX

[Mike Samuel]

On Thu, Sep 20, 2018 at 12:48 PM J Decker  wrote:

>
>
> That could occur in a stream.  (Although if it's a stream I would expect
> it to come in on a websocket rather than any sort of request) But
>
>someText{a,b,c}[1,2,3][1,2,3]
>
> [1][2]
>
> Those are valid streams of objects... How would  '][' be used?
>



// Attacker setup
let someText, a, b, c;
Object.defineProperty(
  Array.prototype, 3,
  {
get() {
  alert(`Intercepted ${ JSON.stringify(this) }`)
}
  });


// Loaded cross origin from victim
someText
{a,b,c}[1,2,3][1,2,3]


If I own an origin and load the victims JSON cross-origin, I can use
getters on Object and Array.prototype to get any object that is square
bracket dereferenced.

You might notice that my setup declares variables to avoid "Undefined
reference to someText" errors.  This could be mitigated by adding an
unpredictable field name to the first type definition for every response so
that the attacker always gets an "Undefined reference error".

someText
{a,b,c,R4nD0m}[1,2,3][1,2,3]

is not vulnerable since, although it is well-formed JS, evaluation fails
before the intercepted array is constructed.


I converted the non-identifier character test to a bit lookup and applied
> it in the JS parser. ( fixed like =,+,-,!,~,(,),<,>,... in unquoted
> contexts) but speaking of quotes a variant allowed is back-tick quoting...
> ` ` ; without the template/code aspects that implies with ES6.  what about
> content that's like
>
> { asdf : "hello
> world" }
> (\n literal is allowed to be collected, and/or \r) but JS would fault on
> multiline non-escaped-continuation...
>
> But I've been reflecting on something you said 'custom types'.
> I'm thinking of implementing basically typed-strings.   " ...
> "  (or like "abc""reconstructiondata" ); and registering fromJSOX handlers
> on the parser.  Which would be like parser.registerFromJSOX( "someType",
> function (string) { /* use string to create a thing */ } ).
> Types like 'color' might want to just emit as '#RRGGBBAA' with a toJSOX...
> but really be separate color channels internally.
>

I don't see any immediate security consequences to custom literals.  People
tend not to put side-effects in literal-ish types' constructors.
I would hope that developers would know to treat literal-ish types like
github.com/WICG/trusted-types with suspicion if it travels across a
security boundary or implement some signature checking scheme, and there's
no novel risk around unwisely registering a type to deserialize via JSOX
than via JSON revivers.

If you're already against global registries, please ignore the rest of this
comment.

Since JavaScript is now used for large systems with many modules from
different authors, it helps to be able to scope things to a module.

It's much harder to build secure systems when we can't reason about
security properties of modules in isolation.
When I, as a security reviewer, encounter a module that uses JSOX, I might
enumerate the types it deserializes and check that it vets those before
making auth decisions based on their content.
But if an application loads another module alongside the first which
registers a global JSOX handler, that reasoning may no longer be valid
since an input pipe to the first module may now include objects of types
its authors didn't forsee.
That means I have to treat any uses of registerFromJSOX that affect
parser's globally as a system-level hazard, not just a module-level hazard.
TLDR: many interesting security properties depend on human judgement;
humans can't do whole program analysis for most programs, so global
registries are effectively open sets; open sets complicate conservative
analyses which are often necessary for sound security reasoning.

https://github.com/mikesamuel/unduck/blob/HEAD/API.md (explainer
) is addressing
the flip side of some of JSOX and I managed to do without global registries.
There i used a composition pattern that brings a base object with an empty
registry into scope, and a registration method that returns a copy with a
larger registry.
{
let ud = require('unduck')
ud = ud.withTypes({ /* type description */ })
// more of the same

// Alternatively
// let ud = require('unduck')
//.withTypes(...)
//.withTypes(...);

// Apply
ud(/* untrusted input */)
}






>
>
>>
>>
>>>

>
> This allowed piggybacking on HTTP credentials if an attacker could get
> a victim to visit their page.
>
> The problem was that the meaning of [...] and {...} were specified in
> terms of global.Array and global.Object
> which could be replaced
>
> That's been fixed, but JSOX should probably be careful about any
> ambiguity with BlockStatement.
> IIUC,
>   { keyword: [] }
> is valid as a statement so there is some ambiguity there.
>
> Then I see examples like
>
> //-- the following...
> a { 

Re: Submitted for your approval, JSOX

[Mike Samuel]

On Wed, Sep 19, 2018, 4:41 PM Mike Samuel  wrote:

>
>
> On Wed, Sep 19, 2018, 4:07 PM J Decker  wrote:
>
>> (trimmed)
>>
>> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 19, 2018 at 12:01 PM J Decker  wrote:
>>>
>>>>
>>>> I know of no exploits; all resulting strings should be shorter than the
>>>> input (because of escapes \\ ).  The C version allocates a output buffer
>>>> that is the same size as the input, and moves decoded strings into it.
>>>> Structure characters [ { } ] , " ' `  don't transfer either.
>>>>
>>>
>>> Not a vulnerability in your JSOX implementation per se, but have you
>>> looked into whether there's exploitable ambiguity between JSOX and runs of
>>> ES BlockStatements and ExpressionStatements?
>>>
>>> JSON used to be vulnerable
>>> <https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
>>> to cross-site snooping.
>>>
>>> // In attacker page
>>> Array = function () { alert('Got ' + arguments[0]) };
>>> 
>>> http://other-origin/some-web-service-that-responds-with-a-json-array</a>
>>> ">
>>>
>>
>> Interesting; that applies to JSOX for Number, BigInt, Date, 
>>
>> Parenthesis (in the C version) fault while collecting an identifier as
>> being a non-identifier character as defined by Unicode Standards  (as
>> per rules of an identifier in ES6)
>> That lookup was omitted in the JS implementation.  (per character search
>> through several thousand values.)
>>
>> Parenthesis is reserved for code, expressions, parameter specifications,
>> and is (should be) forbidden except in strings.
>>
>
> My apologies.  I thought there were parentheses in the docs on npmjs but
> seeing what I pasted from there on my phone it's obvious that it's all
> curly brackets.
>
> As long as your syntax doesn't include parentheses, dots, or backticks
> you're probably fine.
>

Though I could probably make hay with an output that includes thee token
pair  ] [


>
>>
>>>
>>> This allowed piggybacking on HTTP credentials if an attacker could get a
>>> victim to visit their page.
>>>
>>> The problem was that the meaning of [...] and {...} were specified in
>>> terms of global.Array and global.Object
>>> which could be replaced
>>>
>>> That's been fixed, but JSOX should probably be careful about any
>>> ambiguity with BlockStatement.
>>> IIUC,
>>>   { keyword: [] }
>>> is valid as a statement so there is some ambiguity there.
>>>
>>> Then I see examples like
>>>
>>> //-- the following...
>>> a { firstField, secondField }
>>> [ a { 1, 2 }, a{5,6}, a{"val1","val2"} ]
>>>
>>> Ya, it's tempting to type parenthesis after an identifer (fixed above)
>>
>> [ {firstField:1, secondField:2 }, {firstField:5,secondField:6}, 
>> {firstField:"val1",secondField:"val2"} ]
>>
>> But that doesn't really generate any more data; (similar strings get
>> collapsed?)... and  on parsing, there's only one reference to 'firstField'
>> and 'secondField'... I was trying to ponder scenarios where the data grows
>> unbounded... but even in a case where there's a reference like
>>
>> [ {a:1, b:2 }, [ref[0],ref[0]], [ref[1],ref[1]], [ref[2],ref[2]] ]
>>
>> [ {a:1,b:2}, [ {a:1, b:2}, {a:1,b:2} ], [ [{a:1, b:2}, {a:1,b:2}],[{a:1, 
>> b:2}, {a:1,b:2}] ], [ [ [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ], [ 
>> [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ] ] ]
>>
>> But it's not really replicated data, in the meta data between parsing and
>> object assembly, it's an array of strings/numbers; and resolves to pointers
>> to existing data.
>>
>>
>> I haven't worked through your grammar, but I wonder whether a naive JSOX
>>> encoder might produce output like
>>> { looksLikeAStatementLabel: a{"val1", "val2"} }
>>>
>>
>> (yes, but not parentheses.  Because parens are not control characters,
>> the end up being gatherable into identifiers)
>>
>> or
>>> a
>>> { onlyField }
>>>
>>
>> The current parsing will drop 'onlyField' and result with {}.
>> It only 'pushes' the value into the container if there is a value.
>>
>> It was previously is a parsing error, no value for field... 'exp

Re: Submitted for your approval, JSOX

[Mike Samuel]

On Wed, Sep 19, 2018, 4:07 PM J Decker  wrote:

> (trimmed)
>
> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel  wrote:
>
>>
>>
>> On Wed, Sep 19, 2018 at 12:01 PM J Decker  wrote:
>>
>>>
>>> I know of no exploits; all resulting strings should be shorter than the
>>> input (because of escapes \\ ).  The C version allocates a output buffer
>>> that is the same size as the input, and moves decoded strings into it.
>>> Structure characters [ { } ] , " ' `  don't transfer either.
>>>
>>
>> Not a vulnerability in your JSOX implementation per se, but have you
>> looked into whether there's exploitable ambiguity between JSOX and runs of
>> ES BlockStatements and ExpressionStatements?
>>
>> JSON used to be vulnerable
>> <https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
>> to cross-site snooping.
>>
>> // In attacker page
>> Array = function () { alert('Got ' + arguments[0]) };
>> 
>> http://other-origin/some-web-service-that-responds-with-a-json-array</a>
>> ">
>>
>
> Interesting; that applies to JSOX for Number, BigInt, Date, 
>
> Parenthesis (in the C version) fault while collecting an identifier as
> being a non-identifier character as defined by Unicode Standards  (as
> per rules of an identifier in ES6)
> That lookup was omitted in the JS implementation.  (per character search
> through several thousand values.)
>
> Parenthesis is reserved for code, expressions, parameter specifications,
> and is (should be) forbidden except in strings.
>

My apologies.  I thought there were parentheses in the docs on npmjs but
seeing what I pasted from there on my phone it's obvious that it's all
curly brackets.

As long as your syntax doesn't include parentheses, dots, or backticks
you're probably fine.


>
>>
>> This allowed piggybacking on HTTP credentials if an attacker could get a
>> victim to visit their page.
>>
>> The problem was that the meaning of [...] and {...} were specified in
>> terms of global.Array and global.Object
>> which could be replaced
>>
>> That's been fixed, but JSOX should probably be careful about any
>> ambiguity with BlockStatement.
>> IIUC,
>>   { keyword: [] }
>> is valid as a statement so there is some ambiguity there.
>>
>> Then I see examples like
>>
>> //-- the following...
>> a { firstField, secondField }
>> [ a { 1, 2 }, a{5,6}, a{"val1","val2"} ]
>>
>> Ya, it's tempting to type parenthesis after an identifer (fixed above)
>
> [ {firstField:1, secondField:2 }, {firstField:5,secondField:6}, 
> {firstField:"val1",secondField:"val2"} ]
>
> But that doesn't really generate any more data; (similar strings get
> collapsed?)... and  on parsing, there's only one reference to 'firstField'
> and 'secondField'... I was trying to ponder scenarios where the data grows
> unbounded... but even in a case where there's a reference like
>
> [ {a:1, b:2 }, [ref[0],ref[0]], [ref[1],ref[1]], [ref[2],ref[2]] ]
>
> [ {a:1,b:2}, [ {a:1, b:2}, {a:1,b:2} ], [ [{a:1, b:2}, {a:1,b:2}],[{a:1, 
> b:2}, {a:1,b:2}] ], [ [ [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ], [ 
> [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ] ] ]
>
> But it's not really replicated data, in the meta data between parsing and
> object assembly, it's an array of strings/numbers; and resolves to pointers
> to existing data.
>
>
> I haven't worked through your grammar, but I wonder whether a naive JSOX
>> encoder might produce output like
>> { looksLikeAStatementLabel: a{"val1", "val2"} }
>>
>
> (yes, but not parentheses.  Because parens are not control characters, the
> end up being gatherable into identifiers)
>
> or
>> a
>> { onlyField }
>>
>
> The current parsing will drop 'onlyField' and result with {}.
> It only 'pushes' the value into the container if there is a value.
>
> It was previously is a parsing error, no value for field... 'expected ':'
> and a value' sort of thing; But I ran into '{}' which is a similar parsing
> state...
>
>
>
>> [ a(5), a("val1") ]
>> allowing an attacker to do
>> 
>> let onlyField = null;
>> function a(...data) {
>>   alert(`Got ${ data }`);
>> }
>> 
>> http://other-origin/jsox-web-service&quot</a>;>
>>
>> There's a lot of "ifs" in this scenario,
>> AND CORS solves a lot of these problems for origins that use it
>> AND browsers are less trust

Re: Submitted for your approval, JSOX

[Mike Samuel]

On Wed, Sep 19, 2018 at 12:01 PM J Decker  wrote:

> Again I think it's a matter of introduction; I am just fishing for
> knowledge from the more knowledgable; maybe what other JS types are
> important.
> I did include a discussion link https://gitter.im/sack-vfs/jsox .
>
> On Wed, Sep 19, 2018 at 8:14 AM Mike Samuel  wrote:
>
>> TC39 is not really a place to spec out new transport formats.
>>
>> You proposed builtin support for JSON5
>> <https://esdiscuss.org/topic/json5> last year.
>> JSON5 was speced and had some adoption but that was controversial because
>> JSON5 was not nearly as widely used as JSON.
>> This seems to offer more obvious benefits over JSON than JSON5, but it
>> doesn't yet approach the adoption threshold.
>>
>
> Yes, but JSON5 also won't handle bigint (other than as a string). (pure
> speculation).
> I'm not really proposing JSOX into the standard, but it is highly
> dependent on the standard (and yes, the subject doesn't say that at all)
>

Understood.


>
>> -
>>
>> IIUC, type tags can only reference builtin types with well-understood
>> semantics like Date and typed arrays or structs with default values defined
>> in the same JSON input.
>> No type referenced by JSON can be or extend a type defined by application
>> code.
>>
>
> (I am assuming you mean JSOX?) Yes types specified, (without the
> application registering information about that type) are not really 'types'
> they work more like macros.
> And there are lots of ways to instantiate types; for which, just sharing
> the same prototype isn't enough; a use case for that would be a 3D model
> which has lots of 'vector' and some 'matrix'es (and have bone structures
> which may be cyclic).
> that interface probably needs work;
>

Sorry, JSOX.  Thanks for explaining.


>
>> If that's not the case, please keep in mind though that deserialization
>> schemes that allow an external input to specify which types to construct
>> makes it easy for an attacker to forge objects that code might treat as
>> privileged because it assumes all instances are created internally.
>> https://www.owasp.org/index.php/Deserialization_of_untrusted_data
>> "Malformed data or unexpected data could be used to abuse application
>> logic, deny service, or execute arbitrary code, when deserialized."
>> See also "History of Java deserialization vulnerabilities" at
>> https://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10
>>
>
> Prototype binding is entirely controlled by the application; if registers
> objects of a certain type should use a certain prototype(or other
> construction method?), they will be that type alone, and not some arbitrary
> type... if some new macro was used the object will just get a blank
> prototype; which would be shared by others of that 'type'.
>


> And yes, the security note from JSON re eval() does still apply for a
> subset of valid input (since all JSON is valid),
>
> I know of no exploits; all resulting strings should be shorter than the
> input (because of escapes \\ ).  The C version allocates a output buffer
> that is the same size as the input, and moves decoded strings into it.
> Structure characters [ { } ] , " ' `  don't transfer either.
>

Not a vulnerability in your JSOX implementation per se, but have you looked
into whether there's exploitable ambiguity between JSOX and runs of ES
BlockStatements and ExpressionStatements?

JSON used to be vulnerable
<https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
to cross-site snooping.

// In attacker page
Array = function () { alert('Got ' + arguments[0]) };

http://other-origin/some-web-service-that-responds-with-a-json-array</a>
">

This allowed piggybacking on HTTP credentials if an attacker could get a
victim to visit their page.

The problem was that the meaning of [...] and {...} were specified in terms
of global.Array and global.Object
which could be replaced

That's been fixed, but JSOX should probably be careful about any ambiguity
with BlockStatement.
IIUC,
  { keyword: [] }
is valid as a statement so there is some ambiguity there.

Then I see examples like

//-- the following...
a { firstField, secondField }
[ a { 1, 2 }, a(5,6), a("val1","val2") ]

I haven't worked through your grammar, but I wonder whether a naive JSOX
encoder might produce output like
{ looksLikeAStatementLabel: a("val1", "val2") }
or
a
{ onlyField }
[ a(5), a("val1") ]
allowing an attacker to do

let onlyField = null;
function a(...data) {
  alert(`Got ${ data }`);
}

http://other-origin/jsox-web-

Re: Submitted for your approval, JSOX

[Mike Samuel]

TC39 is not really a place to spec out new transport formats.

You proposed builtin support for JSON5 
last year.
JSON5 was speced and had some adoption but that was controversial because
JSON5 was not nearly as widely used as JSON.
This seems to offer more obvious benefits over JSON than JSON5, but it
doesn't yet approach the adoption threshold.

-

IIUC, type tags can only reference builtin types with well-understood
semantics like Date and typed arrays or structs with default values defined
in the same JSON input.
No type referenced by JSON can be or extend a type defined by application
code.

If that's not the case, please keep in mind though that deserialization
schemes that allow an external input to specify which types to construct
makes it easy for an attacker to forge objects that code might treat as
privileged because it assumes all instances are created internally.
https://www.owasp.org/index.php/Deserialization_of_untrusted_data
"Malformed data or unexpected data could be used to abuse application
logic, deny service, or execute arbitrary code, when deserialized."
See also "History of Java deserialization vulnerabilities" at
https://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10

This already happens with plain JSON
,
so anything that allows external inputs to specify which internal types to
construct would have to include a "Security Considerations" section that
explains how this could be safely used by code that assumes that `if (x
instanceof InternalType)` then x came from internal code that made a
good-faith effort to only pass appropriate inputs to `new
InternalType(...)`.

On Tue, Sep 18, 2018 at 5:22 PM J Decker  wrote:

> (Thank you Rod Sterling)
>
> But seriously, I'd like to submit, for serious consideration, JSOX -
> JavaScript Object eXchange format.  It inherits all JSON syntax such that
> it is able to process any existing JSON.
>
> I'm, at this point, open to changing anything (or even omitting things),
> including the name.
>
> JSON is great.  JSON has some limits, and criticisms... JS/ES Grew , but
> JSON has to stay the same, similarly with whatever comes next I'd imagine.
>
> So a primary goal is to encode and decode ES6 objects for transport with a
> simple API such as JSOX.parse( object ), and JSOX.stringify( jsoxString ).
> But also keep with the simplicity of JSON,
> so it can be used in human readable circumstances.
>
> Types that are now (or soon) native to ES such as TypedArrays (binary
> data), BigInt types, and even the existing Date type, do not transport with
> JSON very well.  They become a non-identifable string, that requires extra
> code involving knowledge of the structure of the data being transferred to
> be able to restore the values to Date(), BigInt(), et al.
>
> So a few weeks ago I started considering what else, beyond these simple
> modifications might also be useful, or address criticisms of JSON.
> Handling the above types is really a trivial modification to most JSON
> parsers.  Each of the following modifications is really only a very slight
> change to behavior; although implementing typed-objects does initially
> involve changing error handling into identifer-fallback handling.
>
> I initially argued, that defining a object prototype
> 'card(name,address,zipcode,created)' which removes the redundant data for
> every following reference, (and is good, just for data reduction, which was
> argued 'gzip').  A JSON representation might be
> `{"name":"bob","address":"123
> street","zipcode":"5","created":1537304820} where if have a large
> number of the same record the same 'name':,'address':, etc is repeated in
> every record.  Where a typed-object's value in JSOX could be
> `card{:"bob","123 street","5",2018-09-18T21:07:00Z}`.  All objects that
> are revived as typed-objects share the same prototype, and before parsing,
> the prototypes to be used may be specified.  The amount of data to process
> is reduced, perhaps to a significant degree.
>
> So  '{' is about typed-objects.  This construct is not allowed
> in JSON.  But that then leads to  '['  - typed arrays, arrays
> don't really have redundant data potential like objects, but there are
> TypedArrays in ES.  There is no way to define a type of an array, but
> hardcoded types like 'ab', 'u8', 'ref' are used to revive binary data.  The
> bytes of the backing ArrayBuffer are encoded to base64, and included within
> '[' and ']' without quotes; using the brackets as quotes.
>
> A JSOX typed array is the 'ref' type.  A reference to another location in
> the current object can be specified, which allows encoding cyclic
> structures.
>
>
>
> https://github.com/d3x0r/jsox
> https://npmjs.com/package/jsox
>
> (Initial public reaction was not very helpful, but probably that's the
> fault of how it was introduced?)
>
> 

Re: Proxy target/handler access leak in Node

[Mike Samuel]

Nicely done!

One more reason to prefer WeakMaps to properties when relating objects and
secrets.



On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine 
wrote:

> A few weeks ago I’d commented on an open Node github issue regarding
> Proxies and inspection. While the bulk of the comment concerns an opinion
> that proxies should not be treated as special case, I included an example
> of a mechanism by which the current implementation allows outside code to
> access the target and handler objects of a proxy that it does not own.
>
> On reflection I realized this specific issue might be worth drawing more
> attention to.
>
> ```js
> const util = require('util');
>
> const victim = new Proxy({}, {
>   SECRET: 'Nothing outside can access this'
> });
>
> let secret;
>
> const invariantViolator = {
>   [util.inspect.custom](depth, options) {
> const { stylize } = options;
>
> options.showProxy = true;
>
> options.stylize = (value, color) => {
>   secret = value;
>   options.stylize = stylize;
>   return stylize(value, color);
> };
>
> return victim;
>   }
> };
>
> util.inspect(invariantViolator);
>
> console.log(secret); // 'Nothing outside can access this'
> ```
>
> The implication is that even if running Node with no C++ addons, it is
> presently possible for proxies to be violated using just the standard lib,
> which may be significant from a security perspective. I’m not sure if
> that’s the case in practice, but just in case, I figured I should try to
> get eyes on it.
>
> Note that even if this particular hole is patched, the "analog hole" (so
> to speak) of just analyzing the string output remains.
> ___
> 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: Small Proposal "!in"

[Mike Samuel]

On Thu, Jul 19, 2018 at 11:56 AM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> For me, `hasOwn` with the different operand order isn't a problem, but
>>> others may take a different view. Trying to keep the same order takes us
>>> down a route like `inOwn` which I can't say I care for.
>>>
>>
>> Nor me. I would argue for `on` (`'a' on b`), but that is a huge typo
>> footgun (especially for Colemak users) and maybe isn't clear enough about
>> its semantics.  I would argue that operators aren't camel cased in JS
>> though, so `hasown`/`inown`.
>>
>
> For what it's worth I was also thinking of an "on" operator when reading
> this message, so this is intuitive to me. I also think that is a separate
> idea to propose though.
>

"on" is a good name.  Agree on separate.



> Of couse the usage of `in` is most of the time is not recommended, but it
>>> has it place.
>>>
>>
>> What places does it have?
>> I remain unconvinced that `in` has significant enough use cases to
>> warrant high-level ergonomics
>> were it being proposed today.
>>
>> It exists, and it'll probably never be removed from the language, but I
>> don't think it should be taught
>> as a good part of the language, and linters should probably flag it.
>>
>
> Maybe a radical thought, but does this not apply to hasOwnProperty? If you
> have strong type management why test for a property? The one case I can
> think of is parsing JSON but I handle that with destructuring. Are there
> significant use cases for it? Should linters flag it?
>

Good questions.
Linters should flag
   x.hasOwnProperty(y)
since if you're unsure whether x has an own property y you're probably
unsure whether x has an own property 'hasOwnProperty'.

IIRC, destructuring traverses prototypes so see caveat about library code
and monkeypatching below.
const { toString: f } = {}
typeof f // 'funciton'

You're right that in the middle of an application an instance's type should
determine whether a property is present.
There are use cases at the periphery.

Use cases in bleeding edge JS include
* As you noted, operations on parsed JSON.  Even if you use revivers to
parse JSON to Maps instead of Objects
  you either need own property checks or Object.setPrototypeOf(parsed,
null) when populating the Map.
* Non-clobbering mass assignment.  Like Object.assign but that doesn't
overwrite existing properties in the assignee.
* Reliable hole detection in arrays: (1 !on [0, , 2])
* Adapters that use naming conventions between JS objects and external
systems, like between database field names and JS property names.
* Distinguishing between user-code-defined properties on a host object like
an HTML element and readonly host properties.

Many use cases for hasOwnProperty could be better supported by Map, Set,
and Object.create(null) including:
* Objects used as lookup tables.
* Lookup tables with special purpose fallback logic like message bundles
that fall back from locale 'aa-BB' to 'aa'.
* Configuration objects.
* Function options bundles.
but idiomatic JS hasn't caught up and some library code has to run on old
interpreters, so a transpiling `on` would be nice.
The last two are mostly an issue in library code that needs to be resilient
when loaded alongside monkeypatched prototypes.

Honorable mention:
* for(...in...) iteration broken
solved by for(...of...):
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Mike Samuel]

On Thu, Jul 19, 2018 at 8:54 AM Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On Wed, Jul 18, 2018 at 6:43 PM, Mike Samuel  wrote:
> > Reverse is problematic on String.  The index of a codepoint can't be
> > subtracted from String.length since length is not the count of
> codepoints.
>
> Don't take me wrong, I was not suggesting to add a `reverse` property.
> I was suggesting to add the Iteratable object in the prototype chain
> such that someone can implement extra property on the Iteratable /
> Iteratable.prototype object.
>

My mistake.  I assumed a goal was to allow implementing a generic
findLastIndex in
terms of find and reverse iterators.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Mike Samuel]

On Thu, Jul 19, 2018 at 10:40 AM Augusto Moura 
wrote:

> Of couse the usage of `in` is most of the time is not recommended, but it
> has it place.
>

What places does it have?
I remain unconvinced that `in` has significant enough use cases to warrant
high-level ergonomics
were it being proposed today.

It exists, and it'll probably never be removed from the language, but I
don't think it should be taught
as a good part of the language, and linters should probably flag it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Mike Samuel]

On Thu, Jul 19, 2018 at 9:26 AM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> > 'string' === typeof document.createElement('input').type
> > // true
>
> It should be noted this is a "loose check"; it does not determine whether
> or not the property exists when its value equals undefined. It also
> triggers getters, whereas `in` reports whether or not the property exists
> without triggering a getter.
>

Good point.   `in` does trigger "has" proxy handlers though, so neither is
side-effect free.



> ___
> 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: Small Proposal "!in"

[Mike Samuel]

On Thu, Jul 19, 2018 at 7:32 AM Andy Earnshaw 
wrote:

> Although I support the idea of `!in` (for the same reasons as T.J. Crowder
> mentioned, plus it's useful for duck typing), what some browsers do isn't a
> great argument as modern browsers follow the spec more closely with regards
> to inherited accessors like this and you'd never be able to use `!in` for
> an older browser.  However, you do have a point in that accessors can live
> anywhere in the prototype chain and an object's properties may not
> necessarily be 'owned' by the object in question:
>
> document.createElement('input').hasOwnProperty('type')
> // false
>

'string' === typeof document.createElement('input').type
// true


> So far, the main argument against has been that `hasOwnProperty()` is
> recommended over `in` as a more robust check.  I don't see how this is a
> valid concern, they clearly have different use cases and you're not going
> to solve that problem be excluding a negated `in` from the spec (`!(a in
> b)` is still easier to type than `!b.hasOwnProperty(a)`).  There are plenty
> of valid use cases for `in`, not least duck typing as mentioned before:
>

Agree re "not solving that problem by"
When I'm duck typing, I typically am testing typeof or truthiness of a
property, not just presence.

function feed(duck) {
> if ('quackPitch' in duck && duck.canSwim) {
> duck.give(defrostedPeas);
> }
> }
>

This code is brittle.  An attacker may be able to deny service by getting
`{ "quackPitch": true, "canSwim": true }` to a JSON decoder, but would not
be able to trigger an exception if you tested with typeof instead of in.

function robustFeed(duck) {
  if (duck.canSwim && typeof duck.give === 'function') {
duck.give(defrostedPeas);
  }
}

`in` provides a weak, confusable kind of duck typing.
JSON decoding attacks allow forging objects that satisfy `in` predicates,
encouraging conflating
objects from an untrusted source with objects from trusted code.
These forgeries often would not pass stronger predicates that test for the
typeof required properties.


> `!in` and `!instanceof` would be great additions to the operator sets.
>

Agree re !instanceof.  I'm still not seeing where developers do and should
use `in` or `!in` on a regular basis.


> On Thu, 19 Jul 2018 at 12:06 Tobias Buschor 
> wrote:
>
>> There are valid use-cases.
>> As an example, some browsers have "onfocus" as an own property of
>> "window", some as an inherited.
>>
>> ```js
>> if ('onfocus' !in window) {
>> // polyfill onfocus...
>> }
>> ```
>>
>>
>> Am Mi., 18. Juli 2018 um 18:32 Uhr schrieb Mike Samuel <
>> mikesam...@gmail.com>:
>>
>>>
>>>
>>> On Wed, Jul 18, 2018 at 12:21 PM Michael Theriot <
>>> michael.lee.ther...@gmail.com> wrote:
>>>
>>>> I think it is irrelevant; the operator already exists and I would
>>>> assume if you want the negation of it you are using it correctly in the
>>>> first place. Otherwise are you not just arguing for its removal altogether?
>>>> But to answer your question one case that comes to mind is trapping get/has
>>>> in a proxy handler.
>>>
>>>
>>> Why should we assume that only people who consistently use `in`
>>> correctly would want the negation?  It seems that people who use it
>>> incorrectly because they are confused about the precise semantics or don't
>>> care might want the negation too.  If there are more of the latter then we
>>> should not assume what you assume.
>>>
>>> Proxy handler code is important, but very few developers will ever write
>>> a proxy handler over their careers, so this seems like a marginal use case.
>>> Besides, Reflect.has is probably a better choice in a proxy handler.
>>>
>>> I am not arguing for removing `in`.  That would break the web.  I am
>>> just arguing for prioritizing changes that provide features that more
>>> closely match the semantics developers typically want over making it more
>>> convenient to write code that seems to work in casual testing but has
>>> subtly wrong semantics.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Wednesday, July 18, 2018, Mike Samuel  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
>>>>> michael.lee.ther...@gmail.com> wrote:
>>>>>
>>>>>> I think `in` and `instanceof` could both benefit from 

Re: Feature proposal

[Mike Samuel]

On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On Wed, Jul 18, 2018 at 5:31 PM, Michael Luder-Rosefield
>  wrote:
> > At the moment, we have:
> >
> > every
> > filter
> > find
> > findIndex
> > forEach
> > indexOf / lastIndexOf
> > map
> > reduce / reduceRight
> > some
> >
> > which is not very consistent at all. Perhaps we could add an `iterOrder`
> > method that changes the way the array is iterated through?
>
> Stupid question, but why are some of these methods implemented on
> String, Array, TypedArray, Map and Set, while all of them are
> Iteratable?
>

String is different from the others.
The String index methods deal with a contiguous subsequence of the
sequence, not the index of an element in the sequence.


> If we were to add all these methods on Iteratable, then one could add
> a `reverse` generator property on Iteratable.
>

Reverse is problematic on String.  The index of a codepoint can't be
subtracted from String.length since length is not the count of codepoints.


>   Iteratable.prototype.reverse = function* reverse() { … };
>   foo.reverse().forEach( e => console.log(e) )
>
> Though, this implies that all these objects implement the Iteratable
> prototype, and I am not sure what impact this might have on the Web.
>




-- 
> Nicolas B. Pierron
> ___
> 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: Small Proposal "!in"

[Mike Samuel]

On Wed, Jul 18, 2018 at 12:21 PM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> I think it is irrelevant; the operator already exists and I would assume
> if you want the negation of it you are using it correctly in the first
> place. Otherwise are you not just arguing for its removal altogether? But
> to answer your question one case that comes to mind is trapping get/has in
> a proxy handler.


Why should we assume that only people who consistently use `in` correctly
would want the negation?  It seems that people who use it incorrectly
because they are confused about the precise semantics or don't care might
want the negation too.  If there are more of the latter then we should not
assume what you assume.

Proxy handler code is important, but very few developers will ever write a
proxy handler over their careers, so this seems like a marginal use case.
Besides, Reflect.has is probably a better choice in a proxy handler.

I am not arguing for removing `in`.  That would break the web.  I am just
arguing for prioritizing changes that provide features that more closely
match the semantics developers typically want over making it more
convenient to write code that seems to work in casual testing but has
subtly wrong semantics.







> On Wednesday, July 18, 2018, Mike Samuel  wrote:
>
>>
>>
>> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
>> michael.lee.ther...@gmail.com> wrote:
>>
>>> I think `in` and `instanceof` could both benefit from having negated
>>> versions.
>>>
>>> Assuming the developer is using `in` correctly, hasOwnProperty concerns
>>> are irrelevant. Either way they would attempt to use !(a in b), not
>>> !hasOwnProperty.
>>>
>>
>> Why should we assume the developer is using `in` correctly?
>> Apologies if I buried my question at the end.  It was, what are the use
>> cases for `in` that would not be better served by an ergonomic, infix
>> hasOwnProperty?
>>
>>
>> Same reason we don't use...
>>> !(a == b) // a != b
>>> !(a === b) // a !== b
>>>
>>
>>
>>> !(a > b) // a <= b
>>> (!(a > b) && !(a == b)) // a < b
>>>
>>
>> I'm not sure this is relevant to your larger point, and I've already
>> conceded ergonomics, but
>> these last two are not equivalent because NaN is weird.
>>
>> a = NaN, b = 0
>> [!(a > b), a <= b]  // [true, false]
>> [!(a > b) && !(a == b), a < b]  // [true, false]
>>
>>
>>
>>
>>
>>> On Thursday, June 28, 2018, Tobias Buschor 
>>> wrote:
>>>
>>>> I dont like to write:
>>>> if ( !('x' in obj) &&  !('y' in obj) ) {
>>>>  doit()
>>>> }
>>>>
>>>> I was even tempted to write it that way:
>>>> if ('x' in obj  ||  'y' in obj) { } else {
>>>>  doit()
>>>> }
>>>>
>>>> What about a !in operator to write it like this?
>>>> if ('x' !in obj  &&  'y' !in obj) {
>>>>  doit()
>>>> }
>>>>
>>>> ___
>>> 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

Fwd: Small Proposal "!in"

[Mike Samuel]

[sorry dropped group]

On Fri, Jul 13, 2018 at 11:36 AM  wrote:

> This may be a silly idea that doesn't come naturally to others, but the
> first thing I thought of was "!n", where the "!" represents a flipped
> "i", so the inverse of in.
>

You'd need yet another restricted production which would make infix `in`
unrestricted
but the negation restricted.

x  // no semicolon inserted
in (obj)

x  // semicolon inserted
!n (obj)

Not a blocker, but worth keeping in mind.
I also have to look hard at them to distinguish.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Mike Samuel]

On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> I think `in` and `instanceof` could both benefit from having negated
> versions.
>
> Assuming the developer is using `in` correctly, hasOwnProperty concerns
> are irrelevant. Either way they would attempt to use !(a in b), not
> !hasOwnProperty.
>

Why should we assume the developer is using `in` correctly?
Apologies if I buried my question at the end.  It was, what are the use
cases for `in` that would not be better served by an ergonomic, infix
hasOwnProperty?


Same reason we don't use...
> !(a == b) // a != b
> !(a === b) // a !== b
>


> !(a > b) // a <= b
> (!(a > b) && !(a == b)) // a < b
>

I'm not sure this is relevant to your larger point, and I've already
conceded ergonomics, but
these last two are not equivalent because NaN is weird.

a = NaN, b = 0
[!(a > b), a <= b]  // [true, false]
[!(a > b) && !(a == b), a < b]  // [true, false]





> On Thursday, June 28, 2018, Tobias Buschor 
> wrote:
>
>> I dont like to write:
>> if ( !('x' in obj) &&  !('y' in obj) ) {
>>  doit()
>> }
>>
>> I was even tempted to write it that way:
>> if ('x' in obj  ||  'y' in obj) { } else {
>>  doit()
>> }
>>
>> What about a !in operator to write it like this?
>> if ('x' !in obj  &&  'y' !in obj) {
>>  doit()
>> }
>>
>> ___
> 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: Small Proposal "!in"

[Mike Samuel]

On Wed, Jul 11, 2018 at 1:51 PM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Wed, Jul 11, 2018 at 4:51 PM, Alex Vincent  wrote:
> > In Linux programming, #!/bin/bash is very commonly the first line of a
> shell
> > script. In Python, we have #!/bin/python, or #!/bin/perl.  The #!
> characters
> > are pronounced "she-bang", because # is pronounced "hash" and ! is
> > pronounced "bang".
>
> Indeed. But in JavaScript (and Java and C and C# and...), `!` is "not",
> and I for one read it that way when reading anything other than bash
> script. I don't read `!==` as "bang equal," either. (Which in British
> English would be really misleading...)
>
> And that's why I like the idea of `!in` (or `notin`), because I'd much
> rather read and write "if property not in object" than "if not property in
> object" (and don't get me started on the parens required to make it work
> :-) ).
>
> To me, `!in` or `notin` or whatever you want makes perfect sense, just
> like we have `!=` and `!==`. It's like not having `!==` and then arguing we
> don't need to have it because after all, you can write `n != 1` as `!(n ==
> 1)`.
>


> Heck, all we really need is NAND gates, right? ;-)
>





> On Wed, Jul 11, 2018 at 6:33 PM, Isiah Meadows 
> wrote:
> > So I agree this is a Really Bad Idea™, for this above if not the Kotlin
> > reference.
>
> I strongly disagree it's a Really Bad Idea™. I think it's a Moderately
> Good Idea On The Whole™. And `!in` is fine by me but I'm also happy with
> `notin` or whatever.
>

I agree with all your arguments about why it's more ergonomic, but I keep
coming back to what Naveen said: "I don't use `in`."

I think `in` is the wrong operator to make more convenient, except as part
of a more general cleanup to provide inverted forms of boolean infix
operators.

Usually, where I see `in` I would prefer that the author had used
hasOwnProperty.
And usually where I see (foo.hasOwnProperty(p)), I would prefer the author
wrote Reflect.apply(hasOwnProperty, foo, [p]).

What are the use cases for `in` that would not be better served by an
ergonomic, infix hasOwnProperty?


I just don't expect it to happen. Too much inertia to add it
> after-the-fact, and too many bigger fish to fry. :-)
>


> -- T.J. Crowder
> ___
> 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: FW: Proposal: safeEval

[Mike Samuel]

On Fri, Jun 22, 2018, 6:51 PM doodad-js Admin  wrote:

> *This is silly.  I can want these without wanting them built using
> substandard tools.*
>
>
>
> That’s the point why I bring it to ES. Nothing on the “user land” can
> provide something reliable, apart a complete JS runtime library compiled to
> “WASM” or “asm.js”. And... that’s silly.
>
>
>
For the last time, why do you believe opcode filtering can?



>
> *From:* Mike Samuel 
> *Sent:* Friday, June 22, 2018 6:04 PM
> *To:* doodad-js Admin 
> *Cc:* Isiah Meadows ; es-discuss <
> es-discuss@mozilla.org>
> *Subject:* Re: FW: Proposal: safeEval
>
>
>
>
>
> On Fri, Jun 22, 2018, 5:30 PM doodad-js Admin  wrote:
>
> *“Blacklisting or whitelisting, that’s an open discussion”: It really
> isn't.*
>
>
>
> So for you, blacklisting or whitelisting is not opened to a discussion?
>
> No.
>
> Case based reasoning doesn't work when the partition of cases can't be
> enumerated so if we want confidence in our tools we ought prefer
> whitelisting.
>
>
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_2334123076367658371_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

[Mike Samuel]

On Fri, Jun 22, 2018, 5:30 PM doodad-js Admin  wrote:

> *“Blacklisting or whitelisting, that’s an open discussion”: It really
> isn't.*
>
>
>
> So for you, blacklisting or whitelisting is not opened to a discussion?
>
No.
Case based reasoning doesn't work when the partition of cases can't be
enumerated so if we want confidence in our tools we ought prefer
whitelisting.


*No it isn't.  As I mentioned earlier, a combination of source code
> rewriting, out of language isolation, and special purpose libraries have a
> better track record than AST filtering for general purpose programming
> languages.*
>
>
>
> So, you don’t want JS code interpretation inside “user reports formulas”,
> “template engines”, “compiler tools”, ...?
>
This is silly.  I can want these without wanting them built using
substandard tools.



>
> Claude
>
>
>
>
>
> *From:* Mike Samuel 
> *Sent:* Friday, June 22, 2018 5:06 PM
> *To:* doodad-js Admin 
> *Cc:* Isiah Meadows ; es-discuss <
> es-discuss@mozilla.org>
> *Subject:* Re: FW: Proposal: safeEval
>
>
>
>
>
> On Fri, Jun 22, 2018, 4:56 PM doodad-js Admin  wrote:
>
> Thanks,
>
>
>
> *If you blacklist.*
>
>
>
> Blacklisting or whitelisting, that’s an open discussion.
>
> It really isn't.
>
>
>
> *Yet you're providing a library that does just that*
>
>
>
> Because that’s a “user land” library and currently the only way is with
> “AST filtering”, apart from compiling a complete runtime, with Emscripten
> or else.
>
> No it isn't.  As I mentioned earlier, a combination of source code
> rewriting, out of language isolation, and special purpose libraries have a
> better track record than AST filtering for general purpose programming
> languages.
>
>
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
> Virus-free. www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

[Mike Samuel]

On Fri, Jun 22, 2018, 4:56 PM doodad-js Admin  wrote:

> Thanks,
>
>
>
> *If you blacklist.*
>
>
>
> Blacklisting or whitelisting, that’s an open discussion.
>
It really isn't.

*Yet you're providing a library that does just that*
>
>
>
> Because that’s a “user land” library and currently the only way is with
> “AST filtering”, apart from compiling a complete runtime, with Emscripten
> or else.
>
No it isn't.  As I mentioned earlier, a combination of source code
rewriting, out of language isolation, and special purpose libraries have a
better track record than AST filtering for general purpose programming
languages.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

[Mike Samuel]

On Fri, Jun 22, 2018, 4:21 PM doodad-js Admin  wrote:

>
>
> *you've provided no reason to believe that opcode filtering would provide
> a better balance between security and ease of writing than AST filtering*
>
>
>
> AST filtering is fragile because every change on the language can break it.
>
If you blacklist.

Yet you're providing a library that does just that and have still provided
no reason to believe that an opcode filtering proposal would be both more
secure and less brittle.



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

Re: FW: Proposal: safeEval

[Mike Samuel]

On Wed, Jun 20, 2018 at 9:52 PM doodad-js Admin  wrote:

> Thanks
>
>
>
> *How can we discuss your idea separately from the library?*
>
>
>
> I’m more thinking at the runtime level than at the “user land”. To be
> honest, I don’t care of “safeEval” on “user land”.
>

You seem to be asking for criticism, but seem to not want criticism of the
only thing that has enough detail for criticism.


> *You talk about options and ACLs but the only hint as to what those might
> mean is the library*
>
> *How would the idea work if not by tree filtering?  AdSAFE did that but
> writing AdSAFE was very different from writing vanilla JS.*
>
>
>
> Yeah, sorry. The purpose is to offer something like “opcode” filtering,
> but in a more expressive and user-friendly way.
>

EcmaScript is specified as a tree interpreter that produces completion
records, not in terms of an ISA.
The spec does not define opcodes, and you've provided no reason to believe
that opcode filtering would provide a better balance between security and
ease of writing than AST filtering.

Having written a JS sandbox, I'm skeptical that either approach would work.
All successful approaches have combined static analysis with at least 2 of
1. large dedicated runtime libraries,
2. source code rewriting, and
3. separation/isolation via realm/origin/worker.
Any pair of these are going to require detailed correctness arguments to
pass muster.

I don't see how we could compare the benefits of your proposal to any other
without a lot more detail.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

[Mike Samuel]

How can we discuss your idea separately from the library?

You talk about options and ACLs but the only hint as to what those might
mean is the library.

How would the idea work if not by tree filtering?  AdSAFE did that but
writing AdSAFE was very different from writing vanilla JS.


On Wed, Jun 20, 2018, 9:12 PM doodad-js Admin  wrote:

> I don't want to propose you my library, I want to propose you the idea.
>
> -Original Message-
> From: impinb...@gmail.com  On Behalf Of Isiah Meadows
> Sent: Wednesday, June 20, 2018 7:57 PM
> To: Mike Samuel 
> Cc: doodad-js Admin ; es-discuss <
> es-discuss@mozilla.org>
> Subject: Re: FW: Proposal: safeEval
>
> Just a quick read, but that's a *terrible* set of ACLs, and I strongly
> dislike the idea in general. That utility is trivially broken in multiple
> ways (won't announce them on-list, but I've emailed Claude privately), and
> I'm pretty convinced the idea itself is broken.
> Limiting syntax is incredibly ineffective for anything security-related,
> because there are an infinite number of ways to express something in JS,
> but only a finite number of ways you can realistically limit it without
> breaking it for normal users or just disabling scripting altogether. It
> also doesn't stop them from accessing various globals to screw with you.
>
> To give a concrete example of why syntactic analysis is a bad idea for
> security, let's consider eBay's encounter with JSFuck [1] [2]. Because that
> literally uses only six seemingly benign characters, `[`, `]`, `!`, `+`,
> `(`, and `)`, you can only protect against it by disallowing calls, which
> make general use nearly impossible. It was difficult enough that eBay
> initially gave up [2], until it resulted in rampant, virtually untraceable
> fraud in the wild [3].
>
> Now, if you disallow parentheses, you also have to ban assignment if any
> of your scripts has an ID [4], because attackers can use that to their
> advantage to accomplish the same objective. Claude has an option for that
> in his library, but it's not especially obvious you'd need it to prevent
> arbitrary code execution.
>
> Frozen realms together with closures provide privilege separation through
> offering capabilities, which addresses who can read and/or write what.
> Capabilities are better than ACLs when it comes to security, because if you
> limit what they can try, they can't do what they can't try. They can't read
> what they can't even try to access.
>
> If you want real security, focus on what people can try, not what they can
> do. And this is why I say this entire proposal is complete and utter crap.
>
> [1]: https://github.com/aemkei/jsfuck
> [2]:
> https://arstechnica.com/information-technology/2016/02/ebay-has-no-plans-to-fix-severe-bug-that-allows-malware-distribution/
> [3]:
> https://news.softpedia.com/news/jsf-ebay-xss-bug-exploited-in-the-wild-despite-the-company-s-fix-500651.shtml
> [4]: http://syllab.fr/projets/experiments/sixcharsjs/5chars.html
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel  wrote:
> >
> >
> > On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin 
> wrote:
> >>
> >>
> >>
> >> I was not aware of that proposal or didn’t pay attention.I think
> >> “safeEval” provides ACLs, while your proposal don’t.
> >
> >
> > Neither the realms proposal nor the frozen realms proposal include ACLs.
> >
> > Where are the ACLs in safeeval?
> > I see some privileges via options at L72-75:
> > const preventAssignment = types.get(options, 'preventAssignment',
> > true), allowFunctions = types.get(options, 'allowFunctions', false),
> > // EXPERIMENTAL allowNew = types.get(options, 'allowNew', false), //
> > EXPERIMENTAL allowRegExp = types.get(options, 'allowRegExp', false);
> > // EXPERIMENTAL but, as I understand the term, ACLs are usually the
> > set of privileges available to a principal, the rows in an access
> > control matrix.
> > How are you defining "principal?"
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

[Mike Samuel]

On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin  wrote:

>
>
> I was not aware of that proposal or didn’t pay attention.I think
> “safeEval” provides ACLs, while your proposal don’t.
>

Neither the realms proposal nor the frozen realms proposal include ACLs.

Where are the ACLs in safeeval?
I see some privileges via options at L72-75

:
const preventAssignment = types.get(options, 'preventAssignment', true),
allowFunctions = types.get(options, 'allowFunctions', false), //
EXPERIMENTAL
allowNew = types.get(options, 'allowNew', false), // EXPERIMENTAL
allowRegExp = types.get(options, 'allowRegExp', false); // EXPERIMENTAL
but, as I understand the term, ACLs are usually the set of privileges
available to a principal, the rows in an access control matrix.
How are you defining "principal?"
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline ES Modules

[Mike Samuel]

On Wed, Jun 20, 2018 at 10:44 AM Sultan  wrote:

>
> Additionally there are aspects that bundlers have a hard time replicating
> when using ES modules as an authoring format. Consider the following
> example, where ES modules might maintain a "live" binding.
>
> ```
> // a.js
> import {b} from './b.js'
>
> setTimeout(() => console.log(b), 400)
>
> // b.js
> export var b = 1
>
> setTimeout(() => b++, 200)
> ```
>
> A bundler on the other hand might be forced to produce static bindings.
>
> ```
> var $b1 = 1
>
> setTimeout(() => $b1++, 200)
>
> var $b2 = $b1
>
> setTimeout(() => console.log($b1), 400)
> ```
>

 Or recognize bindings that might be reassigned and use the mangled export
binding directly instead of introducing a local for the import bindings:

```
var $b1 = 1
setTimeout(() => $b1++, 200)

setTimeout(() => console.log($b1), 400)
```

Or allocate a cell for reassignable bindings:

```
var $b1 = [1]
setTimeout(() => $b1[0]++, 200)

var $b2 = $b1
setTimeout(() => console.log($b2[0]), 400)
```

No?

Maybe I'm treading on "sufficiently smart transpiler" territory but it
seems to me that live bindings can be handled simply with a bit of overhead
that can be often eliminated in the common case with only local analysis.

And to the degree that this is a problem, it's a problem as long as there's
a gap between inline module support becoming available and bundlers
end-of-lifing support for previous versions of EcmaScript as an output
language option.

Unless I'm missing something,  inline modules are unnecessary for live
bindings and insufficient given the need to support older versions as
output languages for at least some time.



Did you address my question about importing inline modules?  If so, I
must've missed it.



> They would act akin to hoisted functions declarations in that regard,

I'm also unclear what function hoisting has to do with module declarations
inside loops or conditionals if that's allowed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Inline ES Modules

[Mike Samuel]

On Tue, Jun 19, 2018 at 9:50 PM Darien Valentine 
wrote:

> Aha! Thanks. I think I get what you mean now.
>
> Let’s say I have this CSP:
>
> ```
> content-security-policy: script-src 'nonce-foo'
> ```
>
> And I have this in my document:
>
> ```
> 
>   import 'data:text/javascript,console.log(`bar`)';
> 
> ```
>
> Then the browser could theoretically ignore the absence of 'data:' in the
> CSP safely because the import statement here is part of a nonce-allowed
> script. And the unsafety is adding `data:` to the CSP (which would then be
> available for third party scripts I might also allow), not using `data:` in
> my own trusted modules; and there is a minor bit of unsafety associated
> with dynamic import, but it’s not in the same league as the unsafety
> potentially implied by a blanket permission for all `data:` URI sources.
>
> I was surprised that this nuance was considered. I figured it just blindly
> asked "is this source permitted by the CSP" without taking into account
> whether the trust from a parent resource could be implicitly extended. But
> I see you’re totally right:
>
> ```
> 
> 
> 
>   import 'data:text/javascript,document.open();document.writeln(`<p>static
> import of data URI module worked</p>`)';
>   document.writeln(`<p>nonce module worked</p>`);
>   import('data:text/javascript,document.writeln(`<p>dynamic import of data
> URI module worked</p>`)');
> 
> ```
>
> demo: https://necessary-hallway.glitch.me/
>
> All three seem to work! Very cool.
>

https://github.com/w3c/webappsec-csp/issues/243 : "Any protection against
dynamic module import?"
captures the discussion on this.


> Sorry for the diversion from the main topic. This was really interesting
> and I appreciate the explanation.
>
>
> On Tue, Jun 19, 2018 at 8:58 PM Mike Samuel  wrote:
>
>> Sorry for the confusion.
>>
>> Nonces are just for elements with url attributes.
>>
>> I mentioned nonces to point out that strict CSP policies can allow some
>> data: urls without having to explicitly whitelist or hash the entire
>> content.
>>
>> Separately I wanted to say that there is no incompatibility between the
>> goals of CSP and import statements that use a data: module specifier, since
>> we already trust the compilation unit and there's no actual network message
>> leaked.
>>
>> But there is a risk with the import operator since it's input is not part
>> of an already trusted input.
>>
>> On Tue, Jun 19, 2018, 8:22 PM Darien Valentine 
>> wrote:
>>
>>> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
>>> just for whitelisting inline script elements. How does one specify a nonce
>>> in association with a data URI? I’m having trouble turning up a description
>>> / example of how it would work. Or possibly I’m misunderstanding this quite
>>> a bit, hm ... I’m also confused by the relationship between import/import()
>>> and XSS that you’ve described.
>>>
>>> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel 
>>> wrote:
>>>
>>>> CSP with data URIs is possible via nonce sources.  For data: module
>>>> descriptors browsers could safely skip the CSP check since it doesn't allow
>>>> XSS unless one can already specify an import statement which typically
>>>> means one can specify arbitrary JS.  That argument doesn't extend to the
>>>> import operator though so you'd have to tolerate assymetry there.
>>>>
>>>> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine 
>>>> wrote:
>>>>
>>>>> Andrea: That is a really interesting approach. I would point out that
>>>>> using data URIs for js means the `data:` scheme has to be a permitted
>>>>> source for script-src. This allowance has roughly the same security
>>>>> implications as permitting `unsafe-eval`. I know most people aren’t using
>>>>> CSPs yet, but personally I’d be wary of a solution that makes it harder to
>>>>> adopt a strong CSP.
>>>>>
>>>>> A super dorky/tangential aside that probably doesn’t matter at all but
>>>>> ... I notice you used application/javascript for the media type. There’s a
>>>>> contradiction between the IANA media type registry and the HTML 5 spec 
>>>>> with
>>>>> regard to the "correct" media type to use for JS. RFC 4329 says
>>>>> application/javascript is the only value that should be used, while HTML
>>>>> says text/jav

Re: Proposal: safeEval

[Mike Samuel]

How would this compare to https://github.com/tc39/proposal-frozen-realms ?

I'm not sure how to run @doodad-js/safeeval in node since require doesn't
provide obvious access to safeeval, but the code seems to do AST filtering.
What does it do for inputs like

safeEval(' 0..constructor.constructor("alert(1)")() ')
safeEval(' 0[x][x]`alert(1)`() ', { x: 'constructor' })
safeEval(' 0[x][y] = null ', { x: 'prototype', y: 'toString' })



On Tue, Jun 19, 2018 at 10:29 PM doodad-js Admin  wrote:

> Hi,
>
>
>
> I take a chance to valorize “eval” again by proposing “safeEval”.
>
>
>
> function safeEval(expression, [locals], [options]) {
>
> ..
>
> };
>
>
>
> So that you can:
>
>
>
> safeEval(“1 + a”, {a: 2});// returns “3”
>
> safeEval(“1 + a()”, {a: function() {return 2}}, {allowFunctions:
> true});// also returns “3”
>
>
>
> but:
>
>
>
> safeEval(“1 + a()”, {a: function() { return 2}});// throws whatever
> you want because “allowFunctions” is denied
>
>
>
> etc.
>
>
>
> Note that local variables are specified in argument. Also note that
> “options” mainly gives/denies permissions. I’m not sure if we should be
> whitelisting or blacklisting features there though, or a mix of default
> enabled and disabled ones...
>
>
>
> Very incomplete, but as for inspiration (and very useful to me):
> https://www.npmjs.com/package/@doodad-js/safeeval
>
>
>
>
>
> Claude
>
>
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-6456435073511435867_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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: Re: Inline ES Modules

[Mike Samuel]

Sorry for the confusion.

Nonces are just for elements with url attributes.

I mentioned nonces to point out that strict CSP policies can allow some
data: urls without having to explicitly whitelist or hash the entire
content.

Separately I wanted to say that there is no incompatibility between the
goals of CSP and import statements that use a data: module specifier, since
we already trust the compilation unit and there's no actual network message
leaked.

But there is a risk with the import operator since it's input is not part
of an already trusted input.

On Tue, Jun 19, 2018, 8:22 PM Darien Valentine 
wrote:

> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
> just for whitelisting inline script elements. How does one specify a nonce
> in association with a data URI? I’m having trouble turning up a description
> / example of how it would work. Or possibly I’m misunderstanding this quite
> a bit, hm ... I’m also confused by the relationship between import/import()
> and XSS that you’ve described.
>
> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel  wrote:
>
>> CSP with data URIs is possible via nonce sources.  For data: module
>> descriptors browsers could safely skip the CSP check since it doesn't allow
>> XSS unless one can already specify an import statement which typically
>> means one can specify arbitrary JS.  That argument doesn't extend to the
>> import operator though so you'd have to tolerate assymetry there.
>>
>> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine 
>> wrote:
>>
>>> Andrea: That is a really interesting approach. I would point out that
>>> using data URIs for js means the `data:` scheme has to be a permitted
>>> source for script-src. This allowance has roughly the same security
>>> implications as permitting `unsafe-eval`. I know most people aren’t using
>>> CSPs yet, but personally I’d be wary of a solution that makes it harder to
>>> adopt a strong CSP.
>>>
>>> A super dorky/tangential aside that probably doesn’t matter at all but
>>> ... I notice you used application/javascript for the media type. There’s a
>>> contradiction between the IANA media type registry and the HTML 5 spec with
>>> regard to the "correct" media type to use for JS. RFC 4329 says
>>> application/javascript is the only value that should be used, while HTML
>>> says text/javascript is the only value that should be used. I believe (not
>>> sure though) that this is because it’s the most backwards-compatible value.
>>> Given that the media types registry seems to be basically dead to web
>>> standards (if we follow the registry we can’t serve or post a bunch of
>>> media types acknowledged or defined by web standards at all, including
>>> image/webp, application/csp-report, etc) and the code has to run in a
>>> browser, I’d tend to think HTML is the better spec to follow ... though I
>>> guess when two specs contradict each other it’s hard to make an objective
>>> case for one being more authoritative. (I’d be curious if there’s a
>>> specific reason you know of to prefer to RFC definition though. When
>>> standards don’t align it breaks my tiny heart.)
>>>
>>> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> sorry, I meant:
>>>>
>>>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking)
>>>> ;
>>>>
>>>>
>>>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>>
>>>>> I think these are all nice to have features, but I also think we have
>>>>>> all the primitives we need to make it happen via pre-processing.
>>>>>>
>>>>>>>
>>>>> I meant even synchronously, with a pre-processor that replace the
>>>>> imported module with
>>>>>
>>>>> 'data:text/javascript,' +
>>>>> JSON.stringify(moduleContentAfterTreeShaking);
>>>>>
>>>>
>>>> ___
>>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Inline ES Modules

[Mike Samuel]

CSP with data URIs is possible via nonce sources.  For data: module
descriptors browsers could safely skip the CSP check since it doesn't allow
XSS unless one can already specify an import statement which typically
means one can specify arbitrary JS.  That argument doesn't extend to the
import operator though so you'd have to tolerate assymetry there.

On Tue, Jun 19, 2018, 7:57 PM Darien Valentine 
wrote:

> Andrea: That is a really interesting approach. I would point out that
> using data URIs for js means the `data:` scheme has to be a permitted
> source for script-src. This allowance has roughly the same security
> implications as permitting `unsafe-eval`. I know most people aren’t using
> CSPs yet, but personally I’d be wary of a solution that makes it harder to
> adopt a strong CSP.
>
> A super dorky/tangential aside that probably doesn’t matter at all but ...
> I notice you used application/javascript for the media type. There’s a
> contradiction between the IANA media type registry and the HTML 5 spec with
> regard to the "correct" media type to use for JS. RFC 4329 says
> application/javascript is the only value that should be used, while HTML
> says text/javascript is the only value that should be used. I believe (not
> sure though) that this is because it’s the most backwards-compatible value.
> Given that the media types registry seems to be basically dead to web
> standards (if we follow the registry we can’t serve or post a bunch of
> media types acknowledged or defined by web standards at all, including
> image/webp, application/csp-report, etc) and the code has to run in a
> browser, I’d tend to think HTML is the better spec to follow ... though I
> guess when two specs contradict each other it’s hard to make an objective
> case for one being more authoritative. (I’d be curious if there’s a
> specific reason you know of to prefer to RFC definition though. When
> standards don’t align it breaks my tiny heart.)
>
> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> sorry, I meant:
>>
>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking);
>>
>>
>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>>
>>> I think these are all nice to have features, but I also think we have
 all the primitives we need to make it happen via pre-processing.

>
>>> I meant even synchronously, with a pre-processor that replace the
>>> imported module with
>>>
>>> 'data:text/javascript,' + JSON.stringify(moduleContentAfterTreeShaking);
>>>
>>
>> ___
> 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: Re: Inline ES Modules

[Mike Samuel]

On Tue, Jun 19, 2018 at 3:48 PM Jamie  wrote:

> I think having an inline module format would help make the composition of
> build tools much easier.
>
> Right now we have an ecosystem where everyone builds libraries into
> bundles using tools like Parcel, Rollup, Browserify, and Webpack. These
> create output which get recursively pulled into similar bundles.
>
> The problem is that the operation of merging files into bundles destroys
> static information we have with individual files. So optimizing compilers
> have difficulty doing code elimination (often called "tree shaking" in the
> community) across bundles.
>
> If we had a definition format for these bundlers to compile to which
> didn't destroy all the static information we have in separate files, we
> could build better optimizing compilers around them.
>
> I would hope that such a format would also allow engines to optimize the
> parsing of these inline modules (deferring most of the work until modules
> are actually loaded).
>
> There is other efforts in a similar space such was the webpackage format:
> https://github.com/WICG/webpackage/blob/master/explainer.md
>

What benefits might an inline module proposal have over/in-conjunction-with
the webpackage format proposal?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline ES Modules

[Mike Samuel]

How would an inline module be imported?  Module descriptors are roughly
relative URLs so can refer to a JavaScript source file, but it sounds like
you'd need something more fine-grained to refer to an inline module.  Using
fragments to refer to a passage within a document instead of a location
might have unintended effects.

Also, assuming that problem is solved, does the below mean anything
if (Math.random() < 0.5) {
  module School {
export function getPersonType() {}
  }
}

If not, if inline modules are defined eagerly, what advantages, besides
making life easier for transpiler writers, would inline modules have over
exporting frozen namespaces?



On Sun, Jun 17, 2018 at 10:34 AM Sultan  wrote:

> Are there any open proposals/discussions related to creating ES modules
> inline? For example:
>
> ```
> import getPersonType from School
>
> module School {
>   export function getPersonType (person) {
>   switch (person) {
>   case 'Teacher': return 'A teacher'
>   case 'Director': return 'A director'
>   }
>   }
> }
> ```
> ___
> 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: Symbol history

[Mike Samuel]

https://esdiscuss.org/topic/private-slots
"""
Allen Wirfs-Brock (5 years ago)

As further evidence, the word "private" does not even occur in sections
8.1.6 and 8.1.6.1 of the current ES6 draft. These are the sections that
define the ES6 object model. Small changes and additions had to be made to
allow for property keys to be either strings or symbols but those changes
are independent of whether a symbol is private or not. The only place that
the privateness of a symbol comes into play (besides in proxies) is in the
context of a few reflection operations whose behavior is predicated upon
whether a symbol property key is a private symbol or not. This is very
similar to the tests that the same or similar operations make on individual
property attributes.
"""
I don't know when Object.getOwnPropertySymbols made symbols useless for
private-like symbols, bit IIUC, 5 years ago they were kind of being
advanced for both to allow properties visible only to a symbol holder and
for cooperative namespace separation.



On Mon, May 28, 2018 at 3:48 PM, Mark Miller  wrote:

> There was at some point an attempt at elaborating "symbol" into some kind
> of "private name" or "private symbol", which failed for well explained
> reasons. However, this is not where symbols started. Symbols started as a
> way to introduce new properties while avoiding conflict with possible
> property names, IOW, as a way to introduce new property "names" that were
> guaranteed not to collide with any existing names. This is still their
> primary purpose.
>
>
> On Mon, May 28, 2018 at 11:09 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> Hi all,
>>
>> I've tried to glean this from the meeting notes and such, but many who
>> were actively involved are on the list, so:
>>
>> Am I right that Symbols started out as "private Name objects" then over
>> time their name was changed, they became primitives, and the privacy aspect
>> was dropped; but having guaranteed-unique values was still useful, and
>> found application (amongst other places) in solving the problem of adding a
>> default iterator to `Array.prototype` without name conflicts with existing
>> code in the wild?
>>
>> Thanks,
>>
>> -- T.J. Crowder
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web Security Puzzles with a TC39 agenda

[Mike Samuel]

Sorry I wasn't clear.  Follow link [1] for the rest.

On Mon, Apr 30, 2018, 6:19 PM Mark Miller <erig...@gmail.com> wrote:

> Hi Mike, your message end with "In case you’re interested in how the
> puzzles tie into the larger point I’m trying to make:" followed by three
> unexpandable dots. Copy/paste error?
>
> (Needless to say, I am interested ;).)
>
>
> On Mon, Apr 30, 2018 at 8:02 AM, Mike Samuel <mikesam...@gmail.com> wrote:
>
>> I put together a short video series of web security puzzles [1] to
>> motivate what I'm presenting at the May meeting [2].
>>
>> cheers,
>> mike
>>
>> [1] https://medium.com/@mikesamuel/puzzling-towards-security-a12b9427124
>> [2] https://github.com/tc39/agendas/blob/master/2018/05.md
>>
>> 
>>
>> Puzzling Towards Security
>>
>> If you like computer security puzzles and JavaScript, you’ll like this
>> short video series.
>>
>> It builds on work I and others in Google’s Security Engineering group
>> have done to identify and counter the kinds of common mistakes that lead to
>> vulnerabilities.
>>
>> After the puzzles I draw on experiences managing security within a large
>> engineering organization that builds static systems and propose language
>> tweaks that would enable similar outcomes for dynamic systems.
>>
>> In case you’re interested in how the puzzles tie into the larger point
>> I’m trying to make:
>>
>> ...
>>
>> ___
>> 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

Web Security Puzzles with a TC39 agenda

[Mike Samuel]

I put together a short video series of web security puzzles [1] to motivate
what I'm presenting at the May meeting [2].

cheers,
mike

[1] https://medium.com/@mikesamuel/puzzling-towards-security-a12b9427124
[2] https://github.com/tc39/agendas/blob/master/2018/05.md



Puzzling Towards Security

If you like computer security puzzles and JavaScript, you’ll like this
short video series.

It builds on work I and others in Google’s Security Engineering group have
done to identify and counter the kinds of common mistakes that lead to
vulnerabilities.

After the puzzles I draw on experiences managing security within a large
engineering organization that builds static systems and propose language
tweaks that would enable similar outcomes for dynamic systems.

In case you’re interested in how the puzzles tie into the larger point I’m
trying to make:

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

Re: Accessing (n)th key from an object

[Mike Samuel]

On Tue, Apr 24, 2018 at 9:54 AM, somonek  wrote:

> Hi all,
>
> Assuming that
>
> const myObject = {
>   one: 123,
>   two: 456,
> };
>
> could
> myObject[in 0] === 'one' // true
>
> be a better alternative of
> Object.keys(myObject)[0]
>
> and
> myObject[in 3] === undefined
>
> without the need to convert all the object keys into an array, but
> directly accessing one.
>

Why is this something that warrants extra syntax and not an optimization
better left to sufficiently smart engines?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Share a secret across ES6 specific modules, so that other modules cannot access the secret?

[Mike Samuel]

The box function defined in github.com/mikesamuel/tc39-module-keys enables
things like this.


On Sun, Apr 23, 2017 at 4:42 PM, /#!/JoePea  wrote:

> Is there a way to share some secret value across a few modules, and
> prevent other modules? f.e. prevent modules of an app dev who is importing
> modules of a library where the library wants to share private stuff across
> its modules. Is this possible to implement somehow?
>
> WeakMaps can be encapsulated inside a module to implement "private"
> properties for a class defined inside that module and then exported. But
> "protected" can't be implemented with a WeakMap shared with modules because
> then end-user app code can import the WeakMap and read all the stuff. Is
> there some way to share a WeakMap private with classes defined across
> modules?
>
> */#!/*JoePea
>
> ___
> 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: EcmaScript Proposal - Promised functions

[Mike Samuel]

This seems like it could be done with decorators per
https://github.com/tc39/proposal-decorators without introducing a new
keyword.

@promises function sleep(...) {
  ...
}



On Thu, Apr 12, 2018 at 12:07 PM, Luiz Felipe Frazão Gonçalves <
luizfelipefrazaogoncal...@gmail.com> wrote:

> *One new proposal for EcmaScript.*
> Promised Functions
>
> Like async/await, the promised functions would be preceded by a keyword.
> In the case, promised, it would change the default behavior of the
> function, making it behave as a promise.
>
> I will use as an example a classic sleep function:
>
> function sleep(forHowLong) {
>   return new Promise((resolve, reject) => {
> setTimeout(function() {
>   resolve();
>
>   /**   * For reject:   ** reject(Error('Some error'));   
> */
> }, forHowLong);
>   });
> }
>
> I think to avoid the huge amount of callbacks, there should be a syntax
> similar to this:
>
> promised function sleep(forHowLong) {
>   setTimeout(function() {
> this.resolve(); // could even create a keyword like "resolve"
>
> /** * For reject: *  * this.reject(Error('Some error')); 
> */
>   }, forHowLong);
> }
>
> Note that the hypothetical keyword "promised" before the function
> statement makes it act as a promise.
>
> Just a crazy idea I had. :)
>
> ___
> 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: partial spread syntax

[Mike Samuel]

On Sun, Mar 25, 2018 at 9:20 PM, 月の影 <19511...@qq.com> wrote:

> Sometimes I got a infinity iterable sequences, I may want a partial spreed
> syntax. `...iterableObject{from, to}`
>

How would you prevent ambiguity between the spread and blocks?

iterable
{
  from, to
};

is currently equivalent to

iterable;
{
  from, to;
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

>
> I do have one other related thing I'd like to see: add a `let foo =
> expr() else { ... }` variant, with a line terminator restriction
> before the `else` so it can't be confused with an `else` within an
> `if`.
>

Making it a restricted production would solve the grammatical ambiguity
for existing code, but maybe in an errorprone way for future code:

if (c) let foo = expr() else { ... } // else attaches to let
if (c) let foo = expr(); else { ... } // else attaches to if


Would the semantics differ from

   let foo = expr() || ({} => { ... })()

?





>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Thu, Mar 22, 2018 at 3:21 AM, Rodrigo <rodrigol...@gmail.com> wrote:
> > Not just let-scopes, but the introduction of `async/await` also
> > welcomes the introduction of if-scoped variables.
> >
> > if (const data = await collection.find({}).toArray(); data.length >
> 10)
> > {
> > console.log(data);
> > } else if (data.length > 0) {
> > console.log(data);
> > } else {
> > console.log(data);
> > }
> >
> > And, as mentioned by @jerry, this can be extended to `switch` and
> > `while`. Golang has `switch(;)` initialization too afaik.
> >
> > switch( const today = new Date(); today.getDay() ) {
> >  case 0:
> > console.log( "Don't work on %s", today.toString() );
> > break;
> > }
> >
> > `while` would be a bit unnecessary, due to the fact that it can be
> > replicated with `for( ; ; )`, but could be
> > available for consistency with `if` and `switch`.
> >
> > El mié., 21 mar. 2018 19:47, Mike Samuel <mikesam...@gmail.com>
> escribió:
> >>
> >>
> >>
> >> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton <
> sebast...@malton.name>
> >> wrote:
> >>>
> >>> Because block-level scoping is a very good way to avoid certain bugs
> and
> >>> is easier to reason about. Especially when considering project
> successors.
> >>
> >>
> >> +1.  function-scoped variables in loop bodies caused tons of bugs before
> >> let-scoped variables and were a main motivating case.
> >>
> >> var i;
> >> for (i = 0; i < arr.length; ++i) {
> >>   f(function () { /* Do something with */ arr[i]; });
> >> }
> >>
> >> vs
> >>
> >> for (let i = 0; i < arr.length; ++i) {
> >>   f(function () { /* Do something with */ arr[i]; });
> >> }
> >>
> >> Yes, linters got pretty good at finding uses of closed-over variables
> >> modified in a loop, but the workarounds were not ideal.
> >>
> >> var i;
> >> for (i = 0; i < arr.length; ++i) {
> >>   f(function (i) { return function () { /* Do something with */ arr[i];
> }
> >> }(i));
> >> }
> >>
> >> Block scoping is just better for code that uses loops, variables, and
> >> function expressions.
> >>
> >> ___
> >> 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
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

TIL

On Wed, Mar 21, 2018 at 2:29 PM, kai zhu  wrote:

> /*jslint
>
stupid: true
>
*/
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
wrote:

> Because block-level scoping is a very good way to avoid certain bugs and
> is easier to reason about. Especially when considering project successors.
>

+1.  function-scoped variables in loop bodies caused tons of bugs before
let-scoped variables and were a main motivating case.

var i;
for (i = 0; i < arr.length; ++i) {
  f(function () { /* Do something with */ arr[i]; });
}

vs

for (let i = 0; i < arr.length; ++i) {
  f(function () { /* Do something with */ arr[i]; });
}

Yes, linters got pretty good at finding uses of closed-over variables
modified in a loop, but the workarounds were not ideal.

var i;
for (i = 0; i < arr.length; ++i) {
  f(function (i) { return function () { /* Do something with */ arr[i]; }
}(i));
}

Block scoping is just better for code that uses loops, variables, and
function expressions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo  wrote:

> My proposal is to keep it simple and implement the if-assignment `if(
> const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment
> behavior.
>

Fair enough.  If the assignment is separate from the condition, then none
of that matters.
That question only pertained to let/const declarations used for their value.

That way we can scope a variable to the `if` block and we can do that
> *separately* from assignment.
>
> Assigning and comparing at the same time opens up all sort of oddities
> as the variable transitions from lvalue to comparison operand. This
> already exists in the language and is definitely not good practice.
>
> `if.value`, as proposed earlier is a bombshell similar to `this`,
> which could easily get scrambled with the introduction of additional
> `if` blocks.
>
> The beauty of `if(;)` is that it makes scope blocks possible while
> avoiding the asymmetric behavior caused by assigning and comparing in
> one go.
>
> if( let people=getTeamArray(); people.length > 2 ) {
>console.log("it's a crowd", people.join(','));
>}
>else if( people.length == 2 ) {
>console.log("just a pair");
>}
>else if( people.length == 1 {
>console.log("solo");
>}
>else {
>console.log("none");
>}
>

IIUC, it sounds like the right side could be syntactic sugar for the left
side.
If that's right, what about the left side warrants new syntax to enable the
right?


CurrentProposed

  {
   *let people = getTeamArray();*
   if( people.length > 2 ) {
   console.log("it's a crowd", people.join(','));
   }
   else if( people.length == 2 ) {
   console.log("just a pair");
   }
   else if( people.length == 1 {
   console.log("solo");
   }
   else {
   console.log("none");
   }
  }

   if( *let people = getTeamArray();* people.length > 2 ) {
   console.log("it's a crowd", people.join(','));
   }
   else if( people.length == 2 ) {
   console.log("just a pair");
   }
   else if( people.length == 1 {
   console.log("solo");
   }
   else {
   console.log("none");
   }


I can imagine that it might be nice when used later in an else-if chain:

if (c0) {
  ...
} else (let x = v1, c1(x)) {
  ...
} else ...

vs

if (c0) {
  ...
} else {
  let x = v1;
  if (c1(x)) {
...
  } else ...
}

Can you point at any particularly tricky code that could be simplified by
this?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo  wrote:

> Proposal: inline let/const statements to declare and initialize
> variables within if statements, so that temporary variables exist only
> within the if/else block scope.
>

With setters you can get some oddities because the getter need not return
the same value set.

const o = { get x() { return this.x_ }, set x(v) { return this.x_ =
String(v) } }
if (!(o.x = 0)) {
  console.log('o.x is falsey: ' + !o.x);
}

If decorators  are
allowed on let/const declarations, then you might get a similar source of
confusion.

This might be especially confusing since in Java and C++ the result of an
assignment is
the value actually assigned after any type coercion (or a reference to the
left).

In JavaScript, the result of an assignment is the result of the right
operand.
Though its a bit muddy, since the result of x++ is x coerced to a number
for symmetry with x += 1.

If it turns out that decorators are widely used for type annotations on
declarations and
some do custom coercion on assignment, does that introduce potential
problems?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pointers

[Mike Samuel]

There is a spec reference type.  It was initially there for host objects,
and IIRC, most were happy to see it go.



http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf

8.7 The Reference Type
The internal Reference type is not a language data type.

It is defined by this specification purely for expository purposes. An
implementation of ECMAScript must behave as if it produced and operated
upon references in the manner described here. However, a value of type
Reference is used only as an intermediate result of expression evaluation
and cannot be stored as the value of a variable or property.

The Reference type is used to explain the behaviour of such operators as
delete, typeof, and the assignment operators. For example, the left-hand
operand of an assignment is expected to produce a reference. The behaviour
of assignment could, instead, be explained entirely in terms of a case
analysis on the syntactic form of the left-hand operand of an assignment
operator, *but for one difficulty: function calls are permitted to return
references.* *This possibility is admitted purely for the sake of host
objects.* No builtin ECMAScript function defined by this specification
returns a reference and there is no provision for a user-defined function
to return a reference. (Another reason not to use a syntactic case analysis
is that it would be lengthy and awkward, affecting many parts of the
specification.)

Another use of the Reference type is to explain the determination of the
this value for a function call. A Reference is a reference to a property of
an object.

A Reference consists of two components, the base object and the property
name.

The following abstract operations are used in this specification to access
the components of references:
• GetBase(V). Returns the base object component of the reference V.
• GetPropertyName(V). Returns the property name component of the reference
V.

The following abstract operations are used in this specification to operate
on references:



http://www.ecma-international.org/ecma-262/#sec-reference-specification-type
is the much reduced equivalent in the current draft.
6.2.4The Reference Specification Type


Trying to expose the reference specification type as an actual user
manipulable type would have a lot of consequences, and would not
actually address the local variable use case.


If your use case can be satisfied by objects like some syntactic sugar like
{ get content() { return x }, set content(v) { return x = v } }
then you might find it easier asking for that instead of a new type.




On Mon, Mar 19, 2018 at 3:47 PM, Sebastian Malton 
wrote:

> Proposal:
> Add a new variable-esk type called pointer which acts sort of like a
> reference to the data which it has been assigned to but modifies also the
> original reference when modified.
>
> Justification:
> When working with objects in particular it is often useful for satiny
> reasons to use local variables (mostly const's) as a shorthand reference
> both for compactness and also so that you don't have to type out the entire
> path every type. This would allow for non - objects but also overwriting
> objects if wanted but still have this freedom and convenience.
>
> Method:
> Add a new notation
>
> ```
> let:prt name = obj.field.name.fullname;
> ```
>
> Here if `name` is updated or if `obj.field.name.fullname` is updated so is
> the other.
>
> Sebastian Malton
>
> ___
> 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: JSON.canonicalize()

[Mike Samuel]

On Mon, Mar 19, 2018 at 10:30 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-19 15:17, Mike Samuel wrote:
>
>>
>>
>> On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren <
>> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
>> wrote:
>>
>> On 2018-03-19 14:34, Mike Samuel wrote:
>>
>> How does the transform you propose differ from?
>>
>> JSON.canonicalize = (x) => JSON.stringify(
>>   x,
>>   (_, x) => {
>> if (x && typeof x === 'object' && !Array.isArray(x)) {
>>   const sorted = {}
>>   for (let key of Object.getOwnPropertyNames(x).sort()) {
>> sorted[key] = x[key]
>>   }
>>   return sorted
>> }
>> return x
>>   })
>>
>>
>> Probably not all.  You are the JS guru, not me :-)
>>
>>
>> The proposal says "in lexical (alphabetical) order."
>> If "lexical order" differs from the lexicographic order that sort
>> uses, then
>> the above could be adjusted to pass a comparator function.
>>
>>
>> I hope (and believe) that this is just a terminology problem.
>>
>>
>> I think you're right. http://www.ecma-international.
>> org/ecma-262/6.0/#sec-sortcompare
>> is where it's specified.  After checking that no custom comparator is
>> present:
>>
>>  1. Let/xString/beToString <http://www.ecma-international
>> .org/ecma-262/6.0/#sec-tostring>(/x/).
>>  2. ReturnIfAbrupt <http://www.ecma-international.org/ecma-262/6.0/#sec-
>> returnifabrupt>(/xString/).
>>  3. Let/yString/beToString <http://www.ecma-international
>> .org/ecma-262/6.0/#sec-tostring>(/y/).
>>  4. ReturnIfAbrupt <http://www.ecma-international.org/ecma-262/6.0/#sec-
>> returnifabrupt>(/yString/).
>>  5. If/xString/>  6. If/xString/>/yString/, return 1.
>>  7. Return +0.
>>
>>
>> (<) and (>) do not themselves bring in any locale-specific collation
>> rules.
>> They bottom out on http://www.ecma-international.
>> org/ecma-262/6.0/#sec-abstract-relational-comparison
>>
>> If both/px/and/py/are Strings, then
>>
>>  1. If/py/is a prefix of/px/, return*false*. (A String value/p/is a
>> prefix of String value/q/if/q/can be the result of concatenating/p/and some
>> other String/r/. Note that any String is a prefix of itself, because/r/may
>> be the empty String.)
>>  2. If/px/is a prefix of/py/, return*true*.
>>  3. Let/k/be the smallest nonnegative integer such that the code unit at
>> index/k/within/px/is different from the code unit at index/k/within/py/.
>> (There must be such a/k/, for neither String is a prefix of the other.)
>>  4. Let/m/be the integer that is the code unit value at
>> index/k/within/px/.
>>  5. Let/n/be the integer that is the code unit value at
>> index/k/within/py/.
>>  6. If/m/>
>> Those code unit values are UTF-16 code unit values per
>> http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascri
>> pt-language-types-string-type
>>
>> each element in the String is treated as a UTF-16 code unit value
>>
>> As someone mentioned earlier in this thread, lexicographic string
>> comparisons that use different code
>> unit sizes can compute different results for the same semantic string
>> value.  Between UTF-8 and UTF-32
>> you should see no difference, but UTF-16 can differ from those given
>> supplementary codepoints.
>>
>> It might be worth making explicit that your lexical order is over UTF-16
>> strings if that's what you intend.
>>
>
> Right, it is actually already in 3.2.3:
>

My apologies.  I missed that.

  Property strings to be sorted depend on that strings are represented
>   as arrays of 16-bit unsigned integers where each integer holds a single
>   UCS2/UTF-16 [UNICODE] code unit. The sorting is based on pure value
>   comparisons, independent of locale settings.
>
> This maps "natively" to JS and Java.  Probably to .NET as well.
> Other systems may need a specific comparator.
>

Yep.  Off the top of my head:
Go and Rust use UTF-8.
Python3 is UTF-16, Python2 is usually UTF-16 but may be UTF-32 depending on
sizeof(wchar) when compiling the interpreter.
C++ as is its wont is all of them.



>
>> Applied to your example input,
>>
>> JSON.canonicalize({

Re: Arbitrary precision numbers in JSON

[Mike Samuel]

On Mon, Mar 19, 2018 at 10:09 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-19 14:43, Mike Samuel wrote:
>
>> Maybe have a parser function that receive the text of the number?  If no
>> callout is specified, it could throw an appropriate error.
>>
>>  JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable)
>>
>> That would allow it to tie into future proposals like decimal, and in
>> conjunction with a reviver could treat an array of numbers known to be
>> large as an Int64Array view over an ArrayBuffer.
>>
>
> I may be off here, but don't you also need something like rawToJSON for
> JSON.stringify()?
> That is, rawToJSON would return a string which is used "as is".
>

Quite right, you would need some adjustment to stringify too.

We could change the contract of toJSON so that if it returns a value with a
certain runtime type, then JSON.stringify asserts that it is a
syntactically valid ES404 value and then uses it inline.  For example,
({[Symbol('rawJSON')]: "1" + "0".repeat(1000) }).
That would round-trip and compose reasonably well and wouldn't add another
special method that needs to be tested for at stringify time.



> Anders
>
>
>>
>> On Sun, Mar 18, 2018 at 9:33 PM, Michał Wadas <michalwa...@gmail.com
>> <mailto:michalwa...@gmail.com>> wrote:
>>
>> Fact: JSON allows arbitrary precision numbers.
>> Problem: JavaScript is unable to express these numbers.
>>
>> Proposed solution: introduce JSON.safeParse. This method will work as
>> JSON.parse, but throwing on values that can't be accurately represented by
>> IEEE 754 64-bit float.
>>
>> Alternative: allow user to specify number class - eg. by adding
>> options object with optional method "parseNumber", overwriting default
>> behaviour of using builtin number type.
>>
>> Any thoughts on this?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <
>> https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>>
>> ___
>> 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: JSON.canonicalize()

[Mike Samuel]

On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-19 14:34, Mike Samuel wrote:
>
>> How does the transform you propose differ from?
>>
>> JSON.canonicalize = (x) => JSON.stringify(
>>  x,
>>  (_, x) => {
>>if (x && typeof x === 'object' && !Array.isArray(x)) {
>>  const sorted = {}
>>  for (let key of Object.getOwnPropertyNames(x).sort()) {
>>sorted[key] = x[key]
>>  }
>>  return sorted
>>}
>>return x
>>  })
>>
>
> Probably not all.  You are the JS guru, not me :-)
>
>
>> The proposal says "in lexical (alphabetical) order."
>> If "lexical order" differs from the lexicographic order that sort uses,
>> then
>> the above could be adjusted to pass a comparator function.
>>
>
> I hope (and believe) that this is just a terminology problem.
>

I think you're right.
http://www.ecma-international.org/ecma-262/6.0/#sec-sortcompare
is where it's specified.  After checking that no custom comparator is
present:

   1. Let *xString* be ToString
   <http://www.ecma-international.org/ecma-262/6.0/#sec-tostring>(*x*).
   2. ReturnIfAbrupt
   <http://www.ecma-international.org/ecma-262/6.0/#sec-returnifabrupt>(
   *xString*).
   3. Let *yString* be ToString
   <http://www.ecma-international.org/ecma-262/6.0/#sec-tostring>(*y*).
   4. ReturnIfAbrupt
   <http://www.ecma-international.org/ecma-262/6.0/#sec-returnifabrupt>(
   *yString*).
   5. If *xString* < *yString*, return −1.
   6. If *xString* > *yString*, return 1.
   7. Return +0.


(<) and (>) do not themselves bring in any locale-specific collation rules.
They bottom out on
http://www.ecma-international.org/ecma-262/6.0/#sec-abstract-relational-comparison

If both *px* and *py* are Strings, then

   1. If *py* is a prefix of *px*, return *false*. (A String value *p* is a
   prefix of String value *q* if *q* can be the result of concatenating *p* and
   some other String *r*. Note that any String is a prefix of itself,
   because *r* may be the empty String.)
   2. If *px* is a prefix of *py*, return *true*.
   3. Let *k* be the smallest nonnegative integer such that the code unit
   at index *k* within *px* is different from the code unit at index *k*
   within *py*. (There must be such a *k*, for neither String is a prefix
   of the other.)
   4. Let *m* be the integer that is the code unit value at index *k* within
*px*.
   5. Let *n* be the integer that is the code unit value at index *k* within
*py*.
   6. If *m* < *n*, return *true*. Otherwise, return *false*.

Those code unit values are UTF-16 code unit values per
http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-language-types-string-type

each element in the String is treated as a UTF-16 code unit value

As someone mentioned earlier in this thread, lexicographic string
comparisons that use different code
unit sizes can compute different results for the same semantic string
value.  Between UTF-8 and UTF-32
you should see no difference, but UTF-16 can differ from those given
supplementary codepoints.

It might be worth making explicit that your lexical order is over UTF-16
strings if that's what you intend.



> Applied to your example input,
>>
>> JSON.canonicalize({
>>  "escaping": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
>>  "other":  [null, true, false],
>>  "numbers": [1E30, 4.50, 6, 2e-3, 0.001]
>>}) ===
>>String.raw`{"escaping":"€$\u000f\nA'B\"\"/","numbers":[
>> 1e+30,4.5,6,0.002,1e-27],"other":[null,true,false]}`
>> // proposed {"escaping":"\u20ac$\u000f\nA'B\"\"/","numbers":[1e+30,4
>> .5,6,0.002,1e-27],"other":[null,true,false]}
>>
>>
>> The canonicalized example from section 3.2.3 seems to conflict with the
>> text of 3.2.2:
>>
>
> If you look a under the result you will find a pretty sad explanation:
>
> "Note: \u20ac denotes the Euro character, which not
>  being ASCII, is currently not displayable in RFCs"
>

Cool.


> After 30 years with RFCs, we can still only use ASCII :-( :-(
>
> Updates:
> https://github.com/cyberphone/json-canonicalization/blob/mas
> ter/JSON.canonicalize.md
> https://cyberphone.github.io/doc/security/browser-json-canon
> icalization.html
>

If this can be implemented in a small amount of library code, what do you
need from TC39?



> Anders
>
>
>> """
>> If the Unicode value is outsi

Re: Arbitrary precision numbers in JSON

[Mike Samuel]

Maybe have a parser function that receive the text of the number?  If no
callout is specified, it could throw an appropriate error.

JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable)

That would allow it to tie into future proposals like decimal, and in
conjunction with a reviver could treat an array of numbers known to be
large as an Int64Array view over an ArrayBuffer.


On Sun, Mar 18, 2018 at 9:33 PM, Michał Wadas  wrote:

> Fact: JSON allows arbitrary precision numbers.
> Problem: JavaScript is unable to express these numbers.
>
> Proposed solution: introduce JSON.safeParse. This method will work as
> JSON.parse, but throwing on values that can't be accurately represented by
> IEEE 754 64-bit float.
>
> Alternative: allow user to specify number class - eg. by adding options
> object with optional method "parseNumber", overwriting default behaviour of
> using builtin number type.
>
> Any thoughts on this?
>
> ___
> 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: JSON.canonicalize()

[Mike Samuel]

How does the transform you propose differ from?

JSON.canonicalize = (x) => JSON.stringify(
x,
(_, x) => {
  if (x && typeof x === 'object' && !Array.isArray(x)) {
const sorted = {}
for (let key of Object.getOwnPropertyNames(x).sort()) {
  sorted[key] = x[key]
}
return sorted
  }
  return x
})


The proposal says "in lexical (alphabetical) order."
If "lexical order" differs from the lexicographic order that sort uses, then
the above could be adjusted to pass a comparator function.

Applied to your example input,

JSON.canonicalize({
"escaping": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
"other":  [null, true, false],
"numbers": [1E30, 4.50, 6, 2e-3, 0.001]
  }) ===

String.raw`{"escaping":"€$\u000f\nA'B\"\"/","numbers":[1e+30,4.5,6,0.002,1e-27],"other":[null,true,false]}`
// proposed
{"escaping":"\u20ac$\u000f\nA'B\"\"/","numbers":[1e+30,4.5,6,0.002,1e-27],"other":[null,true,false]}


The canonicalized example from section 3.2.3 seems to conflict with the
text of 3.2.2:

"""
If the Unicode value is outside of the ASCII control character range, it
MUST be serialized "as is" unless it is equivalent to 0x005c (\) or
0x0022 (") which MUST be serialized as \\ and \" respectively.
"""

So I think the "\u20ac" should actually be "€" and the implementation above
matches your proposal.


On Fri, Mar 16, 2018 at 3:16 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> Dear List,
>
> Here is a proposal that I would be very happy getting feedback on since it
> builds on ES but is not (at all) limited to ES.
>
> The request is for a complement to the ES "JSON" object called
> canonicalize() which would have identical parameters to the existing
> stringify() method.
>
> The JSON canonicalization scheme (including ES code for emulating it), is
> described in:
> https://cyberphone.github.io/doc/security/draft-rundgren-jso
> n-canonicalization-scheme.html
>
> Current workspace: https://github.com/cyberphone/json-canonicalization
>
> Thanx,
> Anders Rundgren
> ___
> 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: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018, 4:50 PM Anders Rundgren <anders.rundgren@gmail.com>
wrote:

> On 2018-03-18 20:15, Mike Samuel wrote:
> > I and others have been trying to move towards consensus on what a
> hashable form of
> > JSON should look like.
> >
> > We've identified key areas including
> > * property ordering,
> > * number canonicalization,
> > * string normalization,
> > * whether the input should be a JS value or a string of JSON,
> > * and others
> >
> > but, as in this case, you seem to be arguing both sides of a position to
> support your
> > proposal when you could just say "yes, the proposal could be adjusted
> along this
> > dimension and still provide what's required."
>
> For good or for worse, my proposal is indeed about leveraging ES6's take
> on JSON including limitations, {bugs}, and all.
> I'm not backing from that position because then things get way more
> complex and probably never even happen.
>
> Extending [*] the range of "Number" is pretty much (in practical terms)
> the same thing as changing JSON itself.
>

Your proposal is limiting Number; my alternative is not extending Number.

"Number" is indeed mindless crap but it is what is.
>
> OTOH, the "Number" problem was effectively solved some 10 years ago
> through putting stuff in "strings".
> Using JSON Schema or "Old School" strongly typed programmatic solutions of
> the kind I use, this actually works great.
>
> Anders
>
> *] The RFC gives you the right to do that but existing implementations do
> not.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary of Input. Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018, 4:00 PM Anders Rundgren <anders.rundgren@gmail.com>
wrote:

> On 2018-03-18 20:23, Mike Samuel wrote:
> > It is possible that I don't understand what you are asking for here
> since I have no experience with toJSON.
> >
> > Based on this documentation
> >
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
> <
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
> >
> > JSON.canonicalize() would though work out of the box (when
> integrated in the JSON object NB...) since it would inherit all the
> functionality (and 99% of the code) of JSON.stringify()
> >
> >
> > JSON.stringify(new Date()) has specific semantics because
> Date.prototype.toJSON has specific semantics.
> > As currently written, JSON.canonicalize(new Date()) ===
> JSON.canonicalize({})
>
> It seems that you (deliberately?) misunderstand what I'm writing above.
>
> JSON.canonicalize(new Date()) would do exactly the same thing as
> JSON.stringify(new Date()) since it apparently only returns a string.
>

Where in the spec do you handle this case?

Again, the sample code I provided is a bare bones solution with the only
> purpose showing the proposed canonicalization algorithm in code as a
> complement to the written specification.
>

Understood.  AFAICT neither the text nor the instructional code treat Dates
differently from an empty object.


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

Re: Summary of Input. Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 12:50 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-18 15:13, Mike Samuel wrote:
>
>>
>>
>> On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren <
>> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
>> wrote:
>>
>> Hi Guys,
>>
>> Pardon me if you think I was hyperbolic,
>> The discussion got derailed by the bogus claims about hash functions'
>> vulnerability.
>>
>>
>> I didn't say I "think" you were being hyperbolic.  I asked whether you
>> were.
>>
>> You asserted a number that seemed high to me.
>> I demonstrated it was high by a factor of at least 25 by showing an
>> implementation that
>> used 80 lines instead of the 2000 you said was required.
>>
>> If you're going to put out a number as a reason to dismiss an argument,
>> you should own it
>> or retract it.
>> Were you being hyperbolic?  (Y/N)
>>
> N.
> To be completely honest I have only considered fullblown serializers and
> they typically come in the mentioned size.
>
> Your solution have existed a couple days; we may need a little bit more
> time thinking about it :-)
>

Fair enough.


>
> Your claim and my counterclaim are in no way linked to hash function
>> vulnerability.
>> I never weighed in on that claim and have already granted that hashable
>> JSON is a
>> worthwhile use case.
>>
>
> Great!  So we can finally put that argument to rest.
>

No.  I don't disagree with you, but I don't speak for whoever did.



>
>
>> F.Y.I: Using ES6 serialization methods for JSON primitive types is
>> headed for standardization in the IETF.
>> https://www.ietf.org/mail-archive/web/jose/current/msg05716.html <
>> https://www.ietf.org/mail-archive/web/jose/current/msg05716.html>
>>
>> This effort is backed by one of the main authors behind the current
>> de-facto standard for Signed and Encrypted JSON, aka JOSE.
>> If this is in your opinion is a bad idea, now is the right time to
>> shoot it down :-)
>>
>>
>> Does this main author prefer your particular JSON canonicalization scheme
>> to
>> others?
>>
>
> This proposal does [currently] not rely on canonicalization but on ES6
> "predictive parsing and serialization".
>
>
> Is this an informed opinion based on flaws in the others that make them
>> less suitable for
>> JOSE's needs that are not present in the scheme you back?
>>
>
> A JSON canonicalization scheme has AFAIK never been considered in the
> relevant IETF groups (JOSE+JSON).
> On the contrary, it has been dismissed as a daft idea.
>
> I haven't yet submitted my [private] I-D. I'm basically here for
> collecting input and finding possible collaborators.
>
>
>> If so, please provide links to their reasoning.
>> If not, how is their backing relevant?
>>
>
> If ES6/JSON.stringify() way of serializing JSON primitives becomes an IETF
> standard with backed by Microsoft, it may have an impact on the "market".
>

If you can't tell us anything concrete about your backers, what they back,
or why they back it, then why bring it up?



>
>> This efforts also exploits the ability of JSON.parse() and
>> JSON.stringify() honoring object "Creation Order".
>>
>> JSON.canonicalize() would be a "Sorting" alternative to "Creation
>> Order" offering certain advantages with limiting deployment impact to JSON
>> serializers as the most important one.
>>
>> The ["completely broken"] sample code was only submitted as a
>> proof-of-concept. I'm sure you JS gurus can do this way better than I :-)
>>
>>
>> This is a misquote.  No-one has said your sample code was completely
>> broken.
>> Neither your sample code nor the spec deals with toJSON.  At some point
>> you're
>> going to have to address that if you want to keep your proposal moving
>> forward.
>>
>
> It is possible that I don't understand what you are asking for here since
> I have no experience with toJSON.
>
> Based on this documentation
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
> rence/Global_Objects/JSON/stringify
> JSON.canonicalize() would though work out of the box (when integrated in
> the JSON object NB...) since it would inherit all the functionality (and
> 99% of the code) of JSON.stringify()


JSON.stringify(new Date()) has specific semantics because
Date.prototype.toJSON has specific semantics.
As currently written, JSON.canonicalize(

Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 2:18 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-18 19:04, Mike Samuel wrote:
>
>> I think you misunderstood the criticism.  JSON does not have numeric
>> precision limits.
>>
>
> I think I understood that, yes.
>
> There are plenty of systems that use JSON that never
>> involve JavaScript and which pack int64s.
>>
>
> Sure, but if these systems use the "Number" type they belong to a
> proprietary world where disregarding recommendations and best practices is
> OK.
>

No.  They are simply not following a SHOULD recommendation.
I think you have a variance mismatch in your argument.



> BTW, this an ECMAScript mailing list, why push non-JS complient ideas here?
>

Let's review.

You asserted "This discussion (at least from my point of view), is about
creating stuff that fits into standards."

I agreed and pointed out that not tying the definition to JavaScript's
current value limitations would allow it to fit into
standards that do not assume those limitations.

You leveled this criticism: "My guess is that it would be rejected due to
[quite valid] interoperability concerns."
Implicit in that is when one standard specifies that an input MUST have a
property that conflicts with
an output that a conforming implementation MAY or SHOULD produce then you
have an interoperability concern.


But, you are trying to argue that your proposal is more interoperable
because it works for fewer inputs in fewer contexts
and, if it were ported to other languages, would reject JSON that is
parseable without loss of precision in those languages.
How you can say with a straight face that being non-runtime-agnostic makes
a proposal more interoperable is beyond me.


Here's where variance comes in.
MUST on *output* makes a standard more interoperable.
MAY on *input* makes a standard more interoperable.

SHOULD and SHOULD NOT do not justify denying service.
They are guidelines that should be followed absent a compelling reason --
specific rules trumps the general.


Your proposal is less interoperable because you are quoting a SHOULD,
interpreting it as MUST and saying inputs MUST fit into an IEEE 754 double
without loss of precision.

This makes it strictly less interoperable than a proposal that does not
have that constraint.


EmcaScript SHOULD encourage interoperability since it is often a glue
language.

At the risk of getting meta-,
TC39 SHOULD prefer library functions that provide service for arbitrary
inputs in their range.
TC39 SHOULD prefer library functions that MUST NOT, by virtue of their
semantics,
lose precision silently.


Your proposal fails to be more interoperable inasmuch as it reproduces
JSON.stringify(JSON.parse('1e1000')) === 'null'


There is simply no need to convert a JSON string to JavaScript values in
order to hash it.
There is simply no need to specify this in terms of JavaScript values when
a runtime
agnostic implementation that takes a string and produces a string provides
the same value.


This is all getting very tedious though.
I and others have been trying to move towards consensus on what a hashable
form of
JSON should look like.

We've identified key areas including
* property ordering,
* number canonicalization,
* string normalization,
* whether the input should be a JS value or a string of JSON,
* and others

but, as in this case, you seem to be arguing both sides of a position to
support your
proposal when you could just say "yes, the proposal could be adjusted along
this
dimension and still provide what's required."


If you plan on putting a proposal before TC39 are you willing to move on
any of these.
or are you asking for a YES/NO vote on a proposal that is largely the same
as what
you've presented?


If the former, then acknowledge that there is a range of options and
collect feedback
instead of sticking to "the presently drafted one is good enough."
If the latter, then I vote NO because I think the proposal in its current
form is a poor
solution to the problem.

That's not to say that you've done bad work.
Most non-incremental stage 0 proposals are poor, and the process is
designed to
integrate the ideas of people in different specialties to turn poor
solutions to interesting
problems into robust solutions to a wider range of problems than originally
envisioned.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

I think you misunderstood the criticism.  JSON does not have numeric
precision limits.  There are plenty of systems that use JSON that never
involve JavaScript and which pack int64s.

On Sun, Mar 18, 2018, 1:55 PM Anders Rundgren <anders.rundgren@gmail.com>
wrote:

> On 2018-03-18 18:40, Mike Samuel wrote:
> > A definition of canonical that is not tied to JavaScript's current range
> of values would fit into more standards than the proposal as it stands.
> Feel free submitting an Internet-Draft which addresses a more generic
> Number handling.
> My guess is that it would be rejected due to [quite valid]
> interoperability concerns.
>
> It would probably fall in the same category as "Fixing JSON" which has not
> happened either.
> https://www.tbray.org/ongoing/When/201x/2016/08/20/Fixing-JSON
>
> Anders
>
> >
> > On Sun, Mar 18, 2018, 12:15 PM Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> > On 2018-03-18 16:47, Mike Samuel wrote:
> >  > Interop with systems that use 64b ints is not a .001% issue.
> >
> > Certainly not but using "Number" for dealing with such data would
> never be considered by for example the IETF.
> >
> > This discussion (at least from my point of view), is about creating
> stuff that fits into standards.
> >
> > Anders
> >
> >  >
> >  > On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>
> <mailto:anders.rundgren@gmail.com  anders.rundgren@gmail.com>>> wrote:
> >  >
> >  > On 2018-03-18 15:47, Michał Wadas wrote:
> >  >  > JSON supports arbitrary precision numbers that can't be
> properly
> >  >  > represented as 64 bit floats. This includes numbers like
> eg. 1e or 1/1e.
> >  >
> >  > rfc7159:
> >  >  Since software that implements
> >  >  IEEE 754-2008 binary64 (double precision) numbers
> [IEEE754] is
> >  >  generally available and widely used, good
> interoperability can be
> >  >  achieved by implementations that expect no more
> precision or range
> >  >  than these provide, in the sense that implementations
> will
> >  >  approximate JSON numbers within the expected precision
> >  >
> >  > If interoperability is not an issue you are free to do
> whatever you feel useful.
> >  > Targeting a 0.001% customer base with standards, I gladly
> leave to others to cater for.
> >  >
> >  > The de-facto standard featured in any number of applications,
> is putting unusual/binary/whatever stuff in text strings.
> >  >
> >  > Anders
> >  >
> >  >  >
> >  >  >
> >  >  > On Sun, 18 Mar 2018, 15:30 Anders Rundgren, <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>
> <mailto:anders.rundgren@gmail.com  anders.rundgren@gmail.com>> <mailto:anders.rundgren@gmail.com
> <mailto:anders.rundgren@gmail.com>  anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>>>
> wrote:
> >  >  >
> >  >  > On 2018-03-18 15:08, Richard Gibson wrote:
> >  >  >> On Sunday, March 18, 2018, Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>
> <mailto:anders.rundgren@gmail.com  anders.rundgren@gmail.com>> <mailto:anders.rundgren@gmail.com
> <mailto:anders.rundgren@gmail.com>  anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>>>
> wrote:
> >  >  >>
> >  >  >> On 2018-03-16 20:24, Richard Gibson wrote:
> >  >  >>> Though ECMAScript JSON.stringify may suffice for
> certain Javascript-centric use cases or otherwise restricted subsets
> thereof as addressed by JOSE, it is not suitable for producing
> canonical/hashable/etc. JSON, which requires a fully general solution such
> as [1]. Both its number serialization [2] and string serialization [3]
> specify aspects that harm compatibility (the former having arbitrary
> branches dependent upon the value of numbers, the latter being capable of
> producing invalid UTF-8 octet sequences that represent unpaired surrogate
> code points—unacceptable for exchange outsid

Re: JSON.canonicalize()

[Mike Samuel]

A definition of canonical that is not tied to JavaScript's current range of
values would fit into more standards than the proposal as it stands.

On Sun, Mar 18, 2018, 12:15 PM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-18 16:47, Mike Samuel wrote:
> > Interop with systems that use 64b ints is not a .001% issue.
>
> Certainly not but using "Number" for dealing with such data would never be
> considered by for example the IETF.
>
> This discussion (at least from my point of view), is about creating stuff
> that fits into standards.
>
> Anders
>
> >
> > On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> > On 2018-03-18 15:47, Michał Wadas wrote:
> >  > JSON supports arbitrary precision numbers that can't be properly
> >  > represented as 64 bit floats. This includes numbers like eg.
> 1e or 1/1e.
> >
> > rfc7159:
> >  Since software that implements
> >  IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
> >  generally available and widely used, good interoperability can
> be
> >  achieved by implementations that expect no more precision or
> range
> >  than these provide, in the sense that implementations will
> >  approximate JSON numbers within the expected precision
> >
> > If interoperability is not an issue you are free to do whatever you
> feel useful.
> > Targeting a 0.001% customer base with standards, I gladly leave to
> others to cater for.
> >
> > The de-facto standard featured in any number of applications, is
> putting unusual/binary/whatever stuff in text strings.
> >
> > Anders
> >
> >  >
> >  >
> >  > On Sun, 18 Mar 2018, 15:30 Anders Rundgren, <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>
> <mailto:anders.rundgren@gmail.com  anders.rundgren@gmail.com>>> wrote:
> >  >
> >  > On 2018-03-18 15:08, Richard Gibson wrote:
> >  >> On Sunday, March 18, 2018, Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>
> <mailto:anders.rundgren@gmail.com  anders.rundgren@gmail.com>>> wrote:
> >  >>
> >  >> On 2018-03-16 20:24, Richard Gibson wrote:
> >  >>> Though ECMAScript JSON.stringify may suffice for
> certain Javascript-centric use cases or otherwise restricted subsets
> thereof as addressed by JOSE, it is not suitable for producing
> canonical/hashable/etc. JSON, which requires a fully general solution such
> as [1]. Both its number serialization [2] and string serialization [3]
> specify aspects that harm compatibility (the former having arbitrary
> branches dependent upon the value of numbers, the latter being capable of
> producing invalid UTF-8 octet sequences that represent unpaired surrogate
> code points—unacceptable for exchange outside of a closed ecosystem [4]).
> JSON is a general /language-agnostic/interchange format, and ECMAScript
> JSON.stringify is *not*a JSON canonicalization solution.
> >  >>>
> >  >>> [1]: _http://gibson042.github.io/canonicaljson-spec/_
> >  >>> [2]:
> http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type
> >  >>> [3]:
> http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
> >  >>> [4]: https://tools.ietf.org/html/rfc8259#section-8.1
> >  >>
> >  >> Richard, I may be wrong but AFAICT, our respective
> canoncalization schemes are in fact principally IDENTICAL.
> >  >>
> >  >>
> >  >> In that they have the same goal, yes. In that they both
> achieve that goal, no. I'm not married to choices like exponential notation
> and uppercase escapes, but a JSON canonicalization scheme MUST cover all of
> JSON.
> >  >
> >  > Here it gets interesting...  What in JSON cannot be expressed
> through JS and JSON.stringify()?
> >  >
> >  >> That the number serialization provided by
> JSON.stringify() is unacceptable, is not generally taken as a fact.  I also
> think it looks a bit weird, but that's just a matter of esthetics.
> Compatibility is an entirely different issue.
> >  >>
> >  >>
> >  >> I concede this point. The modified algorit

Re: JSON.canonicalize()

[Mike Samuel]

Interop with systems that use 64b ints is not a .001% issue.

On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-18 15:47, Michał Wadas wrote:
> > JSON supports arbitrary precision numbers that can't be properly
> > represented as 64 bit floats. This includes numbers like eg. 1e or
> 1/1e.
>
> rfc7159:
> Since software that implements
> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
> generally available and widely used, good interoperability can be
> achieved by implementations that expect no more precision or range
> than these provide, in the sense that implementations will
> approximate JSON numbers within the expected precision
>
> If interoperability is not an issue you are free to do whatever you feel
> useful.
> Targeting a 0.001% customer base with standards, I gladly leave to others
> to cater for.
>
> The de-facto standard featured in any number of applications, is putting
> unusual/binary/whatever stuff in text strings.
>
> Anders
>
> >
> >
> > On Sun, 18 Mar 2018, 15:30 Anders Rundgren, <
> anders.rundgren@gmail.com >
> wrote:
> >
> > On 2018-03-18 15:08, Richard Gibson wrote:
> >> On Sunday, March 18, 2018, Anders Rundgren <
> anders.rundgren@gmail.com >
> wrote:
> >>
> >> On 2018-03-16 20:24, Richard Gibson wrote:
> >>> Though ECMAScript JSON.stringify may suffice for certain
> Javascript-centric use cases or otherwise restricted subsets thereof as
> addressed by JOSE, it is not suitable for producing canonical/hashable/etc.
> JSON, which requires a fully general solution such as [1]. Both its number
> serialization [2] and string serialization [3] specify aspects that harm
> compatibility (the former having arbitrary branches dependent upon the
> value of numbers, the latter being capable of producing invalid UTF-8 octet
> sequences that represent unpaired surrogate code points—unacceptable for
> exchange outside of a closed ecosystem [4]). JSON is a general
> /language-agnostic/interchange format, and ECMAScript JSON.stringify is
> *not*a JSON canonicalization solution.
> >>>
> >>> [1]: _http://gibson042.github.io/canonicaljson-spec/_
> >>> [2]:
> http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type
> >>> [3]:
> http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
> >>> [4]: https://tools.ietf.org/html/rfc8259#section-8.1
> >>
> >> Richard, I may be wrong but AFAICT, our respective
> canoncalization schemes are in fact principally IDENTICAL.
> >>
> >>
> >> In that they have the same goal, yes. In that they both achieve
> that goal, no. I'm not married to choices like exponential notation and
> uppercase escapes, but a JSON canonicalization scheme MUST cover all of
> JSON.
> >
> > Here it gets interesting...  What in JSON cannot be expressed
> through JS and JSON.stringify()?
> >
> >> That the number serialization provided by JSON.stringify() is
> unacceptable, is not generally taken as a fact.  I also think it looks a
> bit weird, but that's just a matter of esthetics.  Compatibility is an
> entirely different issue.
> >>
> >>
> >> I concede this point. The modified algorithm is sufficient, but
> note that a canonicalization scheme will remain static even if ECMAScript
> changes.
> >
> > Agreed.
> >
> >>
> >> Sorting on Unicode Code Points is of course "technically 100%
> right" but strictly put not necessary.
> >>
> >>
> >> Certain scenarios call for different systems to _independently_
> generate equivalent data structures, and it is a necessary property of
> canonical serialization that it yields identical results for equivalent
> data structures. JSON does not specify significance of object member
> ordering, so member ordering does not distinguish otherwise equivalent
> objects, so canonicalization MUST specify member ordering that is
> deterministic with respect to all valid data.
> >
> > Violently agree but do not understand (I guess I'm just dumb...) why
> (for example) sorting on UCS2/UTF-16 Code Units would not achieve the same
> goal (although the result would differ).
> >
> >>
> >> Your claim about uppercase Unicode escapes is incorrect, there
> is no such requirement:
> >>
> >> https://tools.ietf.org/html/rfc8259#section-7
> >>
> >> I don't recall ever making a claim about uppercase Unicode escapes,
> other than observing that it is the preferred form for examples in the JSON
> RFCs... what are you talking about?
> >
> > You're right, I found it it in the
> https://gibson042.github.io/canonicaljson-spec/#changelog
> >
> > Thanx,
> > Anders
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org 
> > 

Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 10:47 AM, Michał Wadas 
wrote:

> JSON supports arbitrary precision numbers that can't be properly
> represented as 64 bit floats. This includes numbers like eg. 1e or
> 1/1e.
>

I posted this on the summary thread but not here.

https://gist.github.com/mikesamuel/20710f94a53e440691f04bf79bc3d756 is
structured as a string to string transform, so doesn't lose precision when
round-tripping, e.g. Python bigints and Java BigDecimals.

It also avoids a space explosion for 1e which might help blunt timing
attacks as discussed earlier in this thread.



> On Sun, 18 Mar 2018, 15:30 Anders Rundgren, 
> wrote:
>
>> On 2018-03-18 15:08, Richard Gibson wrote:
>>
>> On Sunday, March 18, 2018, Anders Rundgren 
>> wrote:
>>
>>> On 2018-03-16 20:24, Richard Gibson wrote:
>>>
>>> Though ECMAScript JSON.stringify may suffice for certain
>>> Javascript-centric use cases or otherwise restricted subsets thereof as
>>> addressed by JOSE, it is not suitable for producing
>>> canonical/hashable/etc. JSON, which requires a fully general solution such
>>> as [1]. Both its number serialization [2] and string serialization [3]
>>> specify aspects that harm compatibility (the former having arbitrary
>>> branches dependent upon the value of numbers, the latter being capable of
>>> producing invalid UTF-8 octet sequences that represent unpaired surrogate
>>> code points—unacceptable for exchange outside of a closed ecosystem [4]).
>>> JSON is a general *language-agnostic* interchange format, and
>>> ECMAScript JSON.stringify is *not* a JSON canonicalization solution.
>>>
>>> [1]: *http://gibson042.github.io/canonicaljson-spec/
>>> *
>>> [2]: http://ecma-international.org/ecma-262/7.
>>> 0/#sec-tostring-applied-to-the-number-type
>>> [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
>>> [4]: https://tools.ietf.org/html/rfc8259#section-8.1
>>>
>>>
>>> Richard, I may be wrong but AFAICT, our respective canoncalization
>>> schemes are in fact principally IDENTICAL.
>>>
>>
>> In that they have the same goal, yes. In that they both achieve that
>> goal, no. I'm not married to choices like exponential notation and
>> uppercase escapes, but a JSON canonicalization scheme MUST cover all of
>> JSON.
>>
>>
>> Here it gets interesting...  What in JSON cannot be expressed through JS
>> and JSON.stringify()?
>>
>>
>>
>>> That the number serialization provided by JSON.stringify() is
>>> unacceptable, is not generally taken as a fact.  I also think it looks a
>>> bit weird, but that's just a matter of esthetics.  Compatibility is an
>>> entirely different issue.
>>>
>>
>> I concede this point. The modified algorithm is sufficient, but note that
>> a canonicalization scheme will remain static even if ECMAScript changes.
>>
>>
>> Agreed.
>>
>>
>> Sorting on Unicode Code Points is of course "technically 100% right" but
>>> strictly put not necessary.
>>>
>>
>> Certain scenarios call for different systems to _independently_ generate
>> equivalent data structures, and it is a necessary property of canonical
>> serialization that it yields identical results for equivalent data
>> structures. JSON does not specify significance of object member ordering,
>> so member ordering does not distinguish otherwise equivalent objects, so
>> canonicalization MUST specify member ordering that is deterministic with
>> respect to all valid data.
>>
>>
>> Violently agree but do not understand (I guess I'm just dumb...) why (for
>> example) sorting on UCS2/UTF-16 Code Units would not achieve the same goal
>> (although the result would differ).
>>
>>
>> Your claim about uppercase Unicode escapes is incorrect, there is no such
>>> requirement:
>>>
>> https://tools.ietf.org/html/rfc8259#section-7
>>>
>>
>> I don't recall ever making a claim about uppercase Unicode escapes, other
>> than observing that it is the preferred form for examples in the JSON
>> RFCs... what are you talking about?
>>
>>
>> You're right, I found it it in the https://gibson042.github.io/
>> canonicaljson-spec/#changelog
>>
>> Thanx,
>> Anders
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 10:43 AM, C. Scott Ananian 
wrote:

> On Sun, Mar 18, 2018, 10:30 AM Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> Violently agree but do not understand (I guess I'm just dumb...) why (for
>> example) sorting on UCS2/UTF-16 Code Units would not achieve the same goal
>> (although the result would differ).
>>
>
> Because there are JavaScript strings which do not form valid UTF-16 code
> units.  For example, the one-character string '\uD800'. On the input
> validation side, there are 8-bit strings which can not be decoded as
> UTF-8.  A complete sorting spec needs to describe how these are to be
> handled. For example, something like WTF-8: http://simonsapin.
> github.io/wtf-8/
>

Let's get terminology straight.
"\uD800" is a valid string of UTF-16 code units.   It is also a valid
string of codepoints.  It is not a valid string of scalar values.

http://www.unicode.org/glossary/#code_point : Any value in the Unicode
codespace; that is, the range of integers from 0 to 1016.
http://www.unicode.org/glossary/#code_unit : The minimal bit combination
that can represent a unit of encoded text for processing or interchange.
http://www.unicode.org/glossary/#unicode_scalar_value : Any Unicode *code
point * except high-surrogate
and low-surrogate code points. In other words, the ranges of integers 0 to
D7FF16 and E00016 to 1016 inclusive.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 10:08 AM, Richard Gibson 
wrote:

> On Sunday, March 18, 2018, Anders Rundgren 
> wrote:
>
>> On 2018-03-16 20:24, Richard Gibson wrote:
>>
>> Though ECMAScript JSON.stringify may suffice for certain
>> Javascript-centric use cases or otherwise restricted subsets thereof as
>> addressed by JOSE, it is not suitable for producing
>> canonical/hashable/etc. JSON, which requires a fully general solution such
>> as [1]. Both its number serialization [2] and string serialization [3]
>> specify aspects that harm compatibility (the former having arbitrary
>> branches dependent upon the value of numbers, the latter being capable of
>> producing invalid UTF-8 octet sequences that represent unpaired surrogate
>> code points—unacceptable for exchange outside of a closed ecosystem [4]).
>> JSON is a general *language-agnostic* interchange format, and ECMAScript
>> JSON.stringify is *not* a JSON canonicalization solution.
>>
>> [1]: *http://gibson042.github.io/canonicaljson-spec/
>> *
>> [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostrin
>> g-applied-to-the-number-type
>> [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
>> [4]: https://tools.ietf.org/html/rfc8259#section-8.1
>>
>>
>> Richard, I may be wrong but AFAICT, our respective canoncalization
>> schemes are in fact principally IDENTICAL.
>>
>
> In that they have the same goal, yes. In that they both achieve that goal,
> no. I'm not married to choices like exponential notation and uppercase
> escapes, but a JSON canonicalization scheme MUST cover all of JSON.
>
>
>> That the number serialization provided by JSON.stringify() is
>> unacceptable, is not generally taken as a fact.  I also think it looks a
>> bit weird, but that's just a matter of esthetics.  Compatibility is an
>> entirely different issue.
>>
>
> I concede this point. The modified algorithm is sufficient, but note that
> a canonicalization scheme will remain static even if ECMAScript changes.
>

Does this mean that the language below would need to be fixed at a specific
version of Unicode or that we would need to cite a specific version for
canonicalization but might allow a higher version for
String.prototype.normalize
and in future versions of the spec require it?

http://www.ecma-international.org/ecma-262/6.0/#sec-conformance
"""
A conforming implementation of ECMAScript must interpret source text input
in conformance with the Unicode Standard, Version 5.1.0 or later
"""

and in ECMA 404


"""
For undated references, the latest edition of the referenced document
(including any amendments) applies. ISO/IEC 10646, Information Technology –
Universal Coded Character Set (UCS) The Unicode Consortium. The Unicode
Standard http://www.unicode.org/versions/latest.
"""


Sorting on Unicode Code Points is of course "technically 100% right" but
>> strictly put not necessary.
>>
>
> Certain scenarios call for different systems to _independently_ generate
> equivalent data structures, and it is a necessary property of canonical
> serialization that it yields identical results for equivalent data
> structures. JSON does not specify significance of object member ordering,
> so member ordering does not distinguish otherwise equivalent objects, so
> canonicalization MUST specify member ordering that is deterministic with
> respect to all valid data.
>

Code points include orphaned surrogates in a way that scalar values do not,
right?  So both "\uD800" and "\uD800\uDC00" are single codepoints.
It seems like a strict prefix of a string should still sort before that
string but prefix transitivity in general does not hold: "\u" <
"\uD800\uDC00" && "\u" > "\uD800".
That shouldn't cause problems for hashability but I thought I'd raise it
just in case.



> Your claim about uppercase Unicode escapes is incorrect, there is no such
>> requirement:
>>
> https://tools.ietf.org/html/rfc8259#section-7
>>
>
> I don't recall ever making a claim about uppercase Unicode escapes, other
> than observing that it is the preferred form for examples in the JSON
> RFCs... what are you talking about?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary of Input. Re: JSON.canonicalize()

[Mike Samuel]

On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> Hi Guys,
>
> Pardon me if you think I was hyperbolic,
> The discussion got derailed by the bogus claims about hash functions'
> vulnerability.
>

I didn't say I "think" you were being hyperbolic.  I asked whether you were.

You asserted a number that seemed high to me.
I demonstrated it was high by a factor of at least 25 by showing an
implementation that
used 80 lines instead of the 2000 you said was required.

If you're going to put out a number as a reason to dismiss an argument, you
should own it
or retract it.
Were you being hyperbolic?  (Y/N)

Your claim and my counterclaim are in no way linked to hash function
vulnerability.
I never weighed in on that claim and have already granted that hashable
JSON is a
worthwhile use case.



> F.Y.I: Using ES6 serialization methods for JSON primitive types is headed
> for standardization in the IETF.
> https://www.ietf.org/mail-archive/web/jose/current/msg05716.html
>
> This effort is backed by one of the main authors behind the current
> de-facto standard for Signed and Encrypted JSON, aka JOSE.
> If this is in your opinion is a bad idea, now is the right time to shoot
> it down :-)
>

Does this main author prefer your particular JSON canonicalization scheme to
others?
Is this an informed opinion based on flaws in the others that make them
less suitable for
JOSE's needs that are not present in the scheme you back?

If so, please provide links to their reasoning.
If not, how is their backing relevant?



> This efforts also exploits the ability of JSON.parse() and
> JSON.stringify() honoring object "Creation Order".
>
> JSON.canonicalize() would be a "Sorting" alternative to "Creation Order"
> offering certain advantages with limiting deployment impact to JSON
> serializers as the most important one.
>
> The ["completely broken"] sample code was only submitted as a
> proof-of-concept. I'm sure you JS gurus can do this way better than I :-)
>

This is a misquote.  No-one has said your sample code was completely broken.
Neither your sample code nor the spec deals with toJSON.  At some point
you're
going to have to address that if you want to keep your proposal moving
forward.
No amount of JS guru-ry is going to save your sample code from a
specification bug.



> Creating an alternative based on [1,2,3] seems like a rather daunting task.
>

Maybe if you spend more time laying out the criteria on which a successful
proposal
should be judged, we could move towards consensus on this claim.

As it is, I have only your say so but I have reason to doubt your evaluation
of task complexity unless you were being hyperbolic before.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: add reverse() method to strings

[Mike Samuel]

Previous discussion:
https://esdiscuss.org/topic/wiki-updates-for-string-number-and-math-libraries#content-1

"""
String.prototype.reverse(), as proposed, corrupts supplementary characters.
Clause 6 of Ecma-262 redefines the word "character" as "a 16-bit unsigned
value used to represent a single 16-bit unit of text", that is, a UTF-16
code unit. In contrast, the phrase "Unicode character" is used for Unicode
code points. For reverse(), this means that the proposed spec will reverse
the sequence of the two UTF-16 code units representing a supplementary
character, resulting in corruption. If this function is really needed (is
it? for what?), it should preserve the order of surrogate pairs, as does
java.lang.StringBuilder.reverse:
download.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#reverse()
"""

On Sat, Mar 17, 2018 at 1:41 PM, Grigory Hatsevich 
wrote:

> Hi! I would propose to add reverse() method to strings. Something
> equivalent to the following:
>
> String.prototype.reverse = function(){
>   return this.split('').reverse().join('')
> }
>
> It seems natural to have such method. Why not?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary of Input. Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

>
>
> On my part I added canonicalization to my ES6.JSON compliant Java-based
> JSON tools.  A single line did 99% of the job:
> https://github.com/cyberphone/openkeystore/blob/jose-compati
> ble/library/src/org/webpki/json/JSONObjectWriter.java#L928
>
> for (String property : canonicalized ? new 
> TreeSet(object.properties.keySet())
> : object.properties.keySet()) {
>

If this is what you want then can't you just use a replacer to substitute a
record with sorted keys?

JSON.canonicalize = (value) => JSON.stringify(value, (_, value) => {
  if (value && typeof value === 'object' && !Array.isArray(value)) {
const withSortedKeys = {}
const keys = Object.getOwnPropertyNames(value)
keys.sort()
keys.forEach(key => withSortedKeys[key] = value[key])
value = withSortedKeys
  }
  return value
})
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary of Input. Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> Scott A:
> https://en.wikipedia.org/wiki/Security_level
> "For example, SHA-256 offers 128-bit collision resistance"
> That is, the claims that there are cryptographic issues w.r.t. to Unicode
> Normalization are (fortunately) incorrect.
> Well, if you actually do normalize Unicode, signatures would indeed break,
> so you don't.
>
> Richard G:
> Is the [highly involuntary] "inspiration" to the JSON.canonicalize()
> proposal:
> https://www.ietf.org/mail-archive/web/json/current/msg04257.html
> Why not fork your go library? Then there would be three implementations!
>
> Mike S:
> Wants to build a 2000+ line standalone JSON canonicalizer working on
> string data.
> That's great but I think that it will be a hard sell getting these guys
> accept the Pull Request:
> https://developers.google.com/v8/
> JSON.canonicalize(JSON.parse("json string data to be canonicalized"))
> would IMHO do the same job.
> My (working) code example was only provided to show the principle as well
> as being able to test/verify.
>

I don't know where you get the 2000+ line number.
https://gist.github.com/mikesamuel/20710f94a53e440691f04bf79bc3d756 comes
in at 80 lines.
That's roughly twice as long as your demonstrably broken example code, but
far shorter than the number you provided.

If you're being hyperbolic, please stop.
If that was a genuine guesstimate, but you just happened to be off by a
factor of 25, then I have less confidence that
you can weigh the design complexity tradeoffs when comparing your's to
other proposals.


> On my part I added canonicalization to my ES6.JSON compliant Java-based
> JSON tools.  A single line did 99% of the job:
> https://github.com/cyberphone/openkeystore/blob/jose-compati
> ble/library/src/org/webpki/json/JSONObjectWriter.java#L928

for (String property : canonicalized ? new
TreeSet(object.properties.keySet())
> : object.properties.keySet()) {
>
>
> Other mentioned issues like HTML safety, embedded nulls etc. would apply
> to JSON.stringify() as well.
> JSON.canonicalize() would inherit all the features (and weaknesses) of
> JSON.stringify().
>

Please, when you attribute a summary to me, don't ignore the summary that I
myself wrote of my arguments.

You're ignoring the context.  JSON.canonicalize is not generally useful
because it undoes safety precautions.
That tied into one argument of mine that you left out: JSON.canonicalize is
not generally useful.  It should probably not
be used as a wire or storage format, and is entirely unsuitable for
embedding into other commonly used web application
languages.

You also make no mention of backwards compatibility concerns when this
depends on things like toJSON, which is hugely important
when dealing with long lived hashes.

When I see that you've summarized my own thoughts incorrectly, even though
I provided you with a summary of my own arguments,
I lose confidence that you've correctly summarized other's positions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018, 4:58 PM Anders Rundgren <anders.rundgren@gmail.com>
wrote:

> On 2018-03-16 21:41, Mike Samuel wrote:
> >
> >
> > On Fri, Mar 16, 2018 at 4:34 PM, C. Scott Ananian <ecmascr...@cscott.net
> <mailto:ecmascr...@cscott.net>> wrote:
> >
> > On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
>
> > To restate my main objections:
> >
> > I think any proposal to offer an alternative stringify instead of a
> string->string transform is not very good
> > and could be easily improved by rephrasing it as a string->string
> transform.
>
> Could you give a concrete example on that?
>
>
>
I've given three.  As written, the proposal produces invalid or low quality
output given (undefined, objects with toJSON methods, and symbols as either
keys or values).  These would not be problems for a real canonicalizer
since none are present in a string of JSON.

In addition, two distant users of the canonicalizer who wish to check
hashes need to agree on the ancillary arguments like the replacer if
canonicalize takes the same arguments and actually uses them.  They also
need to agree on implementation details of toJSON methods which is a
backward compatibility hazard.

If you did solve the toJSON problem by incorporating calls to that method
you've now complicated cross-platform behavior.  If you phrase in terms of
string->string it is much easier to disentangle the definition of
canonicalizers JSON from JS and make it language agnostic.

Finally, your proposal is not the VHS of canonicalizers.  That would be
x=>JSON.stringify(JSON.parse(x)) since it's deployed and used.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 4:34 PM, C. Scott Ananian 
wrote:

> On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> Perfection is often the enemy of good.
>>
>
> So, to be clear: you don't plan on actually incorporating any feedback
> into your proposal, since it's already "good"?
>

To restate my main objections:

I think any proposal to offer an alternative stringify instead of a
string->string transform is not very good
and could be easily improved by rephrasing it as a string->string transform.

Also, presenting this as a better wire format I think is misleading since I
think it has no advantages as a wire format over JSON.stringify's
output, and recommending canonical JSON, except for the short duration
needed to hash it creates more problems than it solves.


>   --scott
>
>
> ___
> 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: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 3:23 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-16 20:09, Mike Samuel wrote:
>
>>
>> Availability beats perfection anytime.  This is the VHS (if anybody
>> remember that old story) of canonicalization and I don't feel too bad about
>> that :-)
>>
>>
>> Perhaps.  Any thoughts on my question about the merits of "Hashable" vs
>> "Canonical"?
>>
>
> No, there were so much noise here so I may have need a more dense
> description if possible.
>

In the email to which you responded "Have you actually looked ..." look for
"If that is correct, Would people be averse to marketing this as "hashable
JSON" instead of "canonical JSON?""
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 3:03 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-16 19:51, Mike Samuel wrote:
>
>>
>>
>> On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren <
>> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
>> wrote:
>>
>> On 2018-03-16 19:30, Mike Samuel wrote:
>>
>> 2. Any numbers with minimal changes: dropping + signs,
>> normalizing zeros,
>>   using a fixed threshold for scientific notation.
>>   PROS: supports whole JSON value-space
>>   CONS: less useful for hashing
>>   CONS: risks loss of precision when decoders decide based on
>> presence of
>>  decimal point whether to represent as double or int.
>>
>>
>> Have you actually looked into the specification?
>> https://cyberphone.github.io/doc/security/draft-rundgren-jso
>> n-canonicalization-scheme.html#rfc.section.3.2.2 <
>> https://cyberphone.github.io/doc/security/draft-rundgren-js
>> on-canonicalization-scheme.html#rfc.section.3.2.2>
>> ES6 has all what it takes.
>>
>>
>> Yes, but other notions of canonical equivalence have been mentioned here
>> so reasons to prefer one to another seem in scope.
>>
>
> Availability beats perfection anytime.  This is the VHS (if anybody
> remember that old story) of canonicalization and I don't feel too bad about
> that :-)


Perhaps.  Any thoughts on my question about the merits of "Hashable" vs
"Canonical"?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-16 19:30, Mike Samuel wrote:
>
>> 2. Any numbers with minimal changes: dropping + signs, normalizing zeros,
>>  using a fixed threshold for scientific notation.
>>  PROS: supports whole JSON value-space
>>  CONS: less useful for hashing
>>  CONS: risks loss of precision when decoders decide based on presence
>> of
>> decimal point whether to represent as double or int.
>>
>
> Have you actually looked into the specification?
> https://cyberphone.github.io/doc/security/draft-rundgren-jso
> n-canonicalization-scheme.html#rfc.section.3.2.2
> ES6 has all what it takes.
>

Yes, but other notions of canonical equivalence have been mentioned here
so reasons to prefer one to another seem in scope.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 1:54 PM, C. Scott Ananian <ecmascr...@cscott.net>
wrote:

> And just to be clear: I'm all for standardizing a canonical JSON form.  In
> addition to my 11-year-old attempt, there have been countless others, and
> still no *standard*.  I just want us to learn from the previous attempts
> and try to make something at least as good as everything which has come
> before, especially in terms of the various non-obvious considerations which
> individual implementors have discovered the hard way over the years.
>

I think the hashing use case is an important one.  At the risk of
bikeshedding, "canonical" seems to overstate the usefulness.  Many assume
that the canonical form of something is usually the one you use in
preference to any other equivalent.

If the integer-only restriction is relaxed (see below), then
* The proposed canonical form seems useful as an input to strong hash
functions.
* It seems usable as a complete message body, but not preferable due to
potential loss of precision.
* It seems usable but not preferable as a long-term storage format.
* It seems a source of additional risk when used in conjunction with other
common web languages.

If that is correct, Would people be averse to marketing this as "hashable
JSON" instead of "canonical JSON?"

--

Numbers

There seem to be 3 main forks in the design space w.r.t. numbers.  I'm sure
cscott has thought of more, but to make it clear why I think canonical JSON
is not very useful as a wire/storage format.

1. Integers only
PROS: avoids floating point equality issues that have bedeviled many
systems
CONS: can support only a small portion of the JSON value space
CONS: small loss of precision risk with integers encoded from Decimal
values.
For example, won't roundtrip Java BigDecimals.
2. Any numbers with minimal changes: dropping + signs, normalizing zeros,
using a fixed threshold for scientific notation.
PROS: supports whole JSON value-space
CONS: less useful for hashing
CONS: risks loss of precision when decoders decide based on presence of
   decimal point whether to represent as double or int.
3. Preserve textual representation.
PROS: avoids loss of precision
PROS: can support whole JSON value-space
CONS: not very useful for hashing

It seems that there is a tradeoff between usefulness for hashing and the
ability to
support the whole JSON value-space.

Recommending this as a wire / storage format further complicates that
tradeoff.

Regardless of which fork is chosen, there are some risks with the current
design.
For example, 1e10 takes up some space in memory.  This might allow
timing attacks.
Imagine an attacker can get Alice to embed 1e10 or another number in
her JSON.
Alice sends that message to Bob over an encrypted channel.  Bob converts
the JSON to
canonical JSON.  If Bob refuses some JSON payloads over a threshold size or
the
time to process is noticably different for 1e10 vs 1e1 then the
attacker can
tell, via traffic analysis alone, when Alice communicates with Bob.
We should avoid that in-memory blowup if possible.






>   --scott
>
> On Fri, Mar 16, 2018 at 1:46 PM, Mike Samuel <mikesam...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 16, 2018 at 1:30 PM, Anders Rundgren <
>> anders.rundgren@gmail.com> wrote:
>>
>>> On 2018-03-16 18:04, Mike Samuel wrote:
>>>
>>> It is entirely unsuitable to embedding in HTML or XML though.
>>>> IIUC, with an implementation based on this
>>>>
>>>>JSON.canonicalize(JSON.stringify("")) === `""` &&
>>>> JSON.canonicalize(JSON.stringify("]]>")) === `"]]>"`
>>>>
>>>
>>> I don't know what you are trying to prove here :-)
>>>
>>
>> Only that canonical JSON is useful in a very narrow context.
>> It cannot be embedded in an HTML script tag.
>> It cannot be embedded in an XML or HTML foreign content context without
>> extra care.
>> If it contains a string literal that embeds a NUL it cannot be embedded
>> in XML period even if extra care is taken.
>>
>>
>>
>>>
>>> The output of JSON.canonicalize would also not be in the subset of JSON
>>>> that is also a subset of JavaScript's PrimaryExpression.
>>>>
>>>> JSON.canonicalize(JSON.stringify("\u2028\u2029")) ===
>>>> `"\u2028\u2029"`
>>>>
>>>> It also is not suitable for use internally within systems that
>>>> internally use cstrings.
>>>>
>>>>JSON.canonicalize(JSON.stringify("\u")) === `"\u"`
>>>>
>>>>
>>> JSON.canonicali

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 1:30 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-03-16 18:04, Mike Samuel wrote:
>
> It is entirely unsuitable to embedding in HTML or XML though.
>> IIUC, with an implementation based on this
>>
>>JSON.canonicalize(JSON.stringify("")) === `""` &&
>> JSON.canonicalize(JSON.stringify("]]>")) === `"]]>"`
>>
>
> I don't know what you are trying to prove here :-)
>

Only that canonical JSON is useful in a very narrow context.
It cannot be embedded in an HTML script tag.
It cannot be embedded in an XML or HTML foreign content context without
extra care.
If it contains a string literal that embeds a NUL it cannot be embedded in
XML period even if extra care is taken.



>
> The output of JSON.canonicalize would also not be in the subset of JSON
>> that is also a subset of JavaScript's PrimaryExpression.
>>
>> JSON.canonicalize(JSON.stringify("\u2028\u2029")) ===
>> `"\u2028\u2029"`
>>
>> It also is not suitable for use internally within systems that internally
>> use cstrings.
>>
>>JSON.canonicalize(JSON.stringify("\u")) === `"\u"`
>>
>>
> JSON.canonicalize() would be [almost] identical to JSON.stringify()
>

You're correct.  Many JSON producers have a web-safe version, but the
JavaScript builtin does not.
My point is that JSON.canonicalize undoes those web-safety tweaks.



> JSON.canonicalize(JSON.parse('"\u2028\u2029"')) === '"\u2028\u2029"'  //
> Returns true
>
> "Emulator":
>
> var canonicalize = function(object) {
>
> var buffer = '';
> serialize(object);
>

I thought canonicalize took in a string of JSON and produced the same.  Am
I wrong?
"Canonicalize" to my mind means a function that returns the canonical
member of an
equivalence class given any member from that same equivalence class, so is
always 'a -> 'a.


> return buffer;
>
> function serialize(object) {
> if (object !== null && typeof object === 'object') {
>

JSON.stringify(new Date(0)) === "\"1970-01-01T00:00:00.000Z\""
because Date.prototype.toJSON exists.

If you operate as a JSON_string -> JSON_string function then you
can avoid this complexity.

if (Array.isArray(object)) {
> buffer += '[';
> let next = false;
> object.forEach((element) => {
> if (next) {
> buffer += ',';
> }
> next = true;
> serialize(element);
> });
> buffer += ']';
> } else {
> buffer += '{';
> let next = false;
> Object.keys(object).sort().forEach((property) => {
> if (next) {
> buffer += ',';
> }
> next = true;

buffer += JSON.stringify(property);
>

I think you need a symbol check here.  JSON.stringify(Symbol.for('foo'))
=== undefined


> buffer += ':';
> serialize(object[property]);
> });
> buffer += '}';
> }
> } else {
> buffer += JSON.stringify(object);
>

This fails to distinguish non-integral numbers from integral ones, and
produces non-standard output
when object === undefined.  Again, not a problem if the input is required
to be valid JSON.


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

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 12:44 PM, C. Scott Ananian <ecmascr...@cscott.net>
wrote:

> On Fri, Mar 16, 2018 at 12:23 PM, Mike Samuel <mikesam...@gmail.com>
> wrote:
>>
>>
>> On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian <ecmascr...@cscott.net
>> > wrote:
>>
>>> Canonical JSON is often used to imply a security property: two JSON
>>> blobs with identical contents are expected to have identical canonical JSON
>>> forms (and thus identical hashed values).
>>>
>>
>> What does "identical contents" mean in the context of numbers?  JSON
>> intentionally avoids specifying any precision for numbers.
>>
>> JSON.stringify(1/3) === '0.'
>>
>> What would happen with JSON from systems that allow higher precision?
>> I.e., what would (JSON.canonicalize(JSON.stringify(1/3) + '3')) produce?
>>
>> However, unicode normalization allows multiple representations of "the
>>> same" string, which defeats this security property.  Depending on your
>>> implementation language
>>>
>>
>> We shouldn't normalize unicode in strings that contain packed binary
>> data.  JSON strings are strings of UTF-16 code-units, not Unicode scalar
>> values and any system that assumes the latter will break often.
>>
>
> Both of these points are made on the URL I originally cited:
> http://wiki.laptop.org/go/Canonical_JSON
>

Thanks, I see
"""
Floating point numbers are not allowed in canonical JSON. Neither are
leading zeros or "minus 0" for integers.
"""
which answers my question.

I also see
"""
A previous version of this specification required strings to be valid
unicode, and relied on JSON's \u escape. This was abandoned as it doesn't
allow representing arbitrary binary data in a string, and it doesn't
preserve the identity of non-canonical unicode strings.
"""
which addresses my question.

I also see
"""
It is suggested that unicode strings be represented as the UTF-8 encoding
of unicode Normalization Form C <http://www.unicode.org/reports/tr15/> (UAX
#15). However, arbitrary content may be represented as a string: it is not
guaranteed that string contents can be meaningfully parsed as UTF-8.
"""
which seems to be mixing concerns about the wire format used to encode JSON
as octets and NFC which would apply to the text of the JSON string.


If that confusion is cleaned up, then it seems a fine subset of JSON to
ship over the wire with a JSON content-type.


It is entirely unsuitable to embedding in HTML or XML though.
IIUC, with an implementation based on this

  JSON.canonicalize(JSON.stringify("")) === `""` &&
  JSON.canonicalize(JSON.stringify("]]>")) === `"]]>"`

The output of JSON.canonicalize would also not be in the subset of JSON
that is also a subset of JavaScript's PrimaryExpression.

   JSON.canonicalize(JSON.stringify("\u2028\u2029")) === `"\u2028\u2029"`

It also is not suitable for use internally within systems that internally
use cstrings.

  JSON.canonicalize(JSON.stringify("\u")) === `"\u"`
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON.canonicalize()

[Mike Samuel]

On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian 
wrote:

> Canonical JSON is often used to imply a security property: two JSON blobs
> with identical contents are expected to have identical canonical JSON forms
> (and thus identical hashed values).
>

What does "identical contents" mean in the context of numbers?  JSON
intentionally avoids specifying any precision for numbers.

JSON.stringify(1/3) === '0.'

What would happen with JSON from systems that allow higher precision?
I.e., what would (JSON.canonicalize(JSON.stringify(1/3) + '3')) produce?





> However, unicode normalization allows multiple representations of "the
> same" string, which defeats this security property.  Depending on your
> implementation language
>

We shouldn't normalize unicode in strings that contain packed binary data.
JSON strings are strings of UTF-16 code-units, not Unicode scalar values
and any system that assumes the latter will break often.


> and use, a string with precomposed accepts could compare equal to a string
> with separated accents, even though the canonical JSON or hash differed.
> In an extreme case (with a weak hash function, say MD5), this can be used
> to break security by re-encoding all strings in multiple variants until a
> collision is found.  This is just a slight variant on the fact that JSON
> allows multiple ways to encode a character using escape sequences.  You've
> already taken the trouble to disambiguate this case; security-conscious
> applications should take care to perform unicode normalization as well, for
> the same reason.
>
> Similarly, if you don't offer a verifier to ensure that the input is in
> "canonical JSON" format, then an attacker can try to create collisions by
> violating the rules of canonical JSON format, whether by using different
> escape sequences, adding whitespace, etc.  This can be used to make JSON
> which is "the same" appear "different", violating the intent of the
> canonicalization.  Any security application of canonical JSON will require
> a strict mode for JSON.parse() as well as a strict mode for
> JSON.stringify().
>

Given the dodginess of "identical" w.r.t. non-integral numbers, shouldn't
endpoints be re-canonicalizing before hashing anyway?  Why would one want
to ship the canonical form over the wire if it loses precision?



>   --scott
>
> On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> On 2018-03-16 08:52, C. Scott Ananian wrote:
>>
>>> See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
>>> least
>>> mention unicode normalization of strings.
>>>
>>
>> Yes, I could add that unicode normalization of strings is out of scope
>> for this specification.
>>
>>
>> You probably should also specify a validator: it doesn't matter if you
>>> emit canonical JSON if you can tweak the hash of the value by feeding
>>> non-canonical JSON as an input.
>>>
>>
>> Pardon me, but I don't understand what you are writing here.
>>
>> Hash functions only "raison d'être" are providing collision safe
>> checksums.
>>
>> thanx,
>> Anders
>>
>>
>>--scott
>>>
>>> On Fri, Mar 16, 2018 at 3:16 AM, Anders Rundgren <
>>> anders.rundgren@gmail.com >
>>> wrote:
>>>
>>> Dear List,
>>>
>>> Here is a proposal that I would be very happy getting feedback on
>>> since it builds on ES but is not (at all) limited to ES.
>>>
>>> The request is for a complement to the ES "JSON" object called
>>> canonicalize() which would have identical parameters to the existing
>>> stringify() method.
>>>
>>
Why should canonicalize take a replacer?  Hasn't replacement already
happened?



> The JSON canonicalization scheme (including ES code for emulating it),
>>> is described in:
>>> https://cyberphone.github.io/doc/security/draft-rundgren-jso
>>> n-canonicalization-scheme.html >> doc/security/draft-rundgren-json-canonicalization-scheme.html>
>>>
>>> Current workspace: https://github.com/cyberphone/
>>> json-canonicalization >> /json-canonicalization>
>>>
>>> Thanx,
>>> Anders Rundgren
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org 
>>> https://mail.mozilla.org/listinfo/es-discuss <
>>> https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>>
>>>
>>
>
> ___
> 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: Strawman: Module Keys

[Mike Samuel]

On Fri, Mar 2, 2018 at 8:29 PM, Alex Vincent <ajvinc...@gmail.com> wrote:

> On Wed, Feb 28, 2018 at 4:00 AM, <es-discuss-requ...@mozilla.org> wrote:
>
>> From: Mike Samuel <mikesam...@gmail.com>I'm looking for other criticism
>> of https://github.com/mikesamuel/tc39-module-keys and for interested
>> parties who might have time to refine it.
>
>
> I'm just taking a bit of time to read over it.  Keep in mind, I'm no
> security expert.
>

Thanks for giving it a read.


> In the spec, you write,
>
>> We use the name frenemies below. This is a terrible name.
>
>
> I suggest "counterparties".  https://www.investopedia.com/
> terms/c/counterparty.asp
>
> What's a Box?  (I'm serious.  You really don't define what it is in this
> context.)  You also talk about boxed values and unboxed values, but I may
> have missed the paragraphs explaining the difference.
>

Good point.  A "box" is an instance of `class Box`.
The important thing about Boxes is that if frenemies0 and frenemies1 are
outputs from makeFrenemies then

  value === frenemies0.unbox(
  frenemies1.box(value, (k) => true),
  (k) => true)

so the unbox function reverses the box function when things are permissive.

Where this becomes useful is when we use a predicate less permissive than
(k => true).
The value associated with a box can only be accessed if both the box caller
and the unbox caller
agree.

  value === frenemies0.unbox(
  frenemies1.box(value, (k) => k === frenemies0.publicKey && k()),
  (k) => k === frenemies1.publicKey && k())

Public keys can be passed to predicates.  The private key is used within
unbox to ensure
that the public key only returns true when checked on behalf of the module
that owns it.

The first ((k) => ...) predicate lets frenemies1 ensure that only
frenemies0.unbox can open the value.
The second predicate lets frenemies0 ensure that the box came from
frenemies1


> In your example code sections, you imply these properties are directly
> named as properties of alice and bob, respectively... do we want all of
> those as such, or maybe under a namespace (alice[someNameOrSymbol].publicKey)?
> Particularly with such generic names as box and unbox...
> I'd feel more comfortable if they were under a predefined
> Symbol.MODULE_KEYS namespace.
>

The only frenemies property that is implicitly exported is publicKey.
Having a well-known symbol for the public key seems reasonable.



> That's my two cents - and they're worth exactly that much after
> inflation.  :-)
>
> Alex
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>
> ___
> 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

Strawman: Module Keys

[Mike Samuel]

I'm looking for other criticism of
https://github.com/mikesamuel/tc39-module-keys and for interested parties
who might have time to refine it.

This adds public/private key analogues to ModuleBodies along with some
associated operators.

As background, we on Google's security engineering group have had a lot of
success hooking into build systems, linkers and using static analyzers to
identify problematic code patterns, guide developers towards safe ones, and
make sure we find out about things that we want to know about.  This has
let a small group of security engineers manage the security of a much
larger group of application developers without us-vs-them dynamics.

I hope that some machinery like this might enable similar dynamics within
open-source projects that don't have monolithic code repos.

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

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Tue, Feb 20, 2018 at 1:32 PM, Mike Samuel <mikesam...@gmail.com> wrote:

>
>
> On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesam...@gmail.com>
>> wrote:
>> >
>> > I'm probably just going to echo themes that T.J. has dealt with better,
>> but:
>>
>> Quite the opposite.
>>
>> And keying off Mike's excellent summary: I like the idea of providing a
>> means of handling preconditions (and postconditions), of which runtime type
>> checking is one example but only one. I'd just prefer to see it as a
>> general mechanism than type-checking specifically.
>>
>> I suggest getting deep into the decorators stuff and helping push it
>> forward, possibly into areas where it hasn't previously been headed (such
>> as your `let x = sum(y, y)` where you want to have runtime type checking on
>> what gets assigned to `x` -- as far as I know, that isn't even on their
>> radar). Basically that's applying a precondition to the assignment to `x`
>> (or a postcondition on the call to `sum`). Which could be interesting. You
>> may or may not get agreement on pushing forward that far, but if you feel
>> strongly about the functionality you're after, I see that as the direction
>> to pursue. (Not that I'm in ANY way any kind of authority on moving things
>> through the process here. Not remotely.)
>>
>> -- T.J. Crowder
>>
>
> One way that decorators (I keep saying annotations) for locals might work
> is:
>
> @foo
> const x = initialValue
> f(x)
>
> desugars to
>
> const x = foo(undefined, initialValue)
> f(foo(x))
>
> When the decorated local is used as a left-hand side, the use is wrapped
> in a call to the decorator.
> When the decorated local is used as a right-hand side, the value assigned
> is the result of the decorator applied to the previous value and the
> candidate value.
>
> I think that would be enough to build guards upon.
>
>
I cited this thread as a use case for local decorators at
https://github.com/tc39/proposal-decorators/issues/51#issuecomment-367106358
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesam...@gmail.com> wrote:
> >
> > I'm probably just going to echo themes that T.J. has dealt with better,
> but:
>
> Quite the opposite.
>
> And keying off Mike's excellent summary: I like the idea of providing a
> means of handling preconditions (and postconditions), of which runtime type
> checking is one example but only one. I'd just prefer to see it as a
> general mechanism than type-checking specifically.
>
> I suggest getting deep into the decorators stuff and helping push it
> forward, possibly into areas where it hasn't previously been headed (such
> as your `let x = sum(y, y)` where you want to have runtime type checking on
> what gets assigned to `x` -- as far as I know, that isn't even on their
> radar). Basically that's applying a precondition to the assignment to `x`
> (or a postcondition on the call to `sum`). Which could be interesting. You
> may or may not get agreement on pushing forward that far, but if you feel
> strongly about the functionality you're after, I see that as the direction
> to pursue. (Not that I'm in ANY way any kind of authority on moving things
> through the process here. Not remotely.)
>
> -- T.J. Crowder
>

One way that decorators (I keep saying annotations) for locals might work
is:

@foo
const x = initialValue
f(x)

desugars to

const x = foo(undefined, initialValue)
f(foo(x))

When the decorated local is used as a left-hand side, the use is wrapped in
a call to the decorator.
When the decorated local is used as a right-hand side, the value assigned
is the result of the decorator applied to the previous value and the
candidate value.

I think that would be enough to build guards upon.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Tue, Feb 20, 2018 at 12:33 PM, Александр Ефремов 
wrote:

> Anyone else has interes to this proposal?
>

I'm probably just going to echo themes that T.J. has dealt with better, but:

Things i like:
- provides preconditions
- guards locals

Things I don't like:
- doesn't deal with postconditions
- somewhat redundant with annotations
- adds syntax

It seems that there are two separable issues:
1. Defining guards
2. Syntax for specifying guards.

It seems to me that (2) might be doable with annotations for locals,
so deploying guards could build on annotations.

Where your proposal shines, is in a definition of a guard.
I don't much like the way the definition is tied to classes though.
Maybe, for
  class C {}
make
  C(x)  // [[Call]] not [[Construct]]
default to (x instanceof this) unless the static property you propose is
defined.

That would allow you to use any function type as a value predicate which is
the
minimum needed for a guard.

Leave sub-types that don't override [hasInstance] from super-types to
linters.

If confusion between (new C(x)) and (C(x)) is too much of a hazard, maybe
adjust the calling convention for guards so that they always receive a
well-known
symbol as the first argument, so can switch between acting as a predicate
and
telling developers how to create class instances.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Tue, Feb 20, 2018 at 8:37 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Tue, Feb 20, 2018 at 1:15 PM, Terence M. Bandoian 
> wrote:
> >
> > Wasn't JavaScript originally designed for use in the Netscape
> > browser?  Maybe it's more correct to say that it was originally
> > designed for use in web browsers but has been and is being
> > adapted for other purposes.
>
> The initial version was done in those 10 fateful days in May 1995 (the
> rush was to stave off competing proposals). Shipped in Netscape Navigator
> in September 1995, and in Netscape Enterprise Server in December (for
> server-side scripting). So for three months in 1995, JavaScript was in the
> wild as a browser-only language; only Brendan Eich or others there at the
> time can say what the plan for it was.
>
> Regardless how you want to read that, origins more than 22 years ago don't
> inform what to use modern JavaScript for in 2018, nor how the language
> should move forward from here.
>


In the hopes that quoting relevant docs can help refocus, the TC39 charter
 says

"""
Scope:
Standardization of the general purpose, cross platform, vendor-neutral
programming language ECMAScript. ...
"""

Contrast that with the webapps working group charter which does make
explicit mention of clients and the web:
"""
The scope of the Web Applications Working Group covers the technologies
related to developing
client-side applications on the Web, ...
"""

Any discussions about changing the TC39 charter would probably have to
involve the larger ECMA organization
so it seems off topic to discuss them in a thread devoted to a specific
proposal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: For-has-in loop

[Mike Samuel]

On Mon, Feb 19, 2018 at 1:50 PM, Sebastian Malton 
wrote:

> I would like to propose that the following be valid since it is a very
> common use case.
>
> ```
> for (const field has in object) {
> 
> }
> ```
>
> Would be equivalent to:
>
> ```
> for (const field in object) {
> if (!object.hasOwnPropety(field)) {
> continue;
> }
> 
> }
> ```
>

I'm generally supportive of getting rid of error-prone calls to
hasOwnProperty methods
since they fail when there is a "hasOwnProperty" field anywhere on the
prototype chain
between object and Object.prototype.

This idiom looks like something that usually almost means what its author
intends but rarely
exactly.

Are there any proposals for an `in` operator variant that only checks for
own properties?
If so, the syntax could be synchronized with that.
(I thought there was one but couldn't find it on
https://github.com/tc39/proposals )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Partial regexp matching

[Mike Samuel]

On Mon, Feb 19, 2018 at 1:15 PM, Isiah Meadows 
wrote:

>
> >
> > We can't base a distinction between yes and maybe on whether a
> > zero-width $ assertion is triggered if there are paths to completion
> > that do not pass through that assertion.
> >
> >
> > const re = /^foo($|d).?/
> >
> > // This variant uses the $ assertion
> > console.log(
> >   re.exec("foo")[0] === 'foo')
> > // yes would be inappropriate, but yes|maybe would be because
> >
> > // This variant uses the d
> > console.log(
> >   re.exec("food")[0] === 'food')
> > // and yes|maybe would be appropriate here since
> >
> > console.log(
> >   re.exec("foods")[0] === 'foods')
> >
>
> This particular scenario would not matter to me directly because all I
> need is a "could this match now or potentially later". The optional
> end would be fine, since I'd have the invariant that when I check each
> child, I'll be adding a space along with the next test's name anyways
> (and thus won't have a `d` to worry about).
>
> As for whether it should consider it "ended", I think that's something
> that could probably be spec'd out in a proposal repo, and I doubt
> that'd be a blocker for stage 1 (that's typically a stage 2 concern).


Fwiw, it sounds like a fine idea to me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Partial regexp matching

[Mike Samuel]

On Mon, Feb 19, 2018 at 11:43 AM, Isiah Meadows 
wrote:

> Yes, and I specifically want the conservative variant - I'd want a
> "maybe" for "foo" in that example.
>
> (For context, my test framework determines *while running a test*
> whether that test has children, and checks whether to allocate them
> when defining them. For me, I only need "yes/maybe" and "no", but
> splitting "yes" and "maybe" could be beneficial to others.)
>

Ok, so you're trying to decide whether to prune a graph search based
on a regexp that classifies paths through the graph.

We can't base a distinction between yes and maybe on whether a
zero-width $ assertion is triggered if there are paths to completion
that do not pass through that assertion.


const re = /^foo($|d).?/
// This variant uses the $ assertionconsole.log(
  re.exec("foo")[0] === 'foo')// yes would be inappropriate, but
yes|maybe would be because
// This variant uses the dconsole.log(
  re.exec("food")[0] === 'food')// and yes|maybe would be appropriate here since
console.log(
  re.exec("foods")[0] === 'foods')



So IIUC, the yes/maybe distinction could be based on a bit that is set on
success of a $ assertion and erased on exit from any of ( ...|... , ...? ,
...* , ...{0,...} , (?!...) ).
That only works when we know that the start of the match is stable though
because

const re = /foo$/
console.log(
  re.test('foo'))console.log(
  re.test('foofoo'))



It would hold for the common case /^...$/ but in that case you already know
the answer, and can test it at runtime by testing myRegExp.source matches a
meta-pattern like /^\^([^\\]|\\[\s\s])*\$$/.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Mon, Feb 19, 2018 at 11:50 AM, Aleksander Efremov 
wrote:

> In my first example you can found what I mean. There not only function.
> Just instead of that function can be black box results which we must check
> on assignment to const.
>

Are you referring to the use of PrimitiveNumber in `const c:
PrimitiveNumber = sum(1, 2);` ?
When treating sum as a black box, you can't rely on it to check its
{pre,post}condiitons, so you need an additional guard on the const
initializer?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Mon, Feb 19, 2018 at 9:25 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Mon, Feb 19, 2018 at 1:59 PM, Александр Ефремов 
> wrote:
>
> When [decorators][1] land, provided they land with a means of [decorating
> functions][2] (either as part of that proposal or as a follow-on), that
> would do the job, wouldn't it? Using your `sum` example:
>
> ```js
> @rttc(PrimitiveNumber, PrimitiveNumber)
> const sum = (a, b) => {
> return a + b;
> };
> ```
>
> ...where `rttc` ("runtime type check") decorates the function such that it
> does runtime validation of the type of the arguments supplied. (See the
> issue referenced in the second link above for why I used a function
> expression rather than declration for `sum`.)
>

+1 for a single mechanisms that enables not just preconditions, but
postconditions.

Decorators could also make it super-easy to do things like deprecation
warnings and memoization a la python [1]

[1] https://wiki.python.org/moin/PythonDecoratorLibrary#Memoize
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Partial regexp matching

[Mike Samuel]

So you want an API that can indicate "might match if there were more input"?

Is it ok if it is conservative?  I.e. it won't incorrectly say "definitely
wouldn't match given more input" but could tolerate errors the other way?

For example, /^food(?!)/ would have to say no for "foop" but we might
tolerate a maybe for "foo".


On Feb 15, 2018 8:12 AM, "Isiah Meadows"  wrote:

I've been working on a test framework, and I'd love to implement
support for matching tests via regexp-based selectors. It's basically
impossible without the ability to execute a regular expression and
test if it matched positively, negatively, or incompletely.

- If the regexp does not have an end marker, this, of course, can't
generate a *negative* match, only positive/incomplete ones.
- If the regexp *does* have an end marker, this is where I actually
need native support. (This is especially true if group references get
involved.)

Any chance this could get added?

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
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 to add symbol: "hasInstanceStrict"

[Mike Samuel]

Must hasInstanceStrict's parameter remain untyped for a guard to complete
or is there a top type with an unguarded hasInstanceStrict that these
checks bottom out on?

"has" to my ear sounds like it should return a boolean.  Maybe "require."



On Feb 18, 2018 11:30 AM, "Aleksander Efremov"  wrote:

It’s attempt to provide intermediate layer for implementation of runtime
type checking.

```
class PrimitiveNumber {
static [Symbol.hasInstanceStrict](x) {
if (typeof x !== ’number’) {
throw new TypeError(‘Invalid type’);
}
}
}

function sum(a: PrimitiveNumber, b: PrimitiveNumber) {
return a + b;
}

const c: PrimitiveNumber = sum(1, 2);
```

I.e. when appears assignment of variable (const) if then follows `:
` then JS runtime must to call method `static
[Symbol.hasInstanceStrict](x)` and transfer to there assignable value.

___
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: Suggestion: Infix operators/functions

[Mike Samuel]

On Fri, Feb 2, 2018 at 10:58 AM, Mike Samuel <mikesam...@gmail.com> wrote:

> How would this affect ASI?
>
> a  // no semicolon inserted since '+' is an infix operator
> +b
>
> a  // semicolon inserted since '!' is not an infix operator
> !b
>
> but what about
>
> function '!'(a, b) { ... }
> // now '!' is both an infix and a prefix operator
>
> a  // is a semicolon inserted?
> !b
>

The relevant portion of the spec is 11.9.1 Rules of Automatic Semicolon
Insertion
<http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>
:
"""
   There are three basic rules of semicolon insertion:
   ...
   1. When, as a Script or Module is parsed from left to right, a token
(called the
   offending token) is encountered that *is not allowed by any
production* of the
  grammar, then a semicolon is automatically inserted before the
offending token
  if one or more of the following conditions is true:

  *  The offending token is separated from the previous token by at
least one
  LineTerminator.

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

Re: Suggestion: Infix operators/functions

[Mike Samuel]

How would this affect ASI?

a  // no semicolon inserted since '+' is an infix operator
+b

a  // semicolon inserted since '!' is not an infix operator
!b

but what about

function '!'(a, b) { ... }
// now '!' is both an infix and a prefix operator

a  // is a semicolon inserted?
!b






On Fri, Feb 2, 2018 at 6:55 AM, Thomas Grainger  wrote:

> I'm porting this from the TypeScript issue tracker, original from:
> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
>
> Since it's very unlikely that the extension methods will ever be
> implemented [in a call-site-rewrite
> manner](https://github.com/Microsoft/TypeScript/issues/9#iss
> uecomment-74302592),
> please consider adding infix operators to enable writing in functional
> style similarly to what can be done in Haskell:
>
> Monoids
>
> ```js
>
> function '+' (left, right) {
>return left.concat(right);
> }
>
> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
>
> ```
>
> Monads
>
> ```js
> function '>>=' (promise, bind) {
>return promise.then(bind);
> }
> $.get('/get') '>>=' x => $.post('/save', x + 1)
> ```
>
> Functors
>
> ```js
> function '.' (inner, outer) {
>return function(value: a) : c {
>   return outer(inner(value))
>}
> }
>
> function f(x) { }
> function g(y) { }
> (f '.' g)(x); // z
> ```
>
>
>
> Thomas Grainger
>
> ___
> 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: Map#assign

[Mike Samuel]

On Thu, Jan 18, 2018 at 12:37 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Thu, Jan 18, 2018 at 5:28 PM, 森建  wrote:
> >
> > This code is redundant. I just want to write
> > `mapA.assign(mapB, mapC);`.
>
> FWIW, it would be more in keeping with `Object.assign` if it were on `Map`
> rather than `Map.prototype`. E.g., you'd write the code above like this:
>

What if, instead of a variety of assign methods, we respeced
Object.assign to do this given a Map as the left-value?

If Object.assign sees a "set" method of length 2, then it stores
obj.set.bind(obj)
and uses that rather than assigns to fields.

Two points of potential controversy:

- if an array is on the right, do we pass string or integer keys
  to the bound setter?
- if we allow Maps on the right, we could allow WeakMaps
  on the left.  Users might assume that WeakMap could then
  be used on the right.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Bookmarks of PDF Version ECMAScript Standard Are Broken

[Mike Samuel]

I think the spec is generated via https://github.com/bterlson/ecmarkup
from HTML files like https://github.com/tc39/ecma402/tree/master/spec

Maybe it'd be worth filing a bug on ecmarkup since that's probably the
piece that generates the TOC in the generated PDF.

On Wed, Jan 3, 2018 at 10:22 PM, Timothy Liu <tim...@outlook.com> wrote:
> Thanks! Mike:
>
> I know the HTML version works perfectly well :)
> Usually, I do my writing work in a low network speed environment, say 
> Starbucks.
>
> Best Regards,
> Tim
>
>
> -Original Message-
> From: Mike Samuel [mailto:mikesam...@gmail.com]
> Sent: Wednesday, January 3, 2018 7:19 PM
> To: Timothy Liu <tim...@outlook.com>
> Subject: Re: The Bookmarks of PDF Version ECMAScript Standard Are Broken
>
> Ok.  The "Table of Contents" links don't work for me in MacOS Preview but the 
> equivalent in the left sidebar on the HTML version do :
> http://www.ecma-international.org/ecma-262/8.0/
>
> On Wed, Jan 3, 2018 at 9:53 PM, Timothy Liu <tim...@outlook.com> wrote:
>> Thanks! Mike:
>>
>> I mean the bookmarks in the navigation panel.
>> Here's the Adobe user manual.
>> https://helpx.adobe.com/acrobat/using/page-thumbnails-bookmarks-pdfs.h
>> tml Please scroll down to the " About bookmarks" section.
>>
>> Best Regards,
>> Tim
>>
>>
>> -Original Message-
>> From: Mike Samuel [mailto:mikesam...@gmail.com]
>> Sent: Wednesday, January 3, 2018 6:50 PM
>> To: Timothy Liu <tim...@outlook.com>
>> Subject: Re: The Bookmarks of PDF Version ECMAScript Standard Are
>> Broken
>>
>> Ok.  I think we're looking at the same document.
>>
>> What do you mean by "bookmark?"
>>
>> The links in the table of contents work for me, and I tried a couple other 
>> links which worked.
>> Clicking on "%Array%" under 6.1.7.4 scrolled to something that looked 
>> relevant.
>>
>>
>> On Wed, Jan 3, 2018 at 9:45 PM, Timothy Liu <tim...@outlook.com> wrote:
>>> Hi Mike,
>>>
>>> Thanks for the quick response!
>>> The file I downloaded is: ECMA Homepage -> Standards -> ECMA-262 -> 
>>> ECMA-262.pdf.
>>> The URL is:
>>> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.
>>> pdf
>>>
>>> Best Regards,
>>> Tim
>>>
>>> -Original Message-
>>> From: Mike Samuel [mailto:mikesam...@gmail.com]
>>> Sent: Wednesday, January 3, 2018 6:40 PM
>>> To: Timothy Liu <tim...@outlook.com>
>>> Subject: Re: The Bookmarks of PDF Version ECMAScript Standard Are
>>> Broken
>>>
>>> Which pdf are you trying?
>>>
>>> https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-26
>>> 2
>>> .pdf
>>> works for me
>>> in Chrome's builtin PDF viewer.  The cover page says
>>> "ECMA-262 8th Edition / June 2017 ECMAScript® 2017 Language Specification"
>>>
>>> On Wed, Jan 3, 2018 at 9:33 PM, Timothy Liu <tim...@outlook.com> wrote:
>>>> Dear ES-Discuss:
>>>>
>>>>
>>>>
>>>> First of all, appreciate your hard work which made
>>>> ECMAScript/JavaScript a first-class programming language on the Earth.
>>>>
>>>> I’m a technical writer. Recently, I’m going to initial a book
>>>> writing for ES8. After I download the ECMA-262.pdf, I found the
>>>> bookmarks of the PDF file are now working. I tried both in the
>>>> browser and Acrobat Reader. It seems the older version PDF files have the 
>>>> same issue.
>>>>
>>>> Would you like to take a look and do a quick fix? It is very
>>>> inconvenient reading without bookmark navigation.
>>>>
>>>>
>>>>
>>>> Best Regards, Happy New Year!
>>>>
>>>> Timothy
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> 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: Partial Expression proposal

[Mike Samuel]

Maybe take a shortish but non-trivial piece of code, rewrite it to use the
proposed syntax.  Then explain what about the rewritten code makes it
clearer, more maintainable, etc. than the code before.


On Dec 28, 2017 2:44 PM, "Tamás Halasi" <trusted.tom...@gmail.com> wrote:

How could we find out whether the feature is desirable? Just find a lot of
use cases? Or write a *Purpose* paragraph?

2017-12-28 20:29 GMT+01:00 Mike Samuel <mikesam...@gmail.com>:

> On Thu, Dec 28, 2017 at 12:10 PM, Tamás Halasi <trusted.tom...@gmail.com>
> wrote:
> > Damn.
> > I wonder why is that useful.
> > But whatever.
> >
> > What symbol do you think would be the best?
> > A binary operator have to have an expression at its left side, so *, /,
> %,
> >>, <, &, ^ or | might be good.
>
> If we focused on whether the feature set is desirable given the
> balance of existing features and use cases,
> we could later bikeshed after we're informed enough to weigh the
> benefit vs cost of consuming available punctuation.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Partial Expression proposal

[Mike Samuel]

On Thu, Dec 28, 2017 at 12:10 PM, Tamás Halasi  wrote:
> Damn.
> I wonder why is that useful.
> But whatever.
>
> What symbol do you think would be the best?
> A binary operator have to have an expression at its left side, so *, /, %,
>>, <, &, ^ or | might be good.

If we focused on whether the feature set is desirable given the
balance of existing features and use cases,
we could later bikeshed after we're informed enough to weigh the
benefit vs cost of consuming available punctuation.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Partial Expression proposal

[Mike Samuel]

On Wed, Dec 27, 2017 at 1:43 PM, Tamás Halasi  wrote:
> It's like the functional application proposal, just for any expression. It
> would improve

This sentence ends abruptly.  What would this proposal improve?

> See the proposal:
> https://github.com/trustedtomato/proposal-partial-expression
>
> What are your thoughts?

Is this lambdas with De Bruijn indices?

The proposal says
"""The ? token is used in conditional expressions, but its not
ambiguous, because in this proposal, a ? cannot follow an expression,
while in a conditional expression it always does."""

You have ?? and ??? for referring to outer layers.  Is there no ambiguity there?

  ? ? ? : ?

may not be ambiguous, but without the spaces it would require
lookahead to the ":" to resolve ambiguity,
unless the tokenizer starts to consume maximal runs of question marks.



> ___
> 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: The JavaScript character wall

[Mike Samuel]

On Thu, Dec 14, 2017 at 5:39 AM, Gareth Heyes 
wrote:

> Hi all
>
> So many years ago on the sla.ckers forums Yosuke Hasegawa posted
> non-alphanumeric JavaScript. We then worked together to find out the
> smallest possible charset required to execute non-alphanumeric JavaScript.
> We all broke the wall multiple times and Mario Heiderich found the
> character limit was 6 characters. It could not be broken.
>

Background for other es-discussers,
https://news.ycombinator.com/item?id=4370098
links to Yosuke Hasegawa's various obfuscator demos, and IIRC,
Mario's argument about the limit is in "Web Application Obfuscation."

Gareth, is there a working 6 character contender?
That ycombinator thread notes that utf-8.jp/public/jsfuck.html was broken
when the spec
changed the semantics of [].sort.call() so that it no longer returns the
global object.




> Enter the pipeline operator and Masato Kinugawa. He found using the
> specified pipeline operator he could break the wall :O. Check it out it is
> awesome:
>
> https://speakerdeck.com/masatokinugawa/shibuya-dot-xss-techtalk-number-10
>

Looks like somebody has already put together a demo page for it:
https://syllab.fr/projets/experiments/xcharsjs/5chars.pipeline.html


> I really hope the pipeline operator gets specified and implemented by the
> various browsers because breaking the wall is a fantastic achievement and
> it's useful too.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Identifying pure (or "pure within a scope") JavaScript functions?

[Mike Samuel]

On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent  wrote:
> OK, OK, clearly, pure functions are a fantasy in JavaScript.  Once again,
a
> great idea and a lengthy essay of a post falls to a real-world situation.
> Nuts.
>
> What if there's a middle ground?  In the case I was originally talking
> about, the developer calling on my membrane controls how the callback
> function executes.  I just want to ensure that, when the callback is
passed
> controlled and trusted arguments (including possibly "this"), the function
> doesn't refer to anything outside those arguments and local variables
> derived from them.  Is that reasonable to ask for?

Do you want the same kind of thing that Joe-E provides for Java?
http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf
> Proving that particular methods within a code base are functionally
> pure—deterministic and side-effect free—would aid verification of
> security properties including function invertibility, reproducibility of
> computation, and safety of untrusted code execution. Until now it
> has not been possible to automatically prove a method is functionally
> pure within a high-level imperative language in wide use, such as Java.

Nothing that is well established really fits for JS, but there are some
proposals and experimental features.

The frozen realms proposal
 might
also be of interest.
> Though initially separate, realms can be brought into intimate
> contact with each other via host-provided APIs.

In a browser setting, WebAssembly
 might be
your best bet.
WebAssembly.instantiate(module,importsObj) runs a sandboxed binary
that has access to functions and values in an importsObject, and
takes care to prevent following backwards edges in the object graph
(__proto__, .constructor and the like).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax is the Problem

[Mike Samuel]

On Sun, Nov 5, 2017 at 8:22 AM, Michael Lewis  wrote:

> Raul-Sebastian Mihăilă just made a post here about some mixin syntax.  I
> didn't read it (sorry).
>
> But, it got me thinking about a concept I've been thinking for years:  *syntax
> is the problem*, and there's a better solution.
>
> If you define syntax as a human <--> computer language (a human-readable
> and computer-readable form of text), you necessarily need a very strictly
> defined syntax.  One missing curly, and you're f'd.
>
> Duh, we all know this.  Hang onto your pants for a second, let's explore
> an alternative.
>
> What if we edited scripts more directly in AST form (abstract syntax
> tree).  Developers could implement their own UI to manipulate this AST.
> There are many, many benefits to this, I'll get to in a second.
>

Assuming you're bringing this to TC39 because you think the committee can
contribute to this effort,
there seem to be a few separable questions here:

1. Would there be benefit to standardizing an AST?
2. Would developers benefit from being able to manipulate ASTs?
3. Should TC39 organize efforts to realign JS development around AST
manipulation?

TC39 has already debated some AST proposals.  You could add your use case
to those.
You really don't need them though.  Babel didn't wait.

I'm unsure why manipulating ASTs is a benefit.  It seems tools that
manipulate ASTs can simply have a parser tacked on the front and a
serializer tacked on the back and manipulate text files.  This is what the
refactoring tools in IDEs like Eclipse do.

Even if these tools are wildly popular, the syntax won't be going away
though.  Backwards-compatibility requires EcmaScript be embeddable in HTML,
SVG and a number of other textual formats.

It seems to me, that TC39 need not be involved in the process of specing
tools for manipulating ASTs and even if TC39 gives a full-throated
endorsement to such tools, it would still have to spec syntax.


First, let's remember what everyone in the JS community is doing right
> now:  running their code through transpilers.  (I refuse to do this, that's
> why I'm unemployed - I strongly dislike the concept).  What is a
> transpiler?  It's an unofficial middleman that interprets the syntax,
> converts it to an AST, performs transformations, and then returns the AST
> to syntax form.
>

Suddenly, scripting in AST form doesn't sound so crazy.
>

How does (developers would be better off authoring ASTs) follow from (tools
like transpilers use ASTs internally)?

Clearly, you wouldn't be writing JSON.  We would be using a GUI to create
> the AST.  And this is the greatest benefit: moving away from *syntax*,
> and moving to a GUI.
>

There's a whole literature on end-user programming that others have
referenced.  None of it has caught on with professional developers.  How
are the GUIs you propose different from past efforts?

Most Lisp syntaxes map directly to the AST with just a bit of syntactic
sugar.   There are also plenty of fine GUIs.  You can have an awesome GUI
for building an AST and still have syntax so that you can review code on
long plane trips.


> Then, instead of babel plugins that provide alternative *syntax*, you
> could have plugins that provide alternative *experiences.*
>
> What would designing a class look like, if using a GUI?
>
>1. Click [ create new class ]
>2. Click [ add new method ]
>
> I can do this in Eclipse.  Most of the time I just type "class."
There seems little benefit to a GUI that replaces repetitive typing with
repetitive clicking,
and I'm not familiar enough with the terms you use to know why I would want
to plug-in experiences.


> Or, click the [ extend ] button next to an existing class...
>
> This is the future.
>

This is an odd choice of tense.


> I have to go eat breakfast, but I'd love to discuss this future if anyone
> is interested...
>

I hope you had an awesome breakfast!
Maybe someday we'll all Click [ eat brekkie ].
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss