I just disabled a script MonkeyBarrel on userscripts.org.
Unfortunately, it was a cool idea, but caused lots of server issues.
The feature needs added to us.o and to gm, but in a more private and
scalable way.
(it would be great if existing users of the script could disable it as
right now the server is at full capacity and starting to give random
service errors)
If you want to talk about the feature the script added you can visit:
http://userscripts.org/forums/3/topics/121
The larger and more important issue is having a documented policy:
http://userscripts.org/forums/3/topics/122
When/How/Why/... Obviously we aren't the first to have our service
affected by greasemonkey, but we haven't removed any scripts before.
Is a script considered malicious only if it consumes too many resources?
It is way to late for me to be even attempting to type.
Jesse
ps. if there are issues with userscripts going up and down in the next
day it is because I'll be working on dealing with making search not so
computationally intensive... Please message me (anotherjesse on
gtalk) or (notthatjesse on aim) if you see stability issues.
pps. Thanks to Britt and Henrik we had worked through many
performances issues, and the server load was averaging about 0.2 (with
almost every page being very responsive with the exception of search).
The purpose of this conversation is the bigger question about when and
why we should disable scripts.
Jesse
To clarify: the script exposed your full click trail of all users
running the script to the us.o server. Including for https:// urls.
Some extensions do that too (and sometimes for good reasons -- the
Google Toolbar has an option you can turn on to do that and get page
rank data for every page you visit in return, for instance), but it's
a privacy concern not to be taken lightly.
Granted, a feature enabling you to find scripts for any particular
domain or page you visit, is a feature we all want, and arguably one
we would eventually want to implement base support for right in the
Greasemonkey extension itself, but it needs to be implemented part
server side, part client side, and with good, proper caching and
algorithms on client and server side both.
Everybody is warmly welcome to chime in and help implement that
vision, from both sides, but don't abuse the userscripts.org search
page to implement this; it can't take that kind of load as it is built
today, and trying will just get that feature turned off due to the
denial of service attack nature of using the feature with access
patterns it's not equipped for.
> When/How/Why/... Obviously we aren't the first to have our service
> affected by greasemonkey, but we haven't removed any scripts before.
>
> Is a script considered malicious only if it consumes too many resources?
Invasive composition (the very core of the user script idea) will
always be considered harmful by some sites who don't feel they want to
be invaded, but I don't think we should enter the game of yay or
neigh, or we'll be to our knees in it before soon.
Where us.o can take preventive measures towards spreading scripts that
measurably hurt the proper function of us.o, I find it natural that we
should. Otherwise I don't see that it's an issue we should interfere
with.
Except offer anybody to comment on scripts, and provide forums where
people can discuss and learn from one another about responsible user
scripting, in how to design scripts properly without killing the sites
they connect to, or needlessly leaking user click trails. We already
offer both these opportunities, though there might not yet have shown
up much in way of helping newcomers to good scripting practices.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
Thanks for continuing the discussion. Where might a userscript newbie
go to see such a of best practices, no-nos and ettiquette rules?
Best,
Kevin
On Mar 13, 5:51 am, "Johan Sundström" <oyas...@gmail.com> wrote:
http://wiki.greasespot.net/Main_Page - There isn't too much on the
wiki yet, but it can only get better.