There are multiple scripts being used on almost every website. You need to find the one that pops up the paywall. Use NoScript or just unlock origin (I use both) and with some trial and error it’ll work just fine
It would only work if they specifically bundle the functions which cause the paywall in a separate file (it is very unlikely for this to be the case), and also relies on the assumption that the paywall is entirely front-end side, as well as the “default” content to be without paywall (as opposed to the default content being paywalled and requiring JavaScript to load the actual content).
Not a specific file but a domain. And yes, if the processing is done server-side then there is very little we can do about that. Note that I’m not asking one to disable every script on the page, just the specific script for the pop-up/blurring by the paywall
I think I understood what you were suggesting: try disabling the script tags one by one on a website until either we tried them all or we got through the paywall.
My point is that it’s very unlikely to be feasible on most modern websites.
I mention files because very few bits of functionality tend to be inline scripts these days, 90-95% of JavaScript will be loaded from separate .js files the script tags reference.
In modern webapps the JavaScript usually goes through some sort of build system, like webpack, which does a number of things but the important one for this case is that it re-structures how the code is distributed into .js files which are referenced from script tags in the html. This makes it very difficult to explicitly target a specific bit of functionality to be disabled, since the code for paywall is likely loaded from the same file as a hundred other bits of code which make other features work - hence my point that the sites would actively have to go out of their way to make their build process separate their paywall code from other bits of functionality in their codebase, which is probably not something they would do.
On top of this, the same build system may output differently named files after the build since they’re often named after some hashing of the content, so if any code changes in any of the sources the output file name changes as well in an unpredictable way. This would likely be a much smaller issue since I can’t imagine them actively working on all parts of their codebase all the time.
Lastly, if the way a website works is that it loads the content and then some JavaScript hides it behind a paywall then it’s much simpler to either hide the elements in front of it or make the content visible again just by using CSS and HTML - i.e. the way adblockers remove the entire ad element from the pages.
Most sites load no content at all if JS is disabled.
On a majority of sites all of the page’s content will be present at least for SSO. And you have the added bonus that they don’t ask for cookies etc…
I didn’t ask for JS to be completely disabled, but to disable just enough for the paywall to not crop up
How would your browser differentiate between the 2 scripts?
There are multiple scripts being used on almost every website. You need to find the one that pops up the paywall. Use NoScript or just unlock origin (I use both) and with some trial and error it’ll work just fine
It would only work if they specifically bundle the functions which cause the paywall in a separate file (it is very unlikely for this to be the case), and also relies on the assumption that the paywall is entirely front-end side, as well as the “default” content to be without paywall (as opposed to the default content being paywalled and requiring JavaScript to load the actual content).
Not a specific file but a domain. And yes, if the processing is done server-side then there is very little we can do about that. Note that I’m not asking one to disable every script on the page, just the specific script for the pop-up/blurring by the paywall
I think I understood what you were suggesting: try disabling the script tags one by one on a website until either we tried them all or we got through the paywall.
My point is that it’s very unlikely to be feasible on most modern websites.
I mention files because very few bits of functionality tend to be inline scripts these days, 90-95% of JavaScript will be loaded from separate .js files the script tags reference.
In modern webapps the JavaScript usually goes through some sort of build system, like webpack, which does a number of things but the important one for this case is that it re-structures how the code is distributed into .js files which are referenced from script tags in the html. This makes it very difficult to explicitly target a specific bit of functionality to be disabled, since the code for paywall is likely loaded from the same file as a hundred other bits of code which make other features work - hence my point that the sites would actively have to go out of their way to make their build process separate their paywall code from other bits of functionality in their codebase, which is probably not something they would do.
On top of this, the same build system may output differently named files after the build since they’re often named after some hashing of the content, so if any code changes in any of the sources the output file name changes as well in an unpredictable way. This would likely be a much smaller issue since I can’t imagine them actively working on all parts of their codebase all the time.
Lastly, if the way a website works is that it loads the content and then some JavaScript hides it behind a paywall then it’s much simpler to either hide the elements in front of it or make the content visible again just by using CSS and HTML - i.e. the way adblockers remove the entire ad element from the pages.
Thanks, I understand your point. Thinking about it, this might not work everywhere
deleted by creator