dean.edwards.name/weblog/2005/03/ungreased/

Comment: #1

While this is a way out for Greasemonkey, you’ll have no way out with Opera, as Opera has every option of rewriting your script before it executes, using the BeforeScript and BeforeExternalScript events.

Comment: #2

This is a heads-up to the browser developers I guess. Leave a back-door please! We won’t always use it but it’s nice to know it’s there…

Comment: #3

Why is it that some people don’t realise that what a user does to content they download is their own business?

Just add a little warning saying “if this looks bad, try turning user scripts off” and be done with it.

Comment: #4

So, Opera’s giving me yet another reason to pay it only the mildest of attention while I’m developing, then?

Comment: #5

I think the larger issue here is scripts that are turning DOM compliant browsers into non-compliant ones.

I’d like to see less of the “Emulate IE” in other browsers, and more “Emulate true standards” in IE.

Comment: #6

Er, John. No. You are however encouraged to develop with standards, trust that you do the right thing, and not care particularily whether a user script will conflict with your sites/pages/application: Users have chosen to add these scripts themselves, and they should be able to turn them off entirely by themselves as well. Besides, apart from site fixes, this is a feature that will only ever be used by a tiny minority of the users, just like only a tiny percentage of users create user stylesheets.

Comment: #7

“Cases where you just don’t want your DOM screwed with.” -quote

“Your DOM”? I am sorry, but once your code leaves your server, it is no longer “your DOM” but the “user’s DOM” and they can screw with it as they please.

Deal with all possibilities, but don’t *limit* a user’s palette of abilities. I thought we all went through this already with things like disabling right click and target=”_blank” ?

Comment: #8

“Your DOM”? I am sorry, but once your code leaves your server, it is no longer “your DOM” but the “user’s DOM” and they can screw with it as they please.

Comment by GreyWyvern

Maybe you’re right. I haven’t disabled GreaseMonkey on this site. I coded around the linkify changes instead. But there is an issue here I feel. It looks like we are entering an era of scripting and web applications. It might mean that those applications might have to be coded a lot more defensively or at least carry a warning about user scripting.

Comment: #9

There are two groups who needs “warnings”:

First, it’s site authors: They need to code with accessible, rich, semantic markup. Meaning: minimize the need for user scripting to route around real problems.

But, it’s also for user script authors: They will need to be defensive about their scripting: Don’t mess with documents that have already done what your user script does.

Comment: #10

In light of the above comments. I provide this as an alternative way of disabling GreaseMonkey:

 document._createElement = document.createElement;
 document.createElement = function(tagName, password) {
    if (tagName == "SCRIPT" && password != "My scripts are OK!") {
        if (!confirm("Some GreaseMonkey user scripts can adversely affect the display of this page.\n" +
            "Do you want to allow user scripts on this page?")) return;
    }
    return document._createElement(tagName);
 };

Comment: #12

Next thing you know, they’re going to give the user the option to disable javaScript all together and then we’ll all be screwed.

Comment: #14

A confirm box? You’re lucky if somebody like me has JavaScript turned on when they visit your site, it won’t be on much longer if you throw confirm boxes in their faces.

Comment: #15

You’re lucky if somebody like me has JavaScript turned on when they visit your site…

Isn’t that a little bit like visiting csszengarden with CSS turned off? All of my work is JavaScript or JavaScript related.

Comment: #17

‘The trouble was, that one of the default GreaseMonkey user scripts (linkify) was altering the DOM before my script got there. The DOM my script was expecting to see wasn’t the DOM it got. GreaseMonkey can break DOM scripting’

okay. In what way was the Dom changed?

Comment: #18

linkify identifies text that looks like a link and wraps it with an <a> tag.

Comment: #19

Heh, extensions don’t need to create an element to edit your page, so I’ll bet GM just comes out with a way to disable your disabler. =D

All it has to do is point document.createElement back to document._createElement.

I really don’t think you should be putting this disabler out there though. It’s not GM’s fault that somebody wrote a bad script. If you want to write something helpful you should create one that blocks certain grease monkey scripts, instead of all of them.

Comment: #20

LOL, the only people using “features” like this are people like us (well, not me) – that is, web developers. It’s like worrying about errant conditional comments for folks with standalone IE browsers installed. It’s just not an issue in the real world. It’s only an issue in the closed gene pool of web developers

Comment: #21

Sort of, Al. We’ve got a lot of scripts, and there’s been a good bit of buzz.

If there is a user script that does something useful, Aunt Tilly will install it, even if it means asking her geeky nephew to help her out. As an example, several non-techie friends who are using Firefox have asked me to help them out with features like SessionSaver and AdBlocker. Extensions are gaining some mindshare, and I bet user scripts do to.

Thanks for starting this conversation on a reasonable note, Dean. I posted a pointer over on greaseblog.

Comment: #22

It is, literally, impossible to “disable” Greasemonkey. (by a site owner using Javascript installed on their site) You can mess with its ability to perform certain actions, but then those can always be worked around, which you can then work around, which can then be worked around……. Talk about a barrel full of monkeys. It’s pretty funny that people are freaking out about Gm scripts “messing with their site”. Especially when we didn’t hear that about Firefox extensions and/or Javascript Bookmarklets. (afaik) I find this all very odd, as well as humorous, and interesting while I’m at it. As a web site developer, designer, programmer, implementer, and so on, I could care less what people (legally) do with “my (published) content” once it arrives on their client. And, in fact, I don’t really want to know. Talk about a fascinating exercise in human sociology and psychology engineering and observation. And then one day “this” will all blow over and people will roll their eyes in a smiling manner whenever someone thinks to mention it. Until then, sit back and enjoy the show. Until “next time”.

Comment: #23

Bill-

You’re absolutely correct. The Serenity Prayer (or a secular counterpart) should be required for all web developers.

Comment: #24

Heh, well this disabler isn’t going to work for long. About two posts after the one where I listed this disabler on the Grease monkey mailing list one of the developers posted this:

“I found (well, someone at work found) a way for us to inject even earlier — into the actual source code before the browser gets it. That will be next change and should fix this DOMContentLoaded stuff.”

BTW, this posting script really needs to be updated so that people can add + modifiers to their email addresses.

Comment: #25

Keep in mind that people aren’t so much freaking out in a “OMG they are messing with my content!”, they’re getting concerned that user-scripting will cause the site not to function correctly. If user-scripting becomes popular, then you’ll have a potentially significant number of people visit your site, find it doesn’t work correctly and assume it’s the developer’s fault.

There’s only so much a site developer can do in terms of defensive scripting, client-side extensions/scripting can do all sorts to the page and trying to account for all possibilities is akin to trying to solve the halting problem. Whilst I’m firmly in the “give the user control” camp, there’s got to be some give and take.

Comment: #26

in this case, i’d say the onus is on the user. if they install greasemonkey and then experience problems on a site, it’s their problem (and, in a broader sense, greasemonkey’s developers’ responsibility to fix it). however, i know that’s a very idealistic view on the subject, which doesn’t solve the immediate problem of users coming across what they think is a “broken” site (then again, considering that greasemonkey is not an extension that joe average would install, maybe it’s not such a huge problem…not sure).

Comment: #27

OK. I’m closing comments on this one.

User scripts are the shape of things to come. Let’s continue this debate somewhere suitable:

http://greaseblog.blogspot.com/2005/03/user-script-arms-race-has-begun.html