Excessive Provider Change Events Due to Network Status Fluctuations

[tanuj-g]

Your Environment

• Plugin version: 5.0.0
• Platform: Android
• Device OS version: 11
• Device manufacturer / model: samsung/SM-A908N
• XCode version:

• Capacitor info (npx cap doctor)

  
  Latest Dependencies:
  
  @capacitor/cli: 6.1.1
  @capacitor/core: 6.1.1
  @capacitor/android: 6.1.1
  @capacitor/ios: 6.1.1

Installed Dependencies:

@capacitor/cli: 5.0.1 @capacitor/core: 5.0.1 @capacitor/android: 5.0.1 @capacitor/ios: 5.0.1

* Plugin config provided to `#ready`:

{ /**

• Application config */ autoSync: true, // <-- Auto start tracking when device is powered-up. /**

• Permissions Config */ backgroundPermissionRationale: { message: 'xxxxx', negativeAction: 'Cancel', positiveAction: 'Change to {backgroundPermissionOptionLabel}', title: "xxxx" }, debug: false, // <-- Enable this hear sounds for background-geolocation life-cycle. desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_NAVIGATION, disableLocationAuthorizationAlert: true, distanceFilter: 200, elasticityMultiplier: 4, extras: {

  }, headers: { ContentType: 'application/json' }, isMoving: true, logLevel: config.app.STAGE == 'prod' ? BackgroundGeolocation.LOG_LEVEL_ERROR : BackgroundGeolocation.LOG_LEVEL_VERBOSE, reset: true, showsBackgroundLocationIndicator: false, startOnBoot: true, // <-- Auto start tracking when device is powered-up. stationaryRadius: 25, stopOnTerminate: false, // <-- Allow the background-service to continue tracking when user closes the app. stopTimeout: 5, /**

• HTTP Config */

  url: config.app.MOBILE_APP_LOCATIONS_URL, useSignificantChangesOnly: true //only uses locations determined to be "significant" }

Expected Behavior

Provider change events should only trigger when there is a significant and genuine change in the provider status. Rapid and frequent toggling of the network status should be debounced or rate-limited to prevent excessive event generation.

Actual Behavior

The network status alternates between true and false every 2 seconds. This results in continuous provider change events, causing significant load and potential inaccuracies in our backend processing.

Steps to Reproduce

• Don't have any idea, how one of the user is able to do this.

Context

Impact: The excessive events are causing performance issues in our backend. It appears that this behaviour may be due to user spoofing, resulting in unreliable data.

Request: Implement a debouncing mechanism to filter out rapid and insignificant changes in the provider status. Consider adding a configurable rate limit for provider change events to ensure that only meaningful changes are processed.

[christocracy]

I have never heard of a problem with this. I don’t wish to implement denouncing from a report of a single user without reproduction steps.

[tanuj-g]

@christocracy

I suspect some users might be spoofing their location updates, and our plugin is currently unable to detect it. We have a key in the location object, isMock, which is showing as false for these spoofed updates.

I was wondering if it would be possible to implement debouncing logic to limit the number of updates received per minute. This could help us save on unnecessary API calls and improve the efficiency of our tracking system.

Could you please provide any suggestions or guidance on how to handle this situation? I understand it's a rare condition, but it seems some users have found a way to bypass our spoofing detection algorithm. We need to enhance our system for a more foolproof and robust tracking solution.

Thank you so much for your continuous support and for the excellent work you do with the plugin. Your assistance is greatly appreciated.

[christocracy]

Let me know how to reproduce this phenomenon.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.