There is a crap-on system for a reason.
But who puts a function that grabs arbitrary links provided by the server? That's like having some sort of function that puts itself directly into eval for "convenience" albeit probably not THAT bad but close.
Why would you even need that functionality (to go to ANY URL from a client mod). If anything, the clientside mod should always use some sort of base domain (like example.com) and perhaps would only tell the client to go to a specific path in that domain (like example.com/bleh, the server would send the client "bleh"). Although there's always the chance for XSS if your site is also vulnerable to that and then someone could craft a link to one of your pages.
damn straight, you need filtering.
simple: if the server host has the custom add-on, they aren't gonna host it somewhere specific (except maybe rtb) (say, that's a good idea, share rtb add-ons) they're gonna host it on their own private server, and if the creator of the convenience mod (by convenience mod, i'm referring to those kinds of mods that allow the server to do stuff on the client, like shaking their screen) were to limit it to some stupid domain, it would be totally useless.
the solution is for the convenience mod to, upon receiving a url open request, pop up a gui that says "hey brah do you want to open this url??? like, don't put your password in and stuff becuz phishing"
but a lot of people aren't bright enough for that
and a lot of people aren't checking to make sure people are doing that
and yes, there is a crap on system, but
A: it would require a lot of effort to discover it and ban it if it was a private convenience mod (find the mod, experience the exploit, reverse engineer the exploit, report the mod to badspot. at least a 2-3 day turnaround, longer if the first people exploited aren't coders and don't know what to look for.)
B: badspot doesn't just spend his day sifting through add-ons for exploits
C: people aren't spending their days sifting through add-ons for exploits so they can report them