You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the bot is walking or standing still the data being fed into the signature calculation algorithm should contain realistic raw sensor information based on the current state of the bot.
Actual Behavior
The bot sends naive or nonsensical values for these fields making bot detection trivial.
Other Information
I've been looking into ways to implement this and was wondering if anyone else has started on this feature? I've found a good source of raw data here.
I believe PR #2986 is on the right track however I think there is more that needs to be done in the same vain.
Since the maximum sample rate the official client is sending these is every 15 seconds (AFAIK) and the source data is sampled @ 60 Hz it is doubtful that their bot detection would notice a replay if we sampled at random from the relevant activity in the above dataset and fuzzed the values by a random value within a std deviation or two.
We may need better gyro and magnetometer data since the orientation in the dataset is static and clipped to a belt but I doubt we need to focus on that at the moment. I can start work on this I just want need a bit of direction as to where I should start implementing. From what I can tell it looks like this would require a change to the pogo api in addition to code in the bot to communicate the current state when making a call that contains a signature.
Any thoughts or ideas on how we go about pushing this forward?
The text was updated successfully, but these errors were encountered:
peter-bonanni
changed the title
Provide realistic sensor data in api requests that consider bots current state.
Provide realistic sensor data in api requests that consider bots current state. [Feature Request]
Aug 11, 2016
peter-bonanni
changed the title
Provide realistic sensor data in api requests that consider bots current state. [Feature Request]
Provide realistic sensor data in api requests that consider bots current state.
Aug 11, 2016
I agree this need to be implemented in the bot and in the PogoApi itself, we also need to implement diverse device information and sensor information for the unknown6 I started discussion there pogodevorg/pgoapi#82 all requests are send with the same gyro heading and so on
As of right now we don't even use altitude (which is supported by the current pgoapi).
Tracks from gpsie for example we have altitude data but our FollowPath task doesn't use them.
Expected Behavior
When the bot is walking or standing still the data being fed into the signature calculation algorithm should contain realistic raw sensor information based on the current state of the bot.
Actual Behavior
The bot sends naive or nonsensical values for these fields making bot detection trivial.
Other Information
I've been looking into ways to implement this and was wondering if anyone else has started on this feature? I've found a good source of raw data here.
I believe PR #2986 is on the right track however I think there is more that needs to be done in the same vain.
Since the maximum sample rate the official client is sending these is every 15 seconds (AFAIK) and the source data is sampled @ 60 Hz it is doubtful that their bot detection would notice a replay if we sampled at random from the relevant activity in the above dataset and fuzzed the values by a random value within a std deviation or two.
We may need better gyro and magnetometer data since the orientation in the dataset is static and clipped to a belt but I doubt we need to focus on that at the moment. I can start work on this I just want need a bit of direction as to where I should start implementing. From what I can tell it looks like this would require a change to the pogo api in addition to code in the bot to communicate the current state when making a call that contains a signature.
Any thoughts or ideas on how we go about pushing this forward?
The text was updated successfully, but these errors were encountered: