Re: @ujjwalgattu:

Update your .user.js engine, whatever it may be, and then retry only once. You are limited to the amount of installs as a precaution against faulty .user.js engine updaters.

Re: @xanderten50:

Is there any way to reinstall the script?

Yes... do not tap the install button too many times successively. Wait about 5 to 10 minutes (e.g. "a few" which could change should the need arise again) then you may single tap it again. It's part of a DDoS prevention that resulted from a Tampermonkey (TM) .user.js engine flaw. Since this message is about 2 days old you are clear.

Re: @jsutilities:

Any suggestions?

Usually most people still load their own copy, at whatever version they want is the key so you don't have to guess on major changes, and set the noConflict option. See here. This assumes you are running in the Content Scope with @grant none.

https://github.com/Ticki84/Ticki84.github.io/blob/master/JVCSticker%2B%2B.user.js

You may at your leisure fork it on GH as their TOS allows it but this can't be redistributed on OUJS.

Removing.

Thanks,
OUJS Admin

https://github.com/Ticki84/Ticki84.github.io/blob/master/JVCSticker%2B%2B.user.js

You may at your leisure fork it on GH as their TOS allows it but this can't be redistributed on OUJS.

Removing.

Thanks,
OUJS Admin

Just a quick note... GitHub was inaccessible earlier today. Everything should be okay now.

WTFPL is not a valid OSI license. Please correct this to a non-public domain type license.

Testing... logged in.

Back to original GH clone... reinstalled all deps again from scratch... and it's letting me in. :\

Am able to log in now.

Re: @xenofungi:

As for the GM_addStyle, I still can't get it working in firefox.

Possibly because you left the @grant none in? That line usually overrides any other grants if present.

You've had over a month to fix this and a few weeks since the last reply. Applying the TOS default action. Bye.

Re: @discon:

Should read about CC0 here... still not acceptable.

Thanks.

Greasemonkey Port 3.9.0.1rc1pre-sm.xpi is available now at the SF file repo.

Thank you. :)

OUJS Admin

Please reread about OSI Approved only licensing here.

You have a very short period to correct this before you and your script are eligible for removal.

Please remedy ASAP and thank you for your cooperation.

OUJS Admin

Btw you seem to have this issue on your other 3 scripts.

Thanks for attending to this as soon as possible.
OUJS Admin

Please reread about Public Domain here.

OUJS Admin

Re: @Vadorequest:

Vadorrequest/fb-adblock-timeline#3

Working for me within the attack prevention guidelines set in place. e.g. It would seem that your TM is still majorly flawed with hitting the install route more than once possibly with the script updater routines.

See also #957.

Re: @shush:

Appreciate you giving it a try.

So I have a question... looking at http://www.shush.se/index.php?extension and the settings for http://www.shush.se/index.php?settings with "Force Extension" are these two related to the same thing? e.g. is the site itself trying to hotlink in this Userscript when enabled ??

Completed... ~18 minutes offline to do the snapshot.

Re: @shush:

keep in mind this script has been on here long before the fiasco started (unchanged)

TM has had an issue with caching and pulling full script source going back to Userscripts.org days from many years before this script was published here. When it was first determined with usoCheckup, and AAU from @sizzle, we added in caching headers at that time to attempt to control it via the browser... some of it is Chromium/Chrome too. So if anyone isn't up to date then there is a higher chance of multiple site hits happening. Adding some simple precautions to a known script that continually hits OUJS would be a wise thing to do. We've blocked brute force attacks for every Userscript as our precaution.

however there are no iframes used anywhere and the player simply will not load in an iframe.

Just wrote an ancillary .user.js and a brief extension to make it load in an iframe and it works well... but natively the player loader script attempts to redirects out of a framed element when possible. The framing also does not have to include the Flash player and your current @match will inject into those frames as well. If the .user.js engine is flawed then your script will be pulled from OUJS x number of frames times.

and is completely independent

If a system/platform has been compromised in any way this is not true... better to be precautious with some simple checks. That's why @noframes exists in the first place besides easing up some common coding. You can't guarantee that your script is the only one running on this @matched site and you can't guarantee that shush.se doesn't have some live option that injects framing on the fly.

If you want a more accurate raw install count I would suggest reading this. This will cover up publicly if there is a .user.js engine issue but we'll still be able to track when needed especially with our brute force prevention.

Time for another backup... should be about 20 minutes later this evening the 24th of July, 2016.

Re: @shush:

The traffic spikes on the weekends. Monday and Tuesday it spikes as well.

It spikes constantly every day of the week... the raw installs of this script are the counts up top here on OUJS. Provided @sizzle gets back to me on moving the install stats to once daily per IP based and locally on the VPS all of these numbers would be invalidated... however raw installs shows how many times someone is accessing the .user.js URL portion of any script. We are currently curtailing this with the brute force prevention mentioned by @visionsofleo and some others.

the player already has an iframe breaker

There currently is no window.top reference in this .user.js so if your @match is too wide (inclusive) and multiple iframes/frames exist on the site that too can "inject" the script in multiple locations. In tandem with a .user.js engine flaw (most likely Tampermonkey as the retry routine was incorrectly and badly "borrowed" from usoCheckup and too aggressive). Since derjanb hasn't been communicative lately about his meta check routine I can only presume that he hasn't spent any time on it. I am rarely in Chromium/Chrome so I haven't retested this since that issue report.

this should isolate the issue to tampermonkey

Pointing the finger at that engine might still be the main issue however I still think that your script could use some tender loving care (TLC). I didn't remove it back in April when the fiasco started/continued with Tampermonkey (TM)... but as you may have noticed I put in the @updateURL and version bumped to maintain the integrity of OUJS... otherwise it would have been deleted (not removed) until the situation with TM calmed down a bit. Your script was and still is the number one "raw installed" here on OUJS and it's not just a matter of popularity as some engine somewhere on some client(s) is pulling source every page load/document start (or worse every iframe/frame) load.

My point to you is that you do not have a frame check in this script and most likely there is something that you can do to improve your users experience with it. Personally I would start off with a @noframes and even put the window.top check in for older engines that don't support @noframes in the UserScript metadata block... since you know how your script works better than anyone else with these "certain videos" you can tell if it's still working with the current @match values... or if those keys needs to be refined a bit.