Thread:CzechOut/@comment-31294034-20171006182017/@comment-31294034-20171006200548

My post is talking about the one script in question because this one particular case is probably the most bizarre. The script in question was not approved within the normal time frame as it was rejected for a problem it didn't have. No where in the script did it give anonymous users access to information they could not already get their hands on via a wikis very public API.

In addition, the reasoning for seemingly mandating a guard was a completely contrived example in which a spider of some sort manged to:
 * 1) Have the foresight to crawl the monobook skin
 * 2) Execute this particular script in order to make changes to the page
 * 3) Scrape the information from the modified DOM to gain access to edit info

If this completely improbable scenario were to play out the spider would be much better off making batch requests to the, again, public API Wikia provides through MediaWiki to all of its users.

Furthermore this asinine scenario is still not really reason enough to push for the inclusion of a guard to stop the loading and use by anonymous users.

And, to quote you, "At the end of the day, the use case for anons on Monobook is so tiny that it's not worth whatever small security risk might be present." I rebut with, at the end of the day the use case for monobook to anons is so tiny that the non-existent security issue is not even worth pushing a guard for.

And lastly, you yet again rejected a revision because of commented out code, which cannot run, which seemingly goes against the "the approval process is not a review of the general quality of your code" section of the disclaimer in the Help:JavaScript review process page. The contents of comments poses no security issues or issues at script run-time as no JavaScript engine acknowledges or parses out the contents of comments.

I disagree with your statement about it not setting a precedent. A staff member mandating that code be changed to meet yet undisclosed criteria is quite the situation where a precedent is set.

Even so would it not be more appropriate to leave the code pending review while you seek clarification on its function than rejecting it and then arguing with the users about the purpose and functionality of the script? I certainly think so and I am fairly sure other developers feel the same way as well.

Furthermore, as talked about in the previous section, said line of code didn't need to be added and the hook didn't and shouldn't have been removed only to be replaced later.

I was not asking if you were making a broad ruling, I was asking if we need to now support browsers which Wikia arbitrarily adds to the Help:Supported browsers page. This is an incredibly important question as it basically decides in the future whether or not scripts will get rejected.

The point is that the code I submitted in itself didn't screw up the rendering nor functionality of the site. In fact the code used in Zion is completely, and without error, compatible with IE. Upon failure it does not cause any elements of the site to become corrupt nor does it stop other scripts from running independent of itself. It was designed in such a way that the scripts it loads are put outside of itself so that errors in them will not bubble back up to Zion and further into code minified by the Resource Loader.

It is in this manner that Zion does not and cannot violate the part of the ToU that you quoted.

Source on error bubbling: