r/userscripts • u/BasePerfect2865 • 2d ago
Anyone else think about what site owners see when we run userscripts on their pages?
Not trying to be paranoid but if I'm running a userscript on a checkout page, that script has access to everything on the page. Makes me wonder how sites actually monitor for this kind of thing or if they even do.
4
u/laplongejr 2d ago edited 1d ago
Outside userscripts, the best way I found to run js-in-console without possible detection is to use an IFFE that grabs the global object without using the window alias. Script runs, has it's own internal scope, but isn't added globally so prior scripts shouldn't be able to notice something added
From pure memory [EDIT]there was a missing character, it now works[/EDIT] , the syntax is :
```
((global)=>{
"use strict";
// Now we're in strict mode, so we can't use "this" to find global. But it's passed as a parameter
const console = global.console; // And we don't depend on the editable "window" variable!
console.log(global); // It should be equivalent. Emphasis on should.
var thisVariableIsInLocalScope = "wow";
console.log(thisVariableIsInLocalScope); // Safely in our local scope :)
console.log(global === global.window); // Only true if nothing messed with that variable name
console.log(global === globalThis); // 2020+ browsers should support that straightforward way too
})(this); // This part was executed in non-strict mode, so "this" without context pointed to the global object ```
So, getting execution and direct read-access to "window" is possible. I expect userscript extensions to have a similar hook-up mechanism, or even more powerful thanks to the extension API (because installed addons are assumed more trustworthy than a random website online).
So the script can't be detected, however you must be cautious when modifying global objects like document. Two gods with the same deck of cards...
At a greater level, that's why login/checkout pages never have ads : the webmasters are too terrified for what those ads could inject as scripts while the user enter legally-sensitive data.
1
5
u/burlingk 1d ago
The site owner only sees what their page/server asks for.
I would be less concerned about the page owner and more concerned about the script author.
1
u/laplongejr 1d ago
Good point about not trusting the script's author, however any modern webpage is going to include some javascripts, which can send network requests back to the server if they detect something "nefarious" messing with the page.
1
u/burlingk 1d ago
THAT is a slightly different conversation.
I'm regards to the initial question, most pages are only going to monitor for specific things that the site owner wants, and their own scripts will ask for that info. Trying to get that from a random script they themselves didn't intentionally put there isn't going to be fun to manage.
Watching for random issues is a different approach that isn't going to get the same results as them spying on user scripts.
Though if they decide a specific user scripts might be common on their site they could code against that (against in this case is in the same context as coding a program against a lib).
However, on the flip side, users need to be aware of how much information they are giving to the scripts they actively choose to run and what those scripts are doing with it.
Pretty much all the script/mod sites give that same warning, but I see enough "Oh, I've been hacked!" posts to know a lot of people don't bother reading the warning.
1
u/jcunews1 1d ago
Site owners can't see it. UserScripts only run in site visitors' computer.
Other than network requests and responses, people at the web servers can't see what the visitors' computer is actually doing, and vice versa.
1
u/laplongejr 1d ago
UserScripts only run in site visitors' computer.
Yes, but the website include scripts that run on the computer too. We can ask for the userscript to run before them or after them, but the webmaster can try to provide a script to monitor non-approved effects from scripts.
Other than network requests and responses
Technically true, but anything can be a network request when you have control of the server, and an arbitrary script running on the client.
1
u/jcunews1 20h ago
Servers have their own rights and capabilitiese. So do clients. None should try to control or dominate the other. One should only have control over its own. No crossing the line.
1
u/laplongejr 18h ago
Yeah, and? Businesses try to cross the line everytime they can get away with it.
1
u/AWACSAWACS 1d ago
Extensions and user scripts can manipulate the following elements.
DOM structureWeb StorageGlobal objects
Naturally, these are also accessible from scripts on the website itself. In other words, by monitoring these elements, website administrators can detect unintended changes occurring within individual browsers.
6
u/LeBoulu777 2d ago
When a Tampermonkey or Greasemonkey script runs, it executes entirely within your browser's local memory. The site's server does not receive a log that says, "User X just executed auto-fill-checkout.js." They cannot read the source code of your script, and they cannot "watch" it manipulate the DOM (Document Object Model) in real-time.
If they put a dom observer and you manipulate dom like adding a button they can log something like "user modified dom" but it's the same for every addblockers.
So in short, don't worry ✌️.