Why store data in JSON rather than JavaScript object literal/initializer?

Question

I have been developing a Firefox add-on for one year.

My last update has been refused, because they want me to "store your objects/patterns in non-executable JSON files and load and parse via XHR or SDK API (if applicable), as in this example:"

var data = require('sdk/self').data;
var myJSON = JSON.parse(data.load('dir/file.json'));

I've always stored my data in JavaScript object initializers and never received even a warning.

The data in question is currently represented as one, or more, object literal/initializer expressions in a JavaScript files within my add-on. I am not obtaining this data from a source external to my add-on.

What is wrong with this way? Why should I change?

Since this refusal, my last approved version is "corrupted" and can't be downloaded.

Note that in the code shown, myJSON won't contain JSON, it'll be a reference to the object that you got after you parsed the JSON. — nnnnnn
– nnnnnn, Commented Jul 31, 2016 at 2:19
To check my understanding (I've had such a comment on one of my add-ons): The situation is that you currently have data that is in an an object literal/initalizer contained within one of the JavaScript files packaged with your add-on code. The Mozilla/AMO reviewer's comment is telling you to instead represent this data as JSON (not, quite, the same format as a literal), place it in a separate file (also packaged with your add-on), and load it into an object using JSON.parse(). Is that correct? — Makyen
– Makyen ♦, Commented Jul 31, 2016 at 2:48
@Nucktrooper, I edited this to make it more clear that the data you have is currently a part of your add-on and not being obtained from an external source. (you confirmed that this was the case in a comment below). If anything I added is incorrect, please correct it, or just revert the edit. An example of the data might be helpful. — Makyen
– Makyen ♦, Commented Jul 31, 2016 at 3:26
@Nucktrooper, while it is possible that the your older version was taken down intentionally, from the fact that you have called it "corrupted", it does not sound like the way it would be done (if AMO was going to do so). Without a pointer to your add-on it is difficult to investigate that aspect further. — Makyen
– Makyen ♦, Commented Jul 31, 2016 at 3:33
I've published a new version with the changes they asked me, and this one is also said "corrupted" when I download it. So it is not intentionally done by them. I don't know why, because I never open the xpi file after the creation, but It's not the topic of this question. — Nucktrooper
– Nucktrooper, Commented Aug 1, 2016 at 21:58

S McCrohan · Accepted Answer · 2016-07-31 02:59:03Z

1

When dealing with an external datasource, this is a security precaution against code-injection and XSS hijacking. Always parsing incoming JSON prevents functions injected into the data by an outside actor from being executed (as they would be if you used, for instance, eval()).

In the context of accessing data that shipped in static form with your plug-in, I'm not sure what they're trying to guard against.

This is now a non-answer, but I'm leaving it here rather than deleting because I think Mayken's comment below is worth preserving.

edited Jul 31, 2016 at 2:59

answered Jul 31, 2016 at 2:16

S McCrohan

6,7011 gold badge33 silver badges39 bronze badges

Sign up to request clarification or add additional context in comments.

4 Comments

Makyen Over a year ago

I believe that the situation that is being referred to in the question is that data is currently contained in a object literal within a .js file within the add-on itself, not that the source is from outside the add-on. In other words, that it is static data that currently exists within the to-be-signed add-on, as an object literal, not JSON, or other data, that is incoming from an outside source. The entire contents of the add-on, including the object literal are cryptographically signed. Any change invalidates the entire add-on, which will then be disabled by Firefox.

S McCrohan Over a year ago

On rereading, I mostly agree with you. I still believe this comment is motivated by an avoidance of executable JSON carried over from securing external XHR, but I'm not sure yet what vector they're imagining.

Nucktrooper Over a year ago

Yes, all data is in my extension, I don't ask any data from any external source.

Makyen Over a year ago

I've had a very similar comment on one of my add-ons for the situation I described. In my case, there was no doubt (file/object specifically referenced by reviewer) that it was referring to moving data contained in an object literal into JSON format, placing it in another file, then read in and parse: JSON.parse(). I quite agree with you that there are security issues if the source is external to the add-on, but this was not. I was not sure of the reasoning behind wanting it to be external JSON. I had/have some guesses, but nothing substantiated, nor any which justifies rejecting an add-on.

Collectives™ on Stack Overflow

Why store data in JSON rather than JavaScript object literal/initializer?

1 Answer 1

4 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

4 Comments

Linked

Related