Talk:JSON

From Wikipedia, the free encyclopedia

Contents

[edit] External link to BarracudaDrive and JSON security

I have re-introduced the external link removed by Sleepyhead81. For what reason did you remove this link? This is a good example of how to use JSON. I changed the link to the technical information page for BarracudaDrive.

I do not agree with the security considerations when using JSON in a browser: "in practice, however, security and other considerations generally preclude using eval"

This is only a problem if doing cross site scripting, which is normally not allowed anyway. A DHTML application is loaded on demand from a server and communicates with the origin server i.e. you cannot trust the DHTML application itself if you cannot trust the JSON returned form the server as it originates from the same server. How many users do "view source" and study the JavaScript code before trusting a DHTML application.

What I am trying to say is that any code loaded on demand, including a JSON parser cannot be trusted. It is for this reason no difference between using eval and using a JSON JavaScript parser when it comes to security.

I removed it because I consider is a spamlink. It is an example, but there are heaps of examples. Adding one example will only attract other links which has been the case with other similar articles. --Sleepyhead 08:20, 15 February 2006 (UTC)
That is an opinion.
BarracudaDrive is designed to be an example and a showcase for what is possible with HTTP, AJAX, etc. The search is a particular good example as it shows how much faster asynchronous RPC can be made using JSON than with SOAP. BarracudaDrive is also a good platform for users that are interested in experimenting with the JSON server API. Personally, I do not think you should remove any links. What gives you the right to act as the police and censor what other readers may find useful? There is already a lot of spam in the JSON article and many statements that are not necessarily correct.

[edit] JSON and YAML

Can anyone compare JSON and YAML?


Ruby on Rails NPOV?: Right now, part of the article reads:

  • YAML, the data serialization language favored by the Ruby programming language...
  • ...makes for quite elegant integrations between Rails and Javascript.

I was unfamiliar with YAML, and this gave me the false impression that it was a "Ruby thing". After poking around on YAML.ORG, I see that it's not Ruby specific at all. YAML.ORG's front page makes mention of "scripting languages such as Perl and Python" but Ruby is not mentioned up front (by name). Mentioning Ruby on Rails in this context doesn't look very NPOV. If there's a good NPOV reason that Ruby and RoR should be mentioned in this JSON article, please let us know. If not, I'm going to pull those references next week (unless someone does it before I do). -Gamol 05:01, 3 December 2005 (UTC)

It seems to me that you've probably misunderstood the article. As I understand it, the standard Ruby libraries fully support YAML, and furthermore that this can be said for very few if any other comparable languages. If it is true (or if it later becomes true) of some other comparable language, then the article can accordingly be modified. In the meantime, therefore, it seems to me appropriate to retain the reference, given that JSON is a subset of YAML. Peak 06:55, 3 December 2005 (UTC)
I don't think I've misunderstood the article as it is written. After doing some reading, I have a recommendation I feel quite sure about.
As I understand it, Ruby has used YAML as its "de facto serialization format .... since 1.8" (YAML wiki ref). Now since YAML is (by lucky coincidence) is a superset of JSON, Ruby programmers can use JSON almost as if it's a native data type. This is very cool and--I agree--worthy of mention. The problem I see now is that the article introduces and defines YAML in terms of its relationship to Ruby. I still feel that this is misleading. YAML.ORG and Wikipedia's own YAML article don't do this because, although it's integrated nicely with Ruby, YAML is not Ruby specific.
I think it's more appropriate to define YAML in terms of its relationship to JSON. Then, mention the Ruby integration afterwards. Give this a read:
YAML, another data serialization and lightweight markup language, is a superset of JSON. YAML can be thought of as JSON with a handful of extended data types. JSON is much easier to parse, though[1]. Although coincidental, this relationship means that YAML tools can process JSON data. The Ruby language, which uses YAML as its built-in serialization format, can handle JSON like a native data type.
Now I'm not a Ruby programmer (yet), so I'm not sure my use of "native data type" is wholly appropriate but I think the paragraph should be changed so that it reads something like the above text.-Gamol 13:50, 3 December 2005 (UTC)
Perhaps you missed a small change I made in the intro, that introduces YAML as an extension of JSON. Anyway, your basic proposal is fine, but perhaps the wording would benefit from a bit more research. In the meantime, please consider this:
Some of the limitations of JSON are addressed by YAML, which is a superset of JSON. Although JSON is significantly simpler than YAML[1], YAML is still considered lightweight. The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON.
By the way, I am not sure that YAML is usefully considered a markup language (They don't call it 'YAML ain't Markup Language' for nothing :-) Perhaps the articles on JSON and YAML can be strengthened by explaining their superiority as "data interchange" languages compared to vanilla XML.Peak 19:26, 3 December 2005 (UTC)
P.S. I just noticed that the article List of lightweight markup languages states categorically that JSON and YAML are not markup languages. Perhaps the point of confusion is the difference between being a ML versus being used as a ML? Peak 20:39, 3 December 2005 (UTC)
Hmm, I got that "lightweight markup language" part from the (apparently) underdeveloped YAML article itself. Knowing this, I would have written "lightweight serialization syntax". I liked your last paragraph much better than the one in the article so I made that change. -Gamol 11:01, 6 December 2005 (UTC)

