Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
Hey. We should discuss this sometime. Clearly bots that steal passwords or (potentially any other data on a computer) should be frowned upon. Should we take steps as a community to prevent their proliferation?
Atilla made a good point (more than one) that many users will use what their "cool friend" shared with them. However, when it comes to the forums, what should be done? It appears that capasha and atilla have been periodically checking releases or something for malicious code. (Correct me if wrong). Is this sufficient?
What about in the larger EE context? I don't think there's a whole lot of sharing beyond these forums that can really be accounted for. It'd be great if some systematic approach could be used. Probably the most efficient and productive overall is to make sure users are aware that they should never use programs given from the internet. But, given that, what should the reasoning be for bots supplied on the forums? "It's OK, just wait for atilla/capasha to clear it?"
I offered the idea of plugins (yet again) where all the bots would be given permissions less than regular code... idk what all the options are for sandboxing in .NET but IIRC file read/write is one example. This is slightly defeated by
A) since when do we agree on something
B) people will still be able to share malware outside of the forums eh
C) we have users who already periodically check
if nothing else, this topic is another reminder to not use bots unless you're really confident.
Offline
A plugin system would only limit creativity and productivity.
As with most issues, I think the proper option is to educate the end-users to be cautious with proprietary applications.
If there is an open-source application, whether it is on GitHub or another service, it would be advisable to download release artifacts from trusted build servers. (think AppVeyor)
If there is a proprietary application (source code unavailable) it would be advisable to run it within a sandboxed environment, for example, Sandboxie.
This would ensure that if the application were malicious in nature, it would be contained, and at the maximum, only account details would be potentially compromised - something the Everybody Edits Staff has control over.
*u stinky*
Offline
A plugin system would only limit creativity and productivity.
As with most issues, I think the proper option is to educate the end-users to be cautious with proprietary applications.If there is an open-source application, whether it is on GitHub or another service, it would be advisable to download release artifacts from trusted build servers. (think AppVeyor)
If there is a proprietary application (source code unavailable) it would be advisable to run it within a sandboxed environment, for example, Sandboxie.
more valid reasons why my plugins cannot come to be. :c
But yeah definitely should push the education. On what scale? I guess, that depends on who exactly uses bots these days? Do they all come here?
Offline
We're talking about little kids here, not adults who are typically more responsible when it comes to security.
There isn't a way of completely preventing little kids from downloading binaries when they're shared in the chat for example, but it may be worthwhile to put a reminder to be cautious.
Similarly, a notice could be placed above all Bots & Programming topics that contain a URL.
*u stinky*
Offline
have atilla/capasha check before approval
have topic for approval where all goes
**** ee we cant check in the game/prevent spreading so eh that part sucks
Offline
As already stated Sandboxie could be used. But then we have the part, using a bot need internet.
If internet is accepted in Sandboxie files could be stolen and uploaded/sent to the bad guy.
Offline
As already stated Sandboxie could be used. But then we have the part, using a bot need internet.
If internet is accepted in Sandboxie files could be stolen and uploaded/sent to the bad guy.
That would only be the case whilst the application is running within the sandbox, so it's pretty much entirely dependant on the security of other applications.
However, keep in mind you can limit Sandboxie to a particular folder, so it cannot access folders outside of it, this would be more reasonable as a container - it effectively has nothing to send.
*u stinky*
Offline
Everyone can trust my bots, since I dont know how to make a password and email stealer...
How to make one though :v
Thanks to: Ernesdo (Current Avatar), Zoey2070 (Signature)
Very inactive, maybe in the future, idk.
Offline
Sandboxing would just be a failsafe for software that would do harm to your computer yourself.
But in the OP also the possibility of password saving is made. Locally I personally see no problem, but who knows if it's stored online or whatever?
Offline
Your account can't be stolen if you only use bots that connect with your username and password instead of email and pass. A tutorial forum post and some pastebin should be enough.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
Found the reply
For instance we could have bots that work like Discord bots @ you fill out the details that you want to use and you could then get a token to use in place of username and password, this bot account wouldn't easily be accessible as a playable person and if done ingame it can be trusted by the owner who created the token. The bot would be able to assume all blocks of their owner while not containing any items on the account.
You will never be trusting anyone with your account, only access to a world.
Marten22dox is the one who shared the malware link. I guess the link is removed
No, marcoantonimsantos #
Thank you eleizibeth ^
I stack my signatures rather than delete them so I don't lose them
Offline
No, marcoantonimsantos #
oh, I didn't knew that, thanks
Let's face it, the average [EE] user probably won't bother with sandboxie/appveyor/whatever.
At most they will scan the bot in their antivirus of choice, which will half of the time pop a false positive, they are going to complain "OMG ITS A VIRUS DONT USE IT" and won't use it until someone checks the bot in the forums.
So basically, the safest way to protect the EE bot users is to have the executable checked by someone who knows how to do it.
Offline
There's essentially no feasible way of eliminating the spread of malware completely, especially not so in an environment where the majority of players are little kids.
As with some previous posts above, I think you're missing out on how to prevent malicious bots, and merely suggesting ways people could distribute non-malicious bots, which does not solve the issue of malicious bots being distributed in the first place.
You could create a bot on the cloud, but that doesn't stop people from linking to executables within chat and infecting non-suspecting 11 year olds, which has many more consequences than simply losing your account details.
Do you think it is practical for people to completely ditch executables in favour of online services? I don't, considering a large majority of programmers here are novices.
*u stinky*
Offline
Pls, just use only the ones that connect with username.
If it's about telling people to check on here to see if a bot is trusted, you could do something invasive like PMing every player on EE once a day for a week. Maybe get a mod to send some mail round and warn people.
I'll be sure to run anything I release through Atilla Software Securities, and get it endorsed. =p
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
You don't quite need to integrate it with username.
PlayerIO uses a temporary authentication token which is used within API calls.
The token expires in 5 days approximately and can be used within bots.
I have a working example of this within PlayerIOClient.Helpers.
*u stinky*
Offline
Pages: 1
[ Started around 1732731956.9325 - Generated in 0.187 seconds, 12 queries executed - Memory usage: 1.62 MiB (Peak: 1.82 MiB) ]