[wTf|beautifulNihilist]

I do not like the fact that I trust your judgement enough to follow it.

You're asking for faith, and we've already had some th33f steal our bin4rie5.



I do not mean to be crass with my direct questions, and I do appreciate the need to keep the dagger behind the cloak when we discuss the AC.
But I'd at least like to know the extent of the cross-over.

How much of ami's and or Nikki's information gets linked? While it shows up on the website, at what point is it immediately known inside that Nikki is in fact not ami?

This post has been edited by beautifulNihilist: 03 November 2013 - 03:29 AM

[6th|Clear]

Nitro, on 03 November 2013 - 02:48 AM, said:

Unfortunately I cannot answer those questions, I can only give you my word on the matter. The Anticheat and the website are separate entities and both handle data differently. With the website the data isn't as critical so there are not as many verifications put on the information.

I might be inclined to believe you if it was only the website that was mistaken, but the fact is that nikki's auth was reported erroneously in game as well. As it stands, I can't buy into what you're saying, because this quote:

Frankie V, on 19 August 2013 - 02:38 AM, said:

It's DNA evidence and if someone was dumb enough to log into a AUTH enabled server they gave us all the samples we needed and they only had to do so once.

seems to suggest that the anticheat piggybacks on the auth protocol. If the auth server(s) think that nikki was ami, then how would the anticheat's identification differ from that?

[karnute]

For me, they are clearly separated, as I can deduce:
Auth information in the game server is provided by the game server where the bug is, and also the wrong activity shown in web profile come from the game server from the same bug.
But the AC information is stored in other database with data build by the client, as it is the only source able to know about cheats used in the client side... and the client has no bug as you could check in the menu lower-left line which says "Welcome back XXXX - notoriety: basic" where XXXX is correctly your own auth-id...

This post has been edited by karnute: 03 November 2013 - 09:20 PM

[6th|Clear]

karnute, on 03 November 2013 - 09:06 PM, said:

For me, they are clearly separated, as I can deduce:Auth information in the game server is provided by the game server where the bug is, and also the wrong activity shown in web profile come from the game server from the same bug.But the AC information is stored in other database with data build by the client, as it is the only source able to know about cheats used in the client side... and the client has no bug as you could check in the menu lower-left line which says "Welcome back XXXX - notoriety: basic" where XXXX is correctly your own auth-id...

Yes, however Frankie V said that the cheater needed to connect to an auth-enabled server in order for the anticheat to phone home, which suggests that the server plays some part in the process, and if the server's ID of a player is incorrect, then the anticheat data it sends back could also be tied to the wrong player.

[Fenix]

We can't answer such questions not because we are not capable of, but because our AUTH protocol MUST stay closed in order to work properly (and so the AC). I can tell you that what Nitro stated is 100% true.

[Silver Swords]

this might be a b3 problem. i ran into something similar in 4.1, someone showed up as me with admin rights when using !admin

----------------

also when he/she chats it's posted with my nick.

This post has been edited by Silver Swords: 04 November 2013 - 04:37 AM

[karnute]

Clear, on 04 November 2013 - 02:04 AM, said:

Yes, however Frankie V said that the cheater needed to connect to an auth-enabled server in order for the anticheat to phone home, which suggests that the server plays some part in the process, and if the server's ID of a player is incorrect, then the anticheat data it sends back could also be tied to the wrong player.

Probably, auth enabled servers are only used as a double-check trigger for AC, and when data from game server and client does not match, then AC info is discarded as not reliable in these cases. So, this could be the cause FS is sure the collected AC information is 100% OK, but they could not tell the exact protocol for obvious reasons.
On the other hand, info sent from game server to display on web list was not double checked, as it doesn't matter for security.

[|P|Nitro]

Silver Swords, on 04 November 2013 - 04:33 AM, said:

this might be a b3 problem. i ran into something similar in 4.1, someone showed up as me with admin rights when using !admin

----------------

also when he/she chats it's posted with my nick.

your problem is not related to AUTH at all. its related to 4.1 and how b3 identifies players by combinations of GUID/IP which can easily become confusing when b3 databases become rather large.

clear said:

I might be inclined to believe you if it was only the website that was mistaken, but the fact is that nikki's auth was reported erroneously in game as well.

Both the website and the playerlist in game get their data from the server (where the bug lies in corrupting the data) - The Anticheat does not get the data from the same place. Thats as far as I am willing to go to explain the situation and I am probably already pushing the boundries of my NDA because of the closed nature of the anticheat. However I don't want people to start a panic over nothing at the same time.

We are not into banning players from our game for nothing and you can bet your ass off if we ban a player, we are 100% categorically confident that the evidence collected is undeniable in nature that the client had a cheat installed on their computer and used it on a server with AUTH enabled.

I hope that clears things up for you.

[diRf!Nikki]

One of the reasons some of us are so worried is the phrase, "we're not after the cheater, we're after the cheat". I'm sure you can understand where we're coming from as well.

[Silver Swords]

Nitro, on 04 November 2013 - 06:53 PM, said:

your problem is not related to AUTH at all. its related to 4.1 and how b3 identifies players by combinations of GUID/IP which can easily become confusing when b3 databases become rather large.

sorry for not making post clear enough. i ran into something similar more than 2 years ago. the problem was solved by asking the player to reconnect. it hasn't happened since.