I would like to see the YAML/JSON relationship fleshed out in the future. Right now, readers can see that YAML is a superset of JSON and reasonably conclude that YAML was based on JSON (when in fact, the superset/subset relationship is coincidental). Also, some readers might miss the implications of this. I think it would be helpful to spell out that, because of this relationship, any YAML parser can be used to deal with JSON data structures (because strictly speaking, they're JSON parsers too). -Gamol 11:01, 6 December 2005 (UTC)

No-one has remedied any of the problems with this section. As it is now (Sept 2006), it is poorly written. In fact it almost makes no sense, because it says "The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON with particular ease" without ever mentioning the subset/superset relationship. Nothing in the section, or elsewhere in the article, bears out the "therefore" part of that sentence.

To maintian a neutral POV this article needs to have the outspoken critics view that eval()ing code sent from the server is not a good thing. See http://blogs.ebusiness-apps.com/jordan/index.php/17/. I would modify this article myself, but I just found out what JSON is this morning. - Jay Buffington 16:41, 20 October 2005 (UTC)

This is an incendiary opinion article on why XML is better than JSON, not on the relative security of evaling JSON sent from a server. The assertion still stands: without cross-domain access (disabled by default), if you cannot trust the JSON coming over the XMLHttpRequest, then you can't trust the page itself, as both are guaranteed to be coming from the same source. capnmidnight 15:54, 5 December 2006 (UTC)

YAML is not a subset, superset, anything related to JSON other than that both seek to be lighter, simpler alternatives to using XML. Don't let the fact that you can write files that are equally parsable by JSON and YAML parsers fool you.

I was going to comment on the exact same thing: the syntax of YAML is certainly not a superset of JSON, so saying that YAML is a superset of JSON is very confusing. Possibly, YAML is functionally a superset of JSON? In that case, we should change the formulation. --Ebruchez 13:27, 2 June 2006 (UTC)

[edit] Security risk?

As kind of implied in the comment above, doesn't eval()ing code from another server require that you have absolute trust in the "data" source? I mean, in the example code on the article, anyone who can insert content into http://example.net/this/is/a/fake/url/ can execute whatever JavaScript code they want, in the context of the website "receiving" the data.

Obviously, it's not impossible to trust the "data" source (and I saw somewhere that XMLHttpRequest() can only retrieve from the same server), but surely the importance of doing so should be mentionned very explicitly in the article. Or is there something I'm missing? - IMSoP 13:00, 4 November 2005 (UTC)

XMLHttpRequests are bound by the Same origin policy. But it is possible to load JSON objects using a proxy or other techniques. Now about evaling potentially dangerous code: I agree that this should get some mention. Perhaps the gist of the additional material could read:
If you're loading data from your server there shouldn't be a problem (and if there is a problem, you've got a serious issue that has nothing to do with JSON). But if you're using any of the techniques that can load data from a server you don't have control over, you are putting your trust in whoever's running that server. If, for some reason, you are loading JSON from a source you don't trust (WHY ARE YOU DOING THAT!?), you should validate the code before evaling it (by checking for function calls that shouldn't be there, etc).
...or something along those lines. - Gamol 08:17, 24 November 2005 (UTC)
OK, I've gone ahead and added a subsection on this. Incidentally, I came up with a reason this might end up happening - with people talking of JSON as an alternative to XML, imagine something like RSS being translated into JSON; then imagine people making "JSON/RSS" readers that blithely eval() code from Joe Random Hacker's blog... I think this is a rather important limitation of JSON as compared to a "proper" data format like XML (or rather, a flaw in its widely used parser and selling point, the eval() function). - IMSoP 20:49, 29 November 2005 (UTC)
> imagine something like RSS being translated into JSON
Actually, I forgot about JavaScript feeds. People are doing this sort of thing and they're doing it in a way that doesn't let them validate the foreign data. At least if they were using JSON, they could vet the info and make JavaScript feeds safer. I'm sure there's some your-site-is-in-danger security warning about these but I haven't heard of any serious exploits via the practice. Here's some JS feed sites: The Scotsman, RSS-to-JavaScript, some Google results.-Gamol 04:04, 7 December 2005 (UTC)

[edit] JSONT

I inserted a link to my article about JSONT. The combination JSON/JSONT can be seen as roughly equivalent to XML/XSLT.

JSONT

If you think it is closely related to JSON, I could write some more about JSONT.

If you don't think so, feel free to also remove the link.

Meanwhile there is also a link from json.org to JSONT.

--

Stefan Gössner

well ok, it doesn't seem to fit.

[edit] History

Where is the history section? Who coined the term, etc.? 70.20.193.90 19:05, 2 July 2006 (UTC)

A month later, and I'm still trying to figure out where "JSON" came from. Who started the spec? And why doesn't this article mention him/her??? 70.20.147.17 03:33, 1 August 2006 (UTC)

I partly answer your question with a couple of sentences with info about JSON specifications and roots. Right now it's the second paragraph. --Gosub 22:23, 9 September 2006 (UTC)
Douglas Crockford might be worth mentioning as his page claims he created it. 207.126.230.225 22:59, 24 October 2006 (UTC)

[edit] Cross-site request forgery

User:69.232.196.25 wrote (on the article page, moved here):

This section is not concerned with JSON. It does not belong in this article. It is concerned with a misuse of the HTML script tag. It also recommends an incorrect solution to the problem. The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data.

I assume the IP failed to understand the issue; perhaps it could be explained better? The attack works as follows:

  1. Alice logs into her webmail, run by Bob
    1. Bob sends Alice a session cookie
  2. Alice's web client uses the session cookie to retrieve her emails
    1. Bob sends Alice an AJAX page
    2. Bob's AJAX page, running in Alice's web client, sends a JSON request
    3. Bob responds to the request, sending the data to Alice
  3. Edgar sends Alice an email containing a link (free porn, perhaps)
  4. Alice clicks the link and goes to Edgar's web site
  5. Edgar's web page contains a script tag pointing at a URL on Bob's webmail site
  6. Alice's web client follows the script tag
  7. Bob's webmail site validates Edgar's request (because Alice's web client sent the session cookie) and responds with JSON
  8. Edgar's web page, having peeked into the JSON from Bob's webmail, has been able to read Alice's email and sends that email to Edgar.

--EdC 01:11, 17 December 2006 (UTC)

Note that:
  • the person who is misusing the script tag is the attacker, so neither the web services provider nor the user can do anything about it
  • Alice may know not to click links in emails; that won't help, as an alternate attack scenario is to pollute a high-traffic web site (e.g. Slashdot) and hope that some of the visitors are logged into GMail (which they will be)
  • "The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data" — how? The server is sending data to the victim's web client, which has requested that data with a currently valid session cookie.
--EdC 01:26, 17 December 2006 (UTC)

[edit] JSON vs XML

"XML is however a markup language and is thus significantly more complex than JSON, which is specifically designed as a data interchange format, not a markup language"

I don't follow this reasoning. Markup languages are not more complicated by definition over data interchange formats. The two are also not mutually exclusive -- XML is a markup language designed for data interchange.

As to complexity:

  {
      "firstName": "John",
      "lastName": "Smith",
      "address": {
          "city": "New York, NY",
          "zipCode": 10021,
          "streetAddress": "21 2nd Street"
      },
      "phoneNumbers": [
          "212 732-1234",
          "646 123-4567"
      ]
  }

vs.

 <person>
    <firstName>John</firstName>
    <lastName>Smith</lastName>
    <address>
       <city>New York, NY</city>
       <zipCode>10021</zipCode>
       <streetAddress>21 2nd Street</streetAddress>
    </address>
    <phoneNumbers>
       <phoneNumber>212 732-1234</phoneNumber>
       <phoneNumber>212 732-1234</phoneNumber>
    </phoneNumbers>
  </person>


I'll grant you that XML is more verbose, but 'significantly more complex'? 209.131.211.194 18:52, 20 December 2006 (UTC)

To enhance your statement, XML is for eXtensible Markup Language. --80.217.189.168 19:14, 26 January 2007 (UTC)

[edit] JSON and AJAX isn't "compatible"

The page states that JSON and AJAX is commonly used together over AJAX and XML. AJAX means "Asynchronous JavaScript And XML".

Do I get my point across? Oh and, Ajax is commonly used to refer to the cleaning soap. --80.217.189.168 19:12, 26 January 2007 (UTC)

If the point you're trying to get across is that you're a humourless pedant, then yes, you have succeeded. The article states that JSON is an alternative to XML in AJAX; could it be any clearer? –EdC 21:34, 26 January 2007 (UTC)
EdC, please remember to stay civil. Thank you. Let me attempt to paraphrase the anon's comment. I believe what that person is saying is that you can not have "AJAX" without "XML". Therefore, using JSON in lieu of XML makes it no longer AJAX, but something totally other. Given that, the sentence is somewhat confusing. I tend to agree with the anon in this. -- ShinmaWa(talk) 19:20, 25 March 2007 (UTC)

[edit] JSON and Python

JSON does not 'happen to be' a subset of Python: for starters, 'true' and 'false' have capitals in Python. The claim about eval() in Python being useful for JSON should go until somebody takes the time to find all differences between JSON and valid Python. And, as said by others, eval() is unwise anyway, especially in a non-sandboxed language like Python. --Habbie 11:29, 20 February 2007 (UTC)

[edit] Why JSON?

Why programmers call it JSON? (Javascript Object Notation) JSON is an incomplete copy of ECMA-262 and not as it should be.

Stop once and for all call in it JSON, and call it as it is. Literal Javascript which is far more than JSON. Read the Javascript ECMA-262 You'll find it easier to understand than as a sole concept not as JSON.

Understand the Object Oriented Nature of Javascript and understand that ... to start ... The correct use of Javascript is Literal Javascript What is it for? Simple ... Javascript was designed with a concept of inline porgramming.

So when you understand the structure of Javascript you will understand that the correct use of Javascript is literal, and talking about JSON is an incorrect, absurd concept.

Simple diffences like

for Javascript {key:value} or {"key":value} are the same for JSON only {"key":value} is correct

for javascript var x= 0005; is correct for JSON only var x = 5;

                                             JSON !== Javascript

So is it clear? literal Javascript === Javascript

literal javascript is only another way (the correct way for web programming) to use javascript

  as it is   x  [ "y" ] = value  or   x.y=value  <- this is liteal javascript in Javascript, don't call it JSON.
  as it is  x [ "y" ] = value   or  x={Y:value} <- this is literal javascript too, not JSON

—The preceding unsigned comment was added by 216.62.70.35 (talk • contribs).

OK, I can't say I entirely understand all the points you're trying to make here, but the one phrase that stands out (both visually and intellectually) is "JSON !== Javascript". Now, presumably, you are under the impression that some people are claiming that this is not true, and that JSON is JavaScript; that's not the impression I got - the 'J' in the name stands for 'JavaScript' because that is it's origin, and as the article states: "JSON is a subset of the object literal notation of JavaScript and is commonly used with that language."
If you're trying to say "there are ways of writing data structures in JavaScript that are not JSON" then yes, absolutely; that's what "subset" means. Why this means that "talking about JSON is an incorrect, absurd concept" I honestly have no idea. If anything, it makes the term all the more necessary, because we need some way of talking about the data format without mentionning the language; if you prefer, think of the JS as meaning "JavaScript-like". - IMSoP 20:00, 25 March 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../j/s/o/Talk%7EJSON_b061.html"