Closed uBlock-user closed 7 years ago
Thanks for your report, I'll have a look.
OK, those banners can be blocked with uBlock Origin, every other time it sends you to a block page... Do you have a solution for that?
Read again, those two things are already blocked. Your script loads them. If I disable the script, they don't appear.
This is not about the block page, this is about the script undoing
uBO's cosmetic filters which block them.
AdBlock Protector script ON - https://i.gyazo.com/53e84afe3ce2458c78f8ad4048b06047.png
AdBlock Protector script OFF - https://i.gyazo.com/c52335ebefd0809873e13ed82a8828ad.png
See the difference ?
Besides these two, when I right click, open the context menu and click on "Block Element" which is uBlock's option, the element hiding selector mod won't open because of the script.
^ That happens too
Hi, I figured out what's going on. a.crashScript
seems to break uBlock Origin's element picker. I have commented out calls to this function for now. This is fixed in 6.44.
I was confused because my cosmetic filter was not on, and I see the banner no matter what. Also, every other time it sends me to the block page, does it happen to you? Which custom filters are you using?
Also, every other time it sends me to the block page, does it happen to you?
Yes, that's the most nastiest thing I'm facing with the website since a long time.
I'm using :
8muses.com##.a-image
@@||jsdelivr.net^$domain=8muses.com
8muses.com##.top-warning
@@||ampproject.org^$image,domain=8muses.com
8muses.com##script:inject(abort-on-property-read.js, _$_eb9c)
||$third-party,domain=8muses.com
@uBlock-user
OK, I'll see if I can detect keywords and do an auto-refresh.
I see which script is doing it, but patching it breaks images. One day... one day browsers will support onbeforescriptexecute
.
For now, only one website is using a.crashScript
hack (it does have the side effect of breaking uBO element picker, but that website is tested and everything else works well), I disabled all other calls that are copied from AAK.
8muses.com##script:inject(abort-on-property-read.js, _$_eb9c)
^ That one partially fixed the block page issue, for me, the block page only appears when I'm browsing the home page, but when I'm viewing images of a comic back and forth, it doesn't.
One day... one day browsers will support onbeforescriptexecute.
Can you leverage chrome.webRequest.onBeforeRequest listener ?
@uBlock-user Looks like that is the case without this rule. That variable is never defined.
@X01X012013 Can you use chrome.webRequest.onBeforeRequest listener in place of onbeforescriptexecute
?
@uBlock-user Thanks, I'll look into it.
I added auto-refresh so block screen will be "skipped". You will only see it for less than a second. I also added 8muses.com##.top-warning
to my List, as far as I tested it, other rules seems redundant.
Alright, you might as well close the issue now.
Looks like chrome.webRequest.onBeforeRequest
is only available to extensions, and Userscript can't access it.
Thanks again for your report. I'll close this issue now.
@X01X012013 Tampermonkey can use it since v2.4, so can you leverage it via TM ?
FYI, it appears TM and VM both have the permissions to use chrome.webRequest
and chrome.webRequestBlocking
Do you have a link? I couldn't find anything about it...
link to what ? I found about TM and VM's permissions via their extension manifest.json files. I don't know how to leverage them into JS though, sorry.
@uBlock-user
I'm not exactly sure how extensions work, as far as I know, there isn't a way to block in-line script with Userscript except the a.crashScript
hack.
Hey @derjanb, can you enlighten us on how to use chrome.webRequest
and chrome.webRequestBlocking
API in userscripts ? TamperMonkey supports these and has permissions which can be found in the manifest.json of TM, so we're wondering.
I'll reopen this issue since the discussion hasn't finish.
What we really need is intercept loading of the main document and modify it. Subsequent request can be blocked by editing XMLHttpRequest
constructor.
I'm a bit busy lately, I'll have another look at this when I have time. The adblock detection script is highly obfuscated, but I think I can find the way to properly fix this.
Alternatively, uBO users can simply add these filters and forget about it :
||8muses.com^$inline-script
@@||8muses.com/comix/picture^$inline-script
@uBlock-user I was thinking about that 👍 Added to my List.
Also blocking inline-script neutralizes the need to inject cosmetic filters, so remove any cosmetic filters you added for 8muses too.
@uBlock-user Yes, I did that.
btw pornhub.com
's launching popunders based on a cookie check just like hanime.tv
was doing. Can you look into that ?
@uBlock-user
I don't know how they did it, but it goes right through my a.filter()
. I Googled the script, it sells for like $900 per year, definitely some solid stuff. And they seems to be customized for each site so a generic solution isn't possible (or at least very hard). For pornhub.com
, the solution is:
if (a.domCmp(["pornhub.com"])) {
//NSFW! Patch open()
a.win.open = function (arg) {
if (arg.includes("pornhub.com")) {
a.win.location.href = arg;
}
};
}
It's added to 6.49.
@X01X012013 Actually, the alternative to this solution is pretty simple. Delete, FPSRN
named cookie and the popunders will stop. I wonder if you can block cookies for a website in JS as in don't allow the website to put in any new cookies, that can used against such a script. Thanks for the quick fix man.
@uBlock-user
For locking down a specific cookie, it is not impossible, but it's very complex.
Locking down all cookies is simpler, but not simpler than my solution above.
I'm wondering why uBO doesn't have a $no-cookie
or (cookie-inject.js, name, value)
Locking down all cookies is simpler, but not simpler than my solution above.
That would be preferable as in a consistent solution. Pornhub dev is known to stalk these issue trackers on github and make new changes every once in a while. That's why I would prefer to block all cookies from pornhub.com
from entering my browser if possible via JS. Your solution is considerably solid, so it would be difficult for that guy to bypass this one, we'll see what he does further.
uBO doesn't have the scriptlet because gorhill hasn't added it or given much preference to it yet. He simply did the opposite though, he sets the cookie value of FastPopSessionRequestNumber
to a higher number to defeat the script which also works, but the Pornhub dev introduced another cookie named FPSRN
, so're back to where we started, that's why I would prefer to block cookies once and for all via scriptlet to end this game of cat and mouse.
I don't see how locking down all cookies is better since it is detectable, and can break other things.
I currently allow the web page to detect my tampered open()
, but it's just a switch flip to make it undetectable.
Note for devs: Activate a.protectFunc()
and return a fake window
object.
Yes, there is still ways around my open()
even if I activated a.protectFunc()
, but the way around locked cookies is easier.
I have to say we'll never end this cat and mouse game, there is a way around every solution, there is even a way around Yahoo's server room door. Our goal is to make a solution that will take a significant amount of work to get around.
I don't see how locking down all cookies is better since it is detectable, and can break other things.
I'm talking specifically about pornhub. Blocking all cookies will only stop you from logging, everything else works fine and will deter the dev from introducing new cookies and stopping that would force him to come up with a new strategy. Basically we're plugging that hole(no pun intended)
I have to say we'll never end this cat and mouse game
Oh believe me, it would end, if the dev is forced to take a drastic action and change the entire outlook of the website which a dev will rarely do, it's not worth his time, besides, pornhub is a high profile porn entertainment website and the dev makes millions as not everyone makes use of adblockers and userscripts, only handful do and he's not gonna change the entire website just to compete with few folks who intend on blocking his measures.
Well, they can just tell you if you don't enable cookies you'll get pop-up every click. It's like 3 lines of code.
If you really want, you can set it in your browser settings. And for stopping tracking, your session is destroyed when you exit incognito mode anyway.
(It's in Chinese but it should look the same)
From my JavaScript experience, I think my fix is more of a pain to bypass, because LocalStorage is a drop-in replacement for cookies.
I know about that, I am hoping if I can kill it with JS then that's good enough for me, otherwise ultimately if it comes down to blocking site cookies via the browser, I would do it. It's a matter of preference for me. Your fix is solid as I mentioned before, so we will wait and see if something new comes up.
Well, I can tell you how, but I don't really see the point of putting it into AdBlock Protector.
// ==UserScript==
// @name Block cookies and/or LocalStorage
// @version 1
// @description try to take over the world!
// @author X01X102013
// @match http://*.example.com/*
// @grant none
// @run-at document-start
// ==/UserScript==
(function () {
"use strict";
//Block all cookies
Object.defineProperty(document, "cookie", {value: ""});
//Block LocalStorage
delete window.localStorage;
delete window.sessionStorage;
delete window.Storage;
})();
Hey @derjanb, can you enlighten us on how to use chrome.webRequest and chrome.webRequestBlocking API in userscripts ? TamperMonkey supports these and has permissions which can be found in the manifest.json of TM, so we're wondering.
@uBlock-user The webRequest API is used only internally by Tampermonkey and there is no way for a userscripts to access it. If you could specify an API how would it look like? What functionality would it provide, that can't be done with *blocker extensions? Please consider that the communication between userscripts and the Tampermonkey main code is asynchronous. This means everything that should be done with the webRequest API needs to be communicated to the main code before the web requests are happening.
@derjanb Hi, thanks for replying 😄
If you could specify an API how would it look like?
TM_onBeforeRequest(callback)
Where callback
takes in the URL of the request, if callback
returns true
, this request is blocked.
TM_onAfterRequest(callback)
Where callback
takes in an event object, and can modify the response text and statue. I'm not sure if this is possible, I'm not very sure how extensions work. Looks like HTML is parsed while loading, maybe we need another API like TM_onBeforeHTMLParse
?
What functionality would it provide, that can't be done with *blocker extensions?
TM_onBeforeRequest(callback)
allows RegExp or other complex filtering logic. This would be the answer to detection script changing its name automatically every day.
TM_onAfterRequest(callback)
will allow patching in-line script, which isn't currently possible on Chromium based browsers. And when uBO blocks in-line scripts, it either blocks all or none. This API will also allow modifying XHR responses, uBO only allow redirecting to empty responses.
This means everything that should be done with the webRequest API needs to be communicated to the main code before the web requests are happening.
Maybe a @grant delayFirstWebRequest
statement that will cause the webRequest for the main HTML to be delayed until TM_onAfterRequest(callback)
is called?
@derjanb Hi, I asked that question on @X01X012013's behalf. I'm not prolific in JS and writing userscripts as he is, so better answer him, thank you for taking your time.
Also
The webRequest API is used only internally by Tampermonkey
For what purpose ? If I don't install any userscript in TM, TM won't have any internal use for using webRequest API, am I correct in presuming that ?
@uBlock-user I think the permissions need to be listed when compiling the extension, so if you ever need it, you would need to ask for it when installing.
FYI, pornhub and others are using a script called UAParser which fetches OS name , browsers name, plugins and all that shit and also creates popunders. Need to lock that variable.
example pornhub.com##script:inject(abort-on-property-write.js, UAParser)
Can be used as an alternative solution
TM_onBeforeRequest(callback) Where callback takes in the URL of the request, if callback returns true, this request is blocked.
Maybe a @grant delayFirstWebRequest statement
As I said the communication with the main code is asynchronous and it's not possible to pause a request and continue it later. When the requests happens all information whether to cancel or continue the requests needs to be sent to the main code already.
So it would only be possible to setup something like regular expression based rules whether to block, redirect or stop a request.
@derjanb Is it possible to not redirect, but to change the response received? And can we do this for the main HTML file?
@jspenguin2017 @uBlock-user If you're interested, please check https://github.com/Tampermonkey/tampermonkey/issues/397#issuecomment-299949037 regarding a draft implemented that allows the use the webRequest API at user scripts.
an iframe adbanner placeholder, adblock notice appears on the extreme left side which was already blocked by an appropriate CSS selector via uBlock as long as the script is running.
Besides these two, when I right click, open the context menu and click on "Block Element" which is uBlock's option, the element hiding selector mod won't open because of the script. Happens in both TamperMonkey and ViolentMonkey.