Lobbydev meeting minutes 2012-02-26 - Page 2

Lobbydev meeting minutes 2012-02-26

Archive of lobby developer discussions

Moderators: Moderators, Lobby Developers

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 02 Mar 2012, 14:21

What koshi said.

Also as Licho pointed out, there are many ways to abuse the system, preventing abuse is the job of the server not the client or protocol. It would be very simple to make server detect cyclical forcejoinbattle.

You can make your own lobby opt out if you want, since there is no enforcement. It could be done in such a way as to guarantee that 90% of forcejoins are successful even if the user is stupid..eg. have a setting which enables a popup appear and prompt user if they agree, with a 10 sec countdown to join in case the player is idling.

So..in other words it's quite flexible, which is good, if it turns out that people are denying every forcejoin they get prompted for..well then you remove the option and conclude that players are too dumb to have that kind of choice, no harm done.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 02 Mar 2012, 16:05

koshi wrote:Reread the minutes. The system is already, albeit hackish as always, opt-in.
Summary ___
Proposal 0 (LISTCOMPFLAGS): accepted as on etherpad
Proposal 1 (FORCEJOINBATTLE): accepted as on etherpad, but needs a good explanation/description to be added to the protocol doc
Proposal 2 (USERCONNECT): decission postphoned (casue no time left for discussion/explanation); also needs a good explanation/description to be added to the protocol doc
Proposal 3 (REQUESTDOWNLOAD): postphonehponed
a table that explains special CPU values has to be added to protocol spec (sheep doing it?)
If this is incorrect and there is a hackish opt in system instead could the summary be ammended? The pastebin of etherpad indicates client the must comply, and that there is no choice in the matter.
0 x

User avatar
koshi
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-02-26

Post by koshi » 02 Mar 2012, 16:17

You didn't understand what opt-in means here: never joining a host that utilizes the system -> never getting a FORCEJOINBATTLE command.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Lobbydev meeting minutes 2012-02-26

Post by jK » 02 Mar 2012, 16:23

But as said, it doesn't make sense in a view of a clean protocol, that a client _must_ comply. In such a case the lobbyserver should move the user itself, without such a comply.
AF wrote:Not to mention that with FORCEJOINBATTLE I could setup a DSD autohost filled with 3 or 4 bots, but when you join it, the autohost sends FORCEJOINBATTLE to another battle, which then sends you back and forth, switching you between the two battles before you can leave.
Just limit the force movements per timespan?

PS: Shouldn't hosts that use FORCEDJOINBATTLE be visualized by the lobbyclient similar to NAT ones?
0 x

User avatar
koshi
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-02-26

Post by koshi » 02 Mar 2012, 16:36

jK wrote:But as said, it doesn't make sense in a view of a clean protocol, that a client _must_ comply. In such a case the lobbyserver should move the user itself, without such a comply.
On the contrary. It makes perfect sense not to special case this battle join for clients that understand it.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 02 Mar 2012, 23:51

koshi wrote:You didn't understand what opt-in means here: never joining a host that utilizes the system -> never getting a FORCEJOINBATTLE command.

This assumes that the autohosts in systems like lichos juggler setup are the only clients in the server that will ever send those commands.

Whereas anyone can pull up a traffic window as a host and issue the command, anybody with basic programming knowledge can modify one of the newer lobbies, and any bots only need to implement enough of the protocol to open a battle and detect player joins to exploit the weakness in the design.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 03 Mar 2012, 02:07

AF wrote:
koshi wrote:You didn't understand what opt-in means here: never joining a host that utilizes the system -> never getting a FORCEJOINBATTLE command.

This assumes that the autohosts in systems like lichos juggler setup are the only clients in the server that will ever send those commands.

Whereas anyone can pull up a traffic window as a host and issue the command, anybody with basic programming knowledge can modify one of the newer lobbies, and any bots only need to implement enough of the protocol to open a battle and detect player joins to exploit the weakness in the design.
For the sake of argument, let us assume someone was out to get you and chose to abuse forcejoinbattle, or more likely, triggered that scenario by human error.

How to prevent it? As I already pointed out, the server could detect cyclical joins. If this is not enough, any lobby could do that as well.

Thus the design is valid. Implementation is up to every lobby like any other command.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Lobbydev meeting minutes 2012-02-26

