Suggestion: Detect Tampermonkey and/or installed scripts and change some page content accordingly

[derjanb]

The latest Tampermonkey BETA version added experimental support to allow certain pages to detect Tampermonkey and query the installed version. It's also possible to query by name whether a script is installed.
This can be used for example to not show installation hints or to modify download/install buttons to say something like "already installed".

Feel free to post concerns, issues, hints and change requests here: Tampermonkey/tampermonkey#322

Thanks,
Jan

[Martii]

@GreenLunar

Why would you let servers to detect Tampermonkey?
I think it would be better to conduct any check on client-side.

...

I now understand the problem of conducting this check on client-side.

OUJS would only allow this on client side (front end) due to climbing the stack inside node. So if there is an issue with it being client side, as a script tag that we serve to the user/guest, then it won't happen.

When, and if, #53 occurs is when this could be done server side.

[Martii]

@tophf

Maybe TM should show a confirmation page the first time a whitelisted site wants to get the info. With buttons to allow/disallow permanently/temporarily.

Assuming that OUJS implements this via a script tag (client side), @sizzlemctwizzle would either need to establish a subdomain for allow/block listing via NoScript, or browser equivalent, with optional CSP, or we could add an opt in for each user account which would deny any guest/visitor from this feature. Since our server is natively JavaScript we at OUJS have to consider traversing the stack on both client and server side scripts that could be tampered with.

[sizzlemctwizzle]

OUJS is very concerned with privacy. This is the reason we can only identify a user based on your 3rd party authentication provider at login time (except if you login with GitHub, in which case we store your username to provide integration because it makes sense). We only store a hash of what the authenticator provides as a user id.

I would only feel confortable doing this completely on the client-side, with no possible way the responsible JS talking to Tampermonkey could communicate with server. It would just use the information on the page to query Tampermonkey and update the relavent UI. This way any abuse of this information (such as keeping records of who has what installed) could be easily caught by our users client-side, since the only way to pass information would be through the DOM.

[derjanb]

The suggested Tampermonkey API is completely client-side. To be honest I have no idea of OUJS's architecture so please forgive my confusion. Why should TM try to communicate with your server? Why should it want to know anything about your internal user entry? TM already knows the currently installed scripts.

My suggestion was to let your server deliver a script with some functionality to switch a CSS class or whatever based on client-side userscript detection.
Not sure if one of you checked the referenced issue, but it contains an example: Tampermonkey/tampermonkey#322

And BTW the Greasyfork implementation can be found here. It simply switches a button text.

[GreenLunar]

I am not an OUJS developer, so please take my opinion at face value.

In concern to your last line;
From my very bad experience - of which I will not elaborate - with the way Stylish was managed, and maybe still is, I tend to not give any weight whatsoever to Greasyfork, and I suggest none of us would. These couple of websites may not be used as an example for imitation.

[Martii]

The suggested Tampermonkey API is completely client-side.

I am thinking that a Userscript would be better to handle this as the scope is retained from the client side in all engines. If we put in a script tag that means we own it and it's in our scope not the clients.

switch a CSS class or whatever based on client-side userscript detection.

That's that soft notice I was talking about but it could also potentially be misused like link history visitation... that's why Moz took it out because it was being abused. I think I could write a Userscript to track installs as an ancillary script utilizing this feature of TM and that would definitely intrude on privacy.

I do commend you for your creativity but I think that there are too many loose variables hanging around for us to adopt it in our scope at this time. I wouldn't object to a Userscript as I previously stated in this reply. _bootstrap_s classes are quite simple to toggle a CSS class to a different coloring as well but I think an opt in is mandatory here and .user.js would be more suitable for visitors as well as registered users. We also pretty much exclusively say "click the blue install" button in our documentation which is spread out in a lot of places... I wouldn't be looking forward to changing all of that esp. here on GH.

@GreenLunar

These couple of websites may not be used as an example for imitation.

That is a valid point but I watch GF for certain issues as well. We can work cooperatively but not mutually exclusive. Since the other site isn't JavaScript based and is Ruby based they don't have to be as concerned with traversing the JavaScript scopes... however if that site is sharing any other projects in the content scope those can be at risk to manipulation either from XSS or direct .user.js. It's a fine line that I travel between how malicious a script can potentially be... someone somewhere will undoubtedly try something and we'd rather not have our node stack at risk which is why it would never make it to production other than served as client side script... ownership (actual namespace) if we put it in our views it would be ours... so I don't think that would be wise with what we share in the content scope. Of course GM, or equivalent, can blow away a reference to a global identifier but at least it can't be taken over with the same privilege as if it originated from our domain.

So long story short here... comparisons between other sites really can't be done so you are correct.

[derjanb]

it could also potentially be misused like link history visitation...

A link can be added to every (malicious) page, while I think that if an attacker is able to execute a script within your origin at the client-side, then you may have other problems than leaking script installation information, but I might be wrong.

However, I'm fine with this decision and will remove OUJS from the API whitelist.

[Martii]

and will remove OUJS from the API whitelist.

I'll give you an idea that I've had for GM/GMP for eons... perhaps you could bundle with a .user.js for whatever sites you wish and actually move it from your extensions scope to the Userscript scope... you would have to follow CSS classes on any site that TM would support.

[Martii]

Briefly too is the "whitelist" of the whole site... I continue to maintain that people should read a script homepage first before invoking installation... having any site whitelisted that broad invites a deviation of this.

[Martii]

@derjanb
One other diddy if we did adopt this in our namespace we'd have to have you continue to allow 127.0.0.1 in order to test in our development. Your custom crx you built for GF wasn't there after 2.5 days of publishing so I couldn't even try it out. I've given a lot of thought to how to hack TM and Chromium/Chrome lately and it's best just to not take ownership of this... but the idea of TM taking ownership from static extension userscript store and optionally moved in the Userscript space would be an agreeable alternative and wouldn't rely on anyone's backend technologies but your own.

[derjanb]

Your custom crx you built for GF wasn't there after 2.5 days of publishing so I couldn't even try it out.

Sorry, I've moved some test related things to a new subdomain, that's why the link was unintentionally broken, but it's fixed now.

but the idea of TM taking ownership from static extension userscript store and optionally moved in the Userscript space would be an agreeable alternative

This would mean that I have to track every change of your HTML code. I don't know, but I think this also is not the right ownership.

But as I said: I'm fine with OUJS not implementing this.

[Martii]

track every change of your HTML code.

bootstrap classes which haven't changed for years and looking for "*.user.js" outside of the body user content.... woo too difficult for some. What could be done is a simple TM class we could adopt but the extension would need to find the install button. Too difficult again for some which is why installWith worked seamlessly with USO because it never changed. Anyhow it's up to you since your a peer engine and it's a highly specific TM thing that should always originate from TM. EDIT Plus engines know when the DOM's ready to do something rather than subject a client to a timing and event loop/trap slowing them down like the other site has added. So we are fine with that inconvenience over there. ;)