I have seen people write code like (mix javascript and some templating):

    <script>
    var prefs = <%= user_prefs.to_spec_conforming_json() %>;
    ...

Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?

No, you would break the evaluation of json as javascript in old versions of IE.

Use a real parser already.

    callback(JSON.parse('{ "key":"value" }'))

[1] http://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing

[2] http://caniuse.com/cors

Why do people still care about old versions of IE?

Developing nations have a tendency to not use the latest and greatest. If reaching them is important for you/your product then you have to keep tracking this stuff.

Attention developing nations: Chromium and Firefox are completely foss. No excuse, unless you don't have an internet connection.

In which case, what do you need a web browser for?

This is based on my experience at UPS which used a single machine using IE6 and some form of web app to control start up and shut down procedures, or something to that effect. It had no Internet connection, only LAN I believe.

I did ask myself this question too and it does seem peculiar. After some thought, my only guess is the above!

South Korea is a huge example of this. When online banking first came to market, the only way to do it legally in South Korea was through ActiveX controls embedded in Internet Explorer because they had specific encryption requirements in the 1990s versus what IE or other browsers supported natively.

Even as recent as last year [1] it was a big deal in elections, with at least one candidate promising to end the legal requirements and allow banks to enter the modern age of browsers.

[1] http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to...

(There's also the whole "they get infected with everything under the sun and make the rest of us deal with them", but that's not a visual issue.)

(Meta: Why have any conversation on an HN back-channel when there are comments open at the source?)

Specially now that giving in to G+ means showing up on ads.

The original json.js file from json.org had this copyright and license:

  Copyright (c) 2005 JSON.org
  
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:
  
  The Software shall be used for Good, not Evil.
  
  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.

This was a standard MIT license with one change:

"This license uses the Expat [MIT] license as a base, but adds a clause mandating: “The Software shall be used for Good, not Evil.” This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforcible [sic], but we cannot presume that. Thus, the license is nonfree."

http://www.gnu.org/licenses/license-list.html#JSON

However, the current versions of json.js and json2.js on GitHub contain only this public domain dedication and disclaimer:

  Public Domain.

  NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.

So it's no longer an issue. You can feel free to use json2.js for good or evil.

For context, after Mr. Crockford gave IBM permission to use the license without the clause a few open source projects (mine included), also asked, and Mr. Crockford's response was a bit over the top-

> I released to free use for all with the only condition that it not be used for evil. If that is unacceptable to you, then you may not use it. Your options are to bend to the pro-evil fanatics, or to find a more reasonable hosting solution.

It's nice to see he's become a bit more reasonable.

That last bit is the tough one. Some people define homosexuality as evil, others define it with things like women going to school. DC obviously isn't that extreme, but he's using a term in a legal setting that can be defined by different people in completely different ways. This makes it so no business can use this code, and even things like open source projects should be extremely weary.

What this essentially did was allow Douglas Crockford to claim that he open sourced his code while actually keeping it closed and forcing people to go through him if they actually wanted to legally use it. While I'm sure plenty of people use it regardless, there's nothing preventing DC from simply stepping in and forcing them to stop. If he had used a real open source license that would be impossible, but as it stands all he has to do is walk over and say "I consider that evil" and you need to rip his library out.

This isn't just hypothetical. I had to remove code from an open source project because of this. It's why I wrote JShrink, as an open source replacement for the JSMin libary. https://github.com/tedivm/JShrink

I pay US taxes and the US government kills people around the world. They also subsidise farmers which puts others around the world at a disadvantage contributing to poorer economic circumstances for them. The US incarcerates a large number of people. If the project benefited me or anyone else paying US taxes, then hasn't it benefited the US government, and hence evil?

Vote with your tax dollars.

As others have pointed out, this is just the license on one implementation, not the spec, so it's not really as big a deal.

Consider it an "anti-'people who take licensing seriously' license".

Yes, a million dollars.

We have testimony in this very thread from tedivm who had to rewrite JSMin because of this laugh. That has to have been a multi-thousand-dollar project right there.

Think about the time IBM alone spent on this issue. Developers, managers, lawyers. Five grand? Easily. Maybe more.

Play out this scenario a few hundred times across the globe, and there's your million dollars.

The problem is, when you have a laugh at somebody's expense, it isn't free. It comes at somebody's expense.

