We had to disable installation of the Monkey Barrel script because it made lots of requests and put a huge load on the server - the thread for that is here.

This is obviously something of a slippery slope, so let's discuss it openly and frame a sensible policy.

Should we disable scripts under any circumstances? When? Why? Why not?

These opinions are my own, not site policy (yet ;p):

Obviously many scripts interfere with the intents of the people behind the site - some might even disrupt their business model. This is to some extent the point of userscripts, I feel, so this should certainly not be cause for removing/disabling scripts on this site.

In the case of the Monkey Barrel script, server load was apparently increased fivefold to tenfold. Disabling it was, as I understand it, necessary if we want an up-and-running Userscripts.org. (I make small tweaks to the site code, I don't do any work on the production server, so I don't know first-hand.) I feel that this is a valid cause for disabling scripts – I think most scriptwrights would agree that a site that is up-and-running is preferable to a dead site, even if that means Userscripts.org disables their script.

I also feel that if a site owner contacts Userscripts.org and asks that a script be disabled/removed, we comply if it can be shown that it's actually harmful to the site/server in this sense, but certainly not if they disagree with having their ads removed or links rejuggled.

Perhaps the distinction between disrupting someone's server and disrupting someone's business model is a bit arbitrary, but that's where the slope would definitely start to get slippery. Also, I imagine a couple of hundred users making oodles of requests would hurt a site's server(s) more than a couple of hundred users not watching ads would hurt its economics.

A more radical policy would be to allow anything (lawful) and let any site (including Userscripts.org) handle this on their side - by limiting the amount of allowed connections, checking referers and so on. Less slippery a slope, but also a bit rude, perhaps.

I'm +1 on a minimal involvement policy, where us.o only takes preventive action against scripts that hurt the us.o site. Which is more or less what we have in practice already, with a rather heavy-weight value of "hurt".

Reasoning: we already offer commenting functionality for people to voice opinion against particular scripts, and inviting default practice of shutting down scripts deemed uncomfortable will mostly give us.o admins a work burden not related to improving us.o, which is bad. More in-depth reasoning of both points in this thread on the Greasemonkey-users list.

Makes sense to me.

I suppose when phrasing this as policy, we should perhaps also mention that we reserve the right to nuke scripts that are harmful to users (e.g. steal their passwords) and obviously spam (like sand, spam gets everywhere – I'm sure there'll be spam scripts if there aren't already).

So should this be part of a "legal"/"disclaimer" type site section, or just a forum sticky, or something else? Something you see on the upload and update pages? Or should we assume it's pretty obvious, and just refer people to this thread if we have to disable their script?

Hm. Then again, removing scripts that steal passwords or that are spam shouldn't really require an explicit policy. However, I suppose a notice to the effect that scripts that prove unwittingly harmful to users or to this site might be disabled, but that we otherwise have (should we agree on this point) a minimal involvement policy.

Eh, while I agree that removing scripts which can directly harm sites server-side would be a lot of work, much of the work could be automated. Checking for specific bits of code and requiring the submitter to verify that it won't be hitting a server with huge amounts of traffic shouldn't be too hard.

My rational for this is that it is effectively providing DDoS tools, admittedly unwittingly. A malicious user could, with very little work, insert a small bit of code in an otherwise useful script which would not affect the user except for slightly damaging the bandwidth, but which would completely kill a server. Even a non-malicious user could end up doing something like the author of Monkey Barrel did, which would still result in hitting servers very hard. True, causing serious damage would require being very popular. But I can see some community or even individual with a serious grudge pulling that off. Better not to leave the option open, methinks.

Flyne: So you're suggesting we look through would-be-uploaded scripts for XHR requests and ask the user to verify it does not cause huge amounts of traffic? Interesting, but I think it seems like overkill, especially if we go with a minimal involvement policy as suggested above.

I like the simplicity of what Johan suggested. So we obviously remove any spam scripts and malign scripts - scripts that steal passwords or that are obviously intended for DDoS, should such scripts turn up. Other than that, we don't remove/disable scripts unless they threaten the existence of this site itself – like this particular case, with Monkey Barrel. If other sites have complaints, be it server load or ad-removal, they may comment the script and make their case, or change their site, but we stay away from that slippery slope.

Yeah, that would work - except that, to the best of my knowledge, sites can't tell that it's Greasemonkey's fault, much less which script is causing it. All they can see is that some IP addresses are repeatedly requesting a page on their site. Makes it a little hard to complain to userscript.org.

Flyne: That problem is unfortunately NP hard, and there is an endless number of obfuscation techniques a competent malicious script crafter could employ to dodge such detection. It's a race between black hats and black hat prevention code which black hats will always have the initiative in, and lots of very boring and unrewarding work which would A) flag or affect non-malicious, useful scripts like Book Burro, B) still require manual handling, C) require staff to partake that handling.

That's not to discourage you from participating to yourself write such code for advisory flag tags inviting particular scripts to peer review (once we have that system), merely suggesting that the present code maintainers are unlikely to go down that route themselves.

Yeah. Such detection would probably not be as accurate as one would wish.

Only removing scripts that are obviously malicious, only disabling scripts if they threaten to bring down this site, and letting the site owners themselves and comments/ratings/peer review handle inadvertently malicious scripts seems like a good solution. Pretty much how it's been so far.

Alright, I can see that it would be easy to get around with work. Checking for obvious stuff is still good, but yes, if someone was trying to be malicious they could pretty much ignore it. That would leave it to site owners to complain or deal with it, provided it didn't really interfere with users of the script.

Some things can be checked for, though, and I don't think flagging those scripts for review is such a bad idea. When site owners can't complain about it (which they can't as it is, I think), you've got to be a little more careful with the review process. Automated checking for a few strings isn't very hard.

If he sees a lot of request with the user-agent “Mozilla/4.0 (compatible) Greasemonkey”. Of course, not all userscripts has that user-agent. But I've never found a reason for changing it at least.

Arvid, is that the default user-agent? If not, it probably should be. I like the idea of defaulting to something informative, but that can still be overridden for stealth. I noticed that Monkey Barrel explicitly sets that user-agent for requests. Good point, anyway - that would certainly help a competent site owner figure out what the problem is, which takes a lot of moral weight off our shoulders.