Post by hoijui » 03 Mar 2012, 13:22

protocol change done in final document/format now (still in a branch):
https://github.com/spring/LobbyProtocol ... 17381b9747

cheesecan already supplied a patch for SprignLS. i will put that in main repo (hopefully before meeting tomorow evening).
0 x

User avatar
koshi
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-02-26

Post by koshi » 03 Mar 2012, 14:13

I ask anyone who thinks he should have, but has not, received a reminder via pm today, to contact me.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 03 Mar 2012, 19:04

Cheese, that just starts a cat and mouse game where the next step is to host a second game, forcejoin, then close the first, so no cyclical join pattern exists since the user never goes back to the original battle (which no longer exists).

You shouldn't have to add checks into these things, security through design is a better choice than security through excessive checks and validation.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 03 Mar 2012, 20:32

Relying on the user to accept or reject invitations is not a form of security. Additionally, anyone trying to do this kind of abuse would be banned.

If you wanted to abuse the system there are dozens of more effective ways. A while ago there was a way to DoS vulnerability on the server that was accidentally discovered. Previously I discovered a way to crash an on-going spring game which was also accidentally discovered. There are dozens of more serious threats you could be minding so stop trying to overengineer what is a clean (not hackish), flexible command because of hypothetical and unlikely scenarios.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 04 Mar 2012, 13:38

Its not over-engineering, its simple, the command is flawed from a security perspective because it assumes that the host is trustworthy. Its fine from a political point of view in that its easy to implement and fits in with the needs fo several parties who've already implemented similar systems.

It should take ~2-3 hours to build a proof of concept from scratch, possibly minutes if your a lobby/autohost developer.

Invitations is far more secure in that the worst case scenario is fixed by ignoring invitations, no actual action or consequence occurs unless the user specifically wants it to, and users can't be forcibly moved from battle to battle unless they want it to. Its easy to implement shares most of its implementation details with the current proposal, and does not make the assumption the host can be trusted.


Ironically, the best way of fixing the current command, is to pop up an accept/refuse dialog when the lobby recieves the force join command, essentially duplicating my proposal with nonstandard behaviour, giving users exactly what I proposed but with reduced flexibility, and a mishmash of confusion from players when a user is expected to move from A to B but either clicks refuse or takes their time

If you wanted to abuse the system there are dozens of more effective ways. A while ago there was a way to DoS vulnerability on the server that was accidentally discovered. Previously I discovered a way to crash an on-going spring game which was also accidentally discovered. There are dozens of more serious threats you could be minding so stop trying to overengineer what is a clean (not hackish), flexible command because of hypothetical and unlikely scenarios.
Paraphrase: Its okay to add exploits and security issues to the server, because I can think of even bigger exploits and bigger security issues present already, therefore I declare minor exploits to be clean and safe and shall ignore the problems pointed out.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 04 Mar 2012, 14:32

That is where you are wrong again, hosts are trustworthy and this command poses no threat to lobby security.

I don't see any point in discussing this further as you've clearly lost track of the real goal, which is to meet demands of the community, not to bicker about implementation details.

The only infinite loop here is your inability to productively contribute instead of just complaining. This is a behavior I have observed in pretty much all of your recent posts. Whether it is a lobby, website or protocol you always appear to complain! BAH
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 04 Mar 2012, 16:44

Its simple. I pointed out a fundamental flaw and offered a similar fixed alternative. You ignored the consequences of the flaw.

It would appear logical rational discussion with you is not possible unless the topic is something that benefits your point of view.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 05 Mar 2012, 14:01

If you read the log again, you will see it was already considered at the time of the meeting. I don't have any vested interest in that command btw.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 05 Mar 2012, 15:05

Cheesecan wrote:If you read the log again, you will see it was already considered at the time of the meeting. I don't have any vested interest in that command btw.
Hoijui wrote:cheesecan already supplied a patch for SprignLS. i will put that in main repo (hopefully before meeting tomorow evening).
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 05 Mar 2012, 15:21

That patch isn't really used, and probably won't be needed because of "new" say. I am the only person who even bothered to reply to you, what do I get in return? Some bs about not listening to anything that is not in my point of view. From now on I'll just do like the rest and ignore you.
0 x

Post Reply

Return to “Lobby Meeting Minutes”