And ultimately the laugh wasn't worth a penny, because the license was finally changed to a true open source (public domain) license.

Bullshit. You are not entitled to any particular piece of software, not a single thing is taken from you when you find a software license intolerable. So something isn't licensed how you like... so what? Negotiate new terms, or move on with your life and use something else.

Bitching that something is 'Do no evil' licensed so that you cannot use it is no better than bitching that something is GPLv3'd so you cannot use it, or something is only licensed under proprietary licenses so you cannot use it.

People getting upset over licenses that render software unenjoyable to themselves is the sort of entitled bullshit that makes me want to seek out the most obnoxious license possible. Somebody should make a AGPLv3/Do no Evil hybrid license and write some mildly useful piece of software to use it for, then refuse to duel-license for any earthly fee. That should make some people squirm.

I made a simple economic statement, and I stand by it: The "shall be used for Good, not Evil" episode had a very real cost to it.

People did exactly what you say: negotiated new terms (like IBM) or moved on with their lives and found or wrote something else (like tedivm).

Sure, my million dollar estimate could be way off. But the cost wasn't a small one, and it wasn't just money.

Consider the many developers who saw what looked like an ordinary MIT license and didn't notice the change in the middle or understand the problem with it - maybe thought it was just a cute sentiment. So they made plans and commitments based on being able to use the code. Then their managers made commitments to their bosses and customers. And finally, they all got shot down by Legal and had to scramble to find another solution.

This cost people time and reputation.

GPL and proprietary licenses are different, because they would never be mistaken for the MIT license. A developer could easily find out if they were on the company's approved list or not. And as you know, the GPL itself forbids any changes to its text. So the same problem would be much less likely to happen with those kinds of licenses.

Some developer that cannot be bothered to read and understand a license does not somehow mean that Crockford is "costing" them anything. These hypothetical people fucked up, and they should fucking responsibility for themselves for god's sake. What a pathetic dodge.

Do you also think that NASA has "cost" the North Korean space program anything by not freely giving away rocket designs? Entitled to the absurd.

In return, you have sworn at me, called my argument "a pathetic dodge" and "entitled to the absurd," and came very close to putting words in my mouth with the North Korean strawman.

That makes it difficult to have a polite discussion, but I do want to clarify one thing.

I didn't say that Crockford was responsible for the economic cost of the old json.js license. Of course he had every right to release his code under any license he chose.

I'm simply saying that there was a cost, compared with the situation that would have existed had the code been originally released with a standard MIT license. People spent time and money that they wouldn't have if that had been the case.

Since "cost" seems to be a loaded word here, let me put it another way. It should be clear that there would have been a benefit to the world if the original json.js, JSMin, etc. had used a standard MIT license, because many more people could have used the code. That benefit was lost because of the "Evil" clause.

And, to his credit, I think Crockford eventually realized this when he re-released the code with a pure public domain dedication.

The NSA breathes a sigh of relief.

That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.

The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.

If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.

Wrong! Since ECMAScript 5 there is a single, standard format that all browsers will try to parse first and can predictably output: ISO 8601.

  --
  [02:49:29.621] (new Date()).toISOString()
  [02:49:29.623] "2013-10-12T01:49:29.623Z"
  --
  [02:49:40.233] JSON.stringify(new Date())
  [02:49:40.245] ""2013-10-12T01:49:40.246Z""

In any case, my general point still stands: dates are the only "data" type (i.e. not a function, regex, etc.) which is not supported by JSON. So even if there were a usable universal serialization format, you'd still need to post-process the results of the JSON parser to convert the strings into dates.

I swear the moment I glanced at the title I thought it was an error message that someone accidentally posted.

B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.

C) You can't .join data streams without buffering, which defeats the purpose.

D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.

E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.

... The irony of yaml being human and version control friendly but including massive amounts of serialization mechanism vs. json being for data exchange and having extremely rudimentary serialization features aside.

Why JSON at all if you don't care about reading it?

I'm not against Protobuf, BSON, SPDY and the likes, my argument is just that JSON is used over binary formats only because it's readable.

I should like to visit that world one day.

> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.

Sure, it's easy to read and write by humans, because it's simple, but that's not what it is for (which is what I was disagreeing with). Humans communicate better using a natural language, not JSON, as evidenced by the fact that both our comments are in English, not JSON.

