Add System Clock Offset option to the SDK

[armoona]

Is your feature request related to a problem? Please describe.

FaceLivenessDetectorView frequently fails for our iOS users because of clock drift.

Describe the solution you'd like

Please add an option to set systemClockOffset, same as was done for the React version:

https://ui.docs.amplify.aws/react/connected-components/liveness/customization#system-clock-offset

Describe alternatives you've considered

There are none

Additional context

No response

[harsh62]

@armoona I see that liveness already has clock skew support (https://github.com/aws-amplify/amplify-swift/releases/tag/2.38.0), which has already been pulled into the Liveness repo. Would you be able to use the latest version and validate if the issue still exists.

If you are using the latest version and the issue still exists, would you be able to share verbose logs when the issue happens.

[armoona]

I am already on 2.42.1 that includes the aforementioned clock skew support. But that fix isn't useful. It adds a one-time retry, but if the user's clock is set incorrectly then every retry will return an error.

What's need is a way to set systemClockOffset.

[tylerjroach]

@armoona Can you explain your concern further.

It adds a one-time retry, but if the user's clock is set incorrectly then every retry will return an error

This is not what should happen. With the fix, no time errors should be encountered.

As an example of what the library does:

1. Lets say device time is 05:00 GMT
2. Real time is 04:00 GMT
3. Liveness attempt is made.
4. The library gets the corrected time from the server and adjusts future timestamps for that session to be -01:00 the device time.

No user intervention is required. There is no need to set an offset as the library manually recognizes the offset and adjusts accordingly within the same liveness session. There should be no errors returned.

If you are seeing an error, its possible something is malfunctioning. Please provide further logs of what you are seeing.

[tylerjroach]

The React version is more manual because JS has less control over the WebSocket than the native platforms. Native platforms are able to adjust the skew internally with no manual adjustments required.

[armoona]

I see. Then, yes, this shouldn't be happening.

What I see in the error logs from live users are these:

FaceLivenessDetectionError(code: 17, message: "The signature on the request is invalid.", recoverySuggestion: "Ensure the device time is correct and try again.")

Here is the code:

FaceLivenessDetectorView(
    sessionID: faceLivenessSessionId,
    region: "us-east-1",
    isPresented: $isPresentingLiveness,
    onCompletion: { result in
        isPresentingLiveness = false
        switch result {
        case .success:
            ...
        case let .failure(error):
            SentrySDK.capture(error: error)
        }
    }
)

SentrySDK.capture(error: error) line captures the errors. The errors happen for a sizable minority of users. I haven't been able to notice any pattern in who reports an error. But I also not sure where to look for such pattern. It happens on different devices, different timezones and countries.

I haven't been able to replicate this error locally on my devices. Even when I set a wrong time on my iOS device, there are no errors.

I thought maybe it has something to do with users being on a VPN?

[tylerjroach]

Thanks for the report. It sounds like the signature issue could be something other than a clock skew issue. The recovery suggestion is suggesting to check time as that is a common issue of invalid signatures, but not the only.

Can you try and collect more data, such as if these devices are on VPN, any specific regions with more failures, etc. The more logs here, the more we will be able to investigate on our end.