sticky: user scripts #75
Comments
|
Some sites are trying to set tracking ID by adding ?something after the img url I am using REDIRECTOR to strip those out: |
|
@crssi sometimes these are used as unique links and sometimes they are part of the authentication mechanism. e.g. Only users with the exact link are allowed to see the file or image. |
|
@publicarray thank you. The rule definition: [ { "pattern": { "scheme": "*", "host": [ "*" ], "path": [ "*.jpg?*", "*.gif?*", "*.png?*", "*.svg?*" ] }, "types": [ "main_frame", "sub_frame", "image" ], "action": "filter", "active": true, "skipRedirectionFilter": true, "paramsFilterPattern": ".*", "paramsFilter": { "values": [ "w", "h", "crop", "s", "q", "auto", "fit", "size", "v", "height", "width", "dl", "sigh", "displayname", "oe", "oh" ], "invert": true }, "title": "Filter%20rule%20for%20*" } ]RC also has "problems", but not in this case and this rule is the only rule I am using under RC. |
|
UTM usage: |
|
@earthlng & co - see pes10k/web-api-manager#75 re thwarting Page Visibility API and peter's comments. Can this be beefed up to cover the things mentioned?
while not really necessary from a privacy/security perspective, I'm quite keen on it. I came across it on a reddit thread about a month ago, and then this reddit thread reminded me I had it |
|
Clear window.opener script appears to be unsuccessful when tested at About rel=noopener There is another script which is flawless: noopener_by_default Edit by Thorin: but this new script has some issues: see earthlng's comment , so do not use, see the new issue #401 and wait for what we come up with |
|
note: FF59.0.2, using Violentmonkey (scripts are run @document-start) ❗ EDIT: kinda slightly messed up with temp JS rules in uM. With all JS allowed now and locked in, I fail both tests with clear window.opener "clear window.opener"
"noopener by default"The script says "@description blah blah blah. For Chrome only. blah blah", but I tested it anyway. Seems fine.
Note: for both scripts, cross-origin causes CSP console errors. There are no console errors for same-origin. I'll leave this in earthlng's hands |
|
FF59.0.2, using Violentmonkey as well here. |
|
Why would window.opener be a problem on same-origin? |
I assume the same is true for Violentmonkey and others. The greasemonkey wiki provides a code example to test if any if ('loading' == document.readyState) {
alert("This script is running at document-start time.");
} else {
alert("This script is running with document.readyState: " + document.readyState);
}I tried it numerous times and not once did I get an EDIT: thanks @mazesy for letting us know 👍 EDIT2: middle-clicking a link opens the tab in such a way that document-start scripts work correctly |
because of user-generated content on a website |
|
I'm not at all into coding, need to repeat. I just happened to run a test page, noticed a script apparently wasn't doing the job when another performed correctly. Javascript never disabled here. I'm not discussing, only submitting. I'm fully aware this could be a false-positive. No idea, really. |
yes, but its the same origin... isn't that quite normal by some web apps to pass some data to a new window/tab |
to clarify, middle-clicking lets a script (reliably?) run at document-start but it's not guaranteed that the script works as expected. Something fundamentally changed with webextensions vs legacy which means some scripts need to be rewritten to work with webextension user-script addons. For example the |
That explains why clear window.opener runs flawlessly with legacy Greasemonkey in ESR, OK About conceal history.length : impossible to determine its validity here considering I always get About Conceal window.name : seems to do the job considering I get, on dedicated JoDonym test page, Really odd, and triggers an alarm if it appears that scripts run by a legacy script manager run differently when applied with a webextension script manager. This would be a scoop. I repeat, running scripts with ViolentMonkey 2.9.1 (hence Webextension) on Firefox 52.0.2 (64-bit). |
|
Edited my post to clarify re JS running - I had allowed it, but forgot the cross origin one.
@mazesy The document run is in the script settings of the VM dashboard @earthlng 57+ users, we recommend VM. When I migrated to VM (I think this was around FF54 or 55) there were so many issues with mixing legacy and non-legacy apps (uBO/uM + GM caused lots of weird behavior such as direct images not loading - ask @grauenwolfe and @atomGit ). The three scripts required @document-start to work, and VM was the only one that worked (at the time). I don't know the state of GM now, but they were massively late to the party, even months later you still couldn't save scripts and stuff. Can you do your document start test in VM? |
So true... I had forgotten that! So then, concerning our Clear window.opener script, it appears I had as well not set its |
conceal history.lengthworks fine on both browserspy and jodonym. They are both run at document start in VM. STR
^^ Ditto for same script tested on JoDonym's "tab history" conceal windows.nameExact same thing, except I already had the JoDonym open in that tab (the one I had lots of history in), so instead I toggled conceal windows.name. The script works. noopener by defaultworks every time: is run at document-start: And as I type Tom just said it works as run at Default. I do not know what "default" means. conclusionclear window.opener needs tweaking for VM and it will work. Wiki can hold two versions, a legacy GM version and a 57+ VM version |
your test results clearly indicate that VM doesn't work correctly either. @mazesy
you need to click a couple of other links on that page to increase the number of pages in your history |
|
conceal history.length and conceal windows.name indeed both do it, but here both are set to Run-At -- [Default) ... and both of those scripts state by themselves Now, one thing I ignore with ViolentMonkey : does a script's setting pane prevail on the script's settings (when available) or not? I mean, if the script itself states // |
I had done that, aware. Opened several other tabs, reloaded BrowserSpy, Always got 1 |
that doesn't work. history is per tab, you need to open a couple of links in the same tab. |
|
if there's any chance these scripts will be modified at some point, i might suggest adding the update URL param to them and host them in an appropriate repo
far as updating scripts based on browser version, i don't know if that's possible, but it sounds like there may be a need for it ... OR, can the script itself determine the browser version and run the appropriate code maybe??? |
Oh, right. Gosh, so logic... testing ...Yeah, OK, with the script active, max is 2, otherwise it incements. My fault. |
Say what? On VM, with run @ document start, I just showed the two tests work, as does the new one. The only one failing out of all four is clear window.opener (edit, i.e in non legacy extensions) Edit: Oh, the very first test that showed that |
|
We have -- I have, anyway, here with ViolentMonkey on Firefox 59,
All three with |
|
Tom - make them run @ doc start. Default (from some quick searches) seems to be run at document end, meaning that as soon as the initial HTML document is ready, the script may be executed. I am not an expert, but content scripts can already be done and dusted before that, so user scripts can in those cases, not work. |
|
Surprise with |
|
I have nothing in the script. I changed it to run-at-end and it FAILS - for the last F time, you must use doc-start. Why do you think 3 different authors explicitly used |
|
@Thorin-Oakenpants , but are you on Firefox ESR or Quantum? |
|
I am on Quantum, why would I be testing VM and scripts on ESR? Please tell me you aren't doing all this on ESR |
|
No, no, Quantum Level Firefox 52 :=)
|
|
What does that mean. What FF version are you doing this all on? |
|
Firefox 59.0.2 ... x64 ... sorry |
|
Well FFS ... no wonder. You're using a 7 version OLD release (in terms of features, not security updates). FFS!! |
|
@Thorin-Oakenpants , I'm missing something: what's this 7 version old have to do here? I corrected: I'm running and running these tests on Firefox 59.0.2 64-BIT. |
|
In fact 52.0.2 isn;t even the latest ESR 2017-03-07: 52.0 - over a year old |
|
It's not 52, it's 59; me have mistaked numbers! |
Then why did you say you were doing it on 52.0.2. I give up |
|
Because I typed wrong, I had the 2 from Firefox 59.0.2 in mind, I guess! |
|
This sticky has become a massive useless thread now on a side issue of how VM uses run-at. END of STORY - use doc-start. I don't care HOW yu do it. Its on you. What we need to do it decide if earthlngs script can be changed to work on 57+ VM, or we just go with the new one, or point to an extension (there are several from memory), and edit the wiki accordingly. |
|
And in order to move forward, we just need earthlng to decide what he wants to do |
|
@Thorin-Oakenpants it's getting late, indeed (in EU anyway). As I said above,
There's one problem and one only: I'm off to bed. Sleep well, sweet dreams. |
No. VM stable is currently 2.9.1 (or 29.1 in your typo) and the script DOES NOT WORK (on 59.0.2). It does not |
|
apparently, without looking at the code, just based on your test results, VM uses a different way to inject the scripts and that's why the user-scripts work in their current form. However that method comes with a different set of problems. For example I'm pretty sure the window.opener script doesn't work because the demo page is hosted on a domain with strict CSP rules. That means you can't rely on your user-scripts to work on potentially malicious pages, at all. re: the 2 different scripts: noopener_by_default works by modifying the links on the original page, while "my" user-script works on the "new" page. noopener_by_default has several issues (1) it's less efficient because it modifies all links targeting a new tab, (2) can easily be tricked to not modify a malicious link, (3) and maybe most importantly, it doesn't clear window.opener when a page uses window.open(). There might be other problems as well, fe. a form can also have target=_blank and it's possible that a page opened that way could also have access to window.opener. If it does then noopener_by_default does nothing against that, either. It can also break a page because adding rel=noopener to a link apparently opens the page without the referer header. |
What's this useless nagging? Of course it's VM 2.9.1, of course I meant There's one problem and one only: I brought up this issue, indeed, which makes my typos and language issues irrelevant. @earthlng , |
Wot. That was to clarify so there was no more misunderstanding. You're reading too much into what is just TEXT (which does not emote well). Nothing was meant by it |
Everyone, anyone having read the thread understood what I meant. It was late, for us all. Further emphasizing would bring this very comment useless as well. Let's stay focused on the scripts and on what appears to be a ViolentMonkey interference. |
Who started dabbing? |
A threat as a last resource. Well just do it then.
You rub as well, and not only me. Calm down or block, it's up to you. But I never adapt to threats and, should I be forgotten here that I'd forget it as quickly. Think about it. |
|
@earthlng, could you take a look at this please #401 (comment) |
|
Wiki page now asks for further submissions on scripts to be a new issue. This sticky is over! |
Use this issue to suggest scripts for our wiki section Further Hardening: Extension Scripts. We're looking for scripts that enhance privacy and security, and block tracking and fingerprinting.
Please try to stick to general/global or major site specific scripts (such as google), rather than obscure sites no one really cares about.
Please note: The comments here will be regularly cleaned out to keep this sticky usable
The text was updated successfully, but these errors were encountered: