-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: Detect Tampermonkey and/or installed scripts and change some page content accordingly #1034
Comments
...
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 When, and if, #53 occurs is when this could be done server side. |
Assuming that OUJS implements this via a |
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. |
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. And BTW the Greasyfork implementation can be found here. It simply switches a button text. |
I am not an OUJS developer, so please take my opinion at face value. In concern to your last line; |
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
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.
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. |
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. |
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. |
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. |
@derjanb |
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.
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. |
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. ;) |
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
The text was updated successfully, but these errors were encountered: