Greasemonkey Detectable?

[Cyphorz]

I was just wondering if greasemonkey is detectable.

Thanks

[Aaron Boodman]

I presume you mean from a content page. Not in the general sense (that
I'm aware of), but you can detect individual Greasemonkey scripts, if
they use certain APIs (unsafeWindow in particular).

- a

[Mook]

This seems to sort of work:

<img src="chrome://greasemonkey/content/status_on.gif"
alt="WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" id="z">
<script>setTimeout(function(){
alert(document.getElementById("z").offsetWidth < 50)
},500)</script>

Tested on GM 0.7 / 0.8 on Firefox 2.0.0.10 and 2 months old trunk (...
I'm a little slow).

--
Mook
mook dot moz plus stuff at gmail

[Anthony Lieuallen]

On 12/24/2007 5:51 PM, Mook wrote:
> This seems to sort of work:
>
> <img src="chrome://greasemonkey/content/status_on.gif"
> alt="WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" id="z">
> <script>setTimeout(function(){
> alert(document.getElementById("z").offsetWidth < 50)
> },500)</script>
>
> Tested on GM 0.7 / 0.8 on Firefox 2.0.0.10 and 2 months old trunk (...
> I'm a little slow).

On my machine (GM 0.8 pre), that alerts true. Because zero is less than
50. And the width would be 0, whether you didn't have GM (and the image
didn't load) or if you DO have (and GM used contentpolicy to block it
from loading).

Or in other words, like Aaron said, no GM is not detectable by content
pages. (Directly. Some/most scripts are.)

[esquifit]

It does work for me. I tried it on two profiles with and without GM
installed respectively.

GM: 0.7.200705278.0
ua: Mozilla/5.0 (Windows; U; Windows NT 5.1; ca; rv:1.8.1.11)
Gecko/20071127 Firefox/2.0.0.11

As a side note, Karma Blocker does not help either, at least not with
these rules

score=100
match=all
rule=$origin.scheme!='chrome'
rule=$url.scheme=='chrome'

[esquifit]

Oops, sorry, now I see that you are speaking of 0.8, I haven't tested
this version yet.

[esquifit]

It does also work with 0.8. Sorry for the spam.

[Anthony Lieuallen]

On 12/23/2007 6:17 PM, Cyphorz wrote:
> I was just wondering if greasemonkey is detectable.

To recap this whole thread: Mook posted some code that he said worked.
Esquifit agreed that it worked. I didn't. So, I'm checking extra
thoroughly. I created this page:

http://arantius.info/gm/check-for-gm.html

* In a completely blank profile, no extensions, it says no.
* I installed GM 0.6.6.20061017.0 from a.m.o, then I saw the monkey on
the page, and it said yes.
* I upgraded to GM 0.6.7.20070131.0 from a.m.o (when I thought this
changed), and it still said yes.
* Once I upgrade to GM 0.6.8.20070314.0, though, the monkey disappears
and the page says no.

Also, 0.7.20070607.0 (last in a.m.o) as well as 0.8.20071208.0 (last of
Aaron's posts) continues to not load the monkey, and the page does not
detect GM, as I expected. Again, in a completely blank FF profile.

(Note, the logic is: offsetWidth === 0 means image did not load, and GM
is not present. Alternately, offsetWidth != 0 means image loaded, GM is
present. Rereading Mook's posted code, it checks width < 50, which will
*always* be true, the value will be either 0 or 16. I think there was
some intent for the not-loaded-image to display the wide alt text, but
that isn't happening for me at least.)

[esquifit]

Anthony: your example is not that of Mook. The presence of the 'alt'
attribute is critical here:

Case 1: You do *not* have GM installed
The src attribute of the img tag points to a non-existing resource;
Firefox then *displays* the 'alt' attribute; this have the effect that
the offsetWidth of the element takes the size of the alt attribute
into consideration.

Case 2: You *do* have GM installed:
The src attribute of the img tag points to an existing but blocked
resource; somehow this is different that a non-existing resource, and
Firefox does *not* displays the 'alt' attribute. The offsetWidth
remains zero.

You can check Mook's example here:

http://esquifit.googlepages.com/detectGM.html

I am not sure whether this is a bug in Gecko. According to Mozilla
Developer Centre [1], the offsetWidth is computed taking the following
into consideration:
* the element borders,
* the element horizontal padding,
* the element vertical scrollbar (if present and rendered)
* the element CSS width

It is not clear if the ALT attribute contributes to offsetWidth, and
if does, when. The attribute is non-standard, so there is not
'designed behaviour' to complain against.

[1] http://developer.mozilla.org/en/docs/DOM:element.offsetWidth

[Anthony Lieuallen]

On 12/26/2007 6:26 PM, esquifit wrote:
> Anthony: your example is not that of Mook. The presence of the 'alt'
> attribute is critical here:

Thanks for explaining that. I thought I had tested it, but missed one
case, the 'image with alt' and 'greasemonkey not installed' case. In
other words, yes, it is detectable. Shoot.

[John Plsek]

Interesting, with version 0.7.20070607.0 the monkey head shows and the
width is reported as 16 if you install but disable Greasemonkey. Image
doesn't display, and width is 24 if you enable Greasemonkey

Well, I find it curious anyway.

[esquifit]

From 'components/greasemonkey.js', line 127:

// block content detection of greasemonkey by denying GM
// chrome content, unless loaded from chrome
if (org && org.scheme != "chrome" && cl.scheme == "chrome" &&
decodeURI(cl.host) == "greasemonkey") {
return Ci.nsIContentPolicy.REJECT_SERVER;
}

Apart from nsIContentPolicy.REJECT_SERVER there are other three [1]
constants for denying access to a resource:

nsIContentPolicy.REJECT_OTHER
nsIContentPolicy.REJECT_TYPE
nsIContentPolicy.REJECT_REQUEST

With any of these, GM behave the same way as if it were not installed,
thus effectively bypassing the detection; I do not know the reason why
precisely the one that does not work was chosen ;)

Of course, that works as long as Greasemokey is enabled, otherwise the
code is not run and the detection continues to work. But then, what
harm is a page detecting a disabled Greasemonkey? The only situation
I could imagine is a site tracking *registered* users as having GM
installed (and temporarily disabled) and taking actions accordingly.
Not a likely scenario, I hope.

[1] http://www.xulplanet.com/references/xpcomref/ifaces/nsIContentPolicy.html