And 'easy' is relative anyway. Some of my users have to write JSON (they're not developers). It would be much easier for them if the UI had built the JSON for them, while they click on buttons.

In which language can't you do array.join(",")? You can even do that in Java with one of the myriad of string libraries. I haven't hand-coded joins since (at least) six or seven years.

It is, however, wrong to say it's terrible because of laziness.

I still don't get around how `this` can be so broken.

Honest question: Such as?

Prototypical inheritance may have gotten much more exposure via JS, but I'm not overly impressed with it, and I hardly think it makes up for the rest of the language.

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }
        { PropertyNameAndValueList , }

For instance, there's a standard for measuring computer equipment in controlled rooms: http://www.ecma-international.org/publications/files/ECMA-ST...

And here's an important one, DVD-RAM discs: http://www.ecma-international.org/publications/files/ECMA-ST... and their cases: http://www.ecma-international.org/publications/files/ECMA-ST...

Plus, NFC: http://www.ecma-international.org/publications/files/ECMA-ST...

It's all new to me!

eww, UTF-16 surrogate pairs. Die, die, die, you scourge. (Yes, I've been working with the win32 api lately, which was designed for UCS2/UTF-16).

when has 16 bit anything been a good idea, really. TCP port ranges, looking at you too.

You don't have to escape unicode. If you want to just use Unicode and encode as UTF-8 then go nuts.

This is valid JSON:

{ "äöü": "大家好", "clef": "𝄞" }

Python has an upper case \UXXXXXXXX literal that seems a lot cleaner.

A better solution is to use YAML for things like configuration files. It's more pleasant for a human than JSON would be even if it supported comments, and there are nice parsing libraries available for every popular language.

Ultimately, it makes JSON unsuitable for configuration files (there are other reasons for that, to be fair, like over-verboseness)

Also, I hope, trailing commas and binary types.

As for adding comments to the spec--again, the idea is to prevent shadow information showing up that isn't obvious to a conformant parser.

If you give people the ability to smuggle data in comments, that's exactly what they'll do. At least this way people know that what they're doing isn't "to spec" and that their sneaky parsers are not following the rules.

The reasoning is also incredibly short-sighted.

This is probably going to sound like asking someone to catch sunlight in a teacup, but wouldn't it have been more productive to stress the importance of syntax adherence and consistency rather than remove it altogether? There's really nothing stopping someone from abusing the rest of JSON for silly things so leaving comments out seems a bit redundant.

    JSON.stringify(JSON.parse(foo))

If you go with the first option, you'll inevitably run into a scenario where you have a document like this contrived example:

    {
      // this is the first ever version!
      "version": "1.0.0"
    }

    {
      // this is the first ever version!
      "version": "2.0.0"
    }

If you go with the second option, you destroy all comments whenever you write data back to the file, so they can be deemed temporary at best.

What benefit do you actually get from having comments in either scenario?

Supporting comments makes JSON more convenient to use in more situations, and it doesn't prevent you from doing anything you can do now.

And this may even encourage people into separating the data payload from the metadata, who knows?

Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.

I don't see how this is a "no true scotsman". Maybe a non-true "no true scotsman"?

> If comments were added to the spec then normal tools would support them just fine.

Plain comments, sure. Comments with custom annotations in them, not so much.

> Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.

Maybe this wasn't such a good idea in the first place?

https://news.ycombinator.com/item?id=6534318

Is it too late for edn? https://github.com/edn-format/edn

Symbols that aren't "strings" are kinda neat too, and you get downright attached to arbitrary key-value mappings once you have them.

I can't imagine why they changed the name, given that the forward slash and the solidus are not interchangeable. http://www.fileformat.info/info/unicode/char/5c/index.htm

    <span style="font-size:125%"><span class="Unicode">\</span></span>

EDIT: Actually, this explanation is enlightening: http://en.wikipedia.org/wiki/Slash_(punctuation)#Encoding

Considering that DPI devices are already sold to parse json-desribed protocols dynamically, I think you are a bit uninformed about my statement. It is not hypothetical.

If you want security, you need encryption, not obscure encoding formats.

I accept "The Software shall be used for Good, not Evil." is amusing and "good" but must cause difficulties for people wanting to package with other software under standard licenses.