Good idea to give LT a kill switch on our greasemonkey scripts?

Se habla deHacking LibraryThing

Únase a LibraryThing para publicar.

Good idea to give LT a kill switch on our greasemonkey scripts?

Este tema está marcado actualmente como "inactivo"—el último mensaje es de hace más de 90 días. Puedes reactivarlo escribiendo una respuesta.

1brightcopy
Editado: Ene 21, 2010, 12:47am

As Tim has expressed a lot of concern of possible Greasemonkey-ization of LT, I've been thinking of putting a kill switch in my scripts to keep him on our side (and hopefully keep him from making the site harder to monkey with).

It would give him the peace of mind that if anything went haywire and our scripts were messing things up, he could at last resort put in a piece of code that turns that script off without trying to get users to uninstall the script. And if we ever felt like this power was abused, we could just take the kill switch out of our scripts fairly easily.

So here's what I propose. Put this as the very first piece of code in your script:


if (typeof unsafeWindow.ltKillSwitch == 'function' &&
    unsafeWindow.ltKillSwitch('Name of Your Script Goes Here'))
  return;


What that (hopefully) does is say "if there's a function called ltKillSwitch in the page and ltKillSwitch(my script) returned true, bail out and don't do anything else."

That way Tim can define the kill switch however he wants (global kill switch, kill switch per script, etc.) and we don't have to worry about the details. All you care is if it exists and it returns true on your script name.

What do you think? Totally crazy? A decent idea?

2JonathanGorman
Editado: Ene 21, 2010, 10:32am

I think it's overkill, at least till I actually see some more evidence from timspalding that he doesn't like Greasemonkey.

I guess here's my take on it:

1) If Greasemonkey usage with LibraryThing skyrockets, that should be a pretty clear indications of which areas of the interface that need work. Hopefully what will be done is something to address the concerns of that script, hence removing the need for it. (For example, I originally started researching this to try to find some way to have it so my "To Read" list didn't keep showing up with green checkmarks. That is an itch just got a lot less scratchy).

2) I know very, very few people who actually regularly use Greasemonkey. The idea of spending effort to take preventive measures against what I would guess is at most 1% of users seems silly when we don't know if there's a problem yet.

3) If there's something with a Greasemonkey script that's abusive, there's little to stop someone from taking out the kill switch. Even more, I imagine there's already safeguards to prevent abuse like throttling and the like. I would expect the number of people using Greasemonkey and the number of folks capable of modifying javascript in Greasemonkey are pretty close.

3JonathanGorman
Ene 21, 2010, 8:57am

Oh, and another perk, if 1) does happen with a particular Greasemonkey script, not only do you have a useful demonstration of what people want, you have a functioning prototype implementation.

4Collectorator
Ene 21, 2010, 9:25am

I didn't get the impression that Tim disapproves of Greasemonkey; only that one time it gave him a big headape. (inside joke)

I can't see how using Greasemonkey could ever interfere with the site at all (?) and the LT staff knows to ask if it is in use before troubleshooting problems.

But, I don't know anything. :)

5brightcopy
Ene 21, 2010, 10:37am

JonathanGorman> Good points, but I'm not sure what they have to do with what I proposed. :) First off, it's not really spending anything other than trivial effort. You just paste those two lines of code at the top of your script and change the script name. And you're done.

Second, it won't stop anything you said in point #1 (or post 3) from happening. For point #3, I don't mean intentionally abusive scripts. I mean ones where it has unintended consequences to the UI, especially after a code change altered the structure of what it used to manipulate.

Now, back to the question of who uses the GM scripts. Well, our good friend Collectorator (hi there!) is a good example of someone who doesn't know javascript that uses GM. If you look at the stats for my scripts, I've had quite a few installs. I agree that in general it's fairly low compared to the userbase. But I don't think it's just technically proficient users. That worldcat one got very popular when I posted it to a thread of Collectorator's about using worldcat.

Collectorator> Tim doesn't disapprove so much as he is leery of it, because of that past problem and the potential for repeats. As a programmer, I understand him. It's enough work for a small team to try to solve their own bugs and take responsibility for them. As far as how GM could ever interfere with the site - yes it definitely can. In some of the scripts I've written, it definitely did break the UI until I got the script totally right. Now, it wouldn't break the site for other people, but it would for the GM user.

Mainly, I do not think any of the scripting we're doing is going to cause a problem. Mainly I'm wanting to put Tim at ease so that he's more on our side of things. I want to be able to say "hey, you mind using id attributes on more stuff so it's easier to find the right element?" and have him say "sure thing, I'll try to use them" rather than "oh no, not another potential breakage." I'm hoping this will also get him more receptive of our scripts that work as a proof-of-concept for a code change we're requesting.

I'm going to do it. It's just three lines of code pasted into each script. The potential benefits far outweigh the trouble. I hope other people might follow suite but won't be bent out of shape if they don't. :)

6Collectorator
Ene 21, 2010, 12:31pm

Yes, I understand that GM could foul a site for an individual, and I was quite sure that no harm comes to the site itself. Now, when we are about to say, "It's all in your head, dude" we can say, "It's all in your browser."

7brightcopy
Ene 21, 2010, 12:39pm

6> Actually, it is possible to harm the site itself, though less likely.

I've written a proof-of-concept script that creates an iframe on one of the LT pages and loads it with the source from another LT page so I can get all the information on one page. In other words, I'm making it so one page load causes two. I'm also firing this by means of a timer loop, since I have to wait until a button is clicked on the form.

Now, image I fouled my code up such that it requested that load on ever run of the timer loop and never stopped. Especially imagine that this didn't happen originally but did happen when Tim changed the code for the page such that my previous condition to stop the timer now never happened.

And now imagine a couple dozen people install my script.

Basically, I've just implemented an accidental Denial of Service attack on LT using greasemonkey. I'm not sure how beefy their servers are, so I couldn't tell you at which point they'd actually start having problems. But it is a real possibility.

Note: I would never release a script such as that without explicitly getting Tim's okay on it.

8Collectorator
Ene 21, 2010, 12:54pm

Oh! Well this is now a horse of a different color! Now I think your kill switch is a good idea.

What would be really nice is to have the Tim Stamp of Approval on GM scripts. Then we'd all be more comfortable. But we'd need another Tim to perform this quality control function.

9brightcopy
Ene 21, 2010, 12:55pm

Yeah, that pretty much makes it a non-starter, unfortunately. Plus, if we got another Tim, he'd likely have a goatee and be evil.

Well... MORE evil.