serverTime - deviceTime offset check + ACTION_TIME_CHANGED intentFilter

[rawmain]

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

The current SDK code mainly relies on local deviceTime checks (because of offline certificate verification requirements) for scan validation datetime.

Therefore - in case of device datetime misconfiguration - it doesn't raise any timeOffset exceptions .

---

Describe the solution you'd like

1. DGC-SDK : Addition of ServerTimeOffsetException check function in order to check/detect any difference between deviceTime and serverTime (that can be retrieved/parsed from Date field in SERVER_HOST get.dgc.gov.it response headers).

2. App with DGC-SDK integration : ServerTimeOffsetException call at the start of the app / whenever needed + addition of ACTION_TIME_CHANGED intentFilter = broadcast receiver to check whether deviceTime has been manually changed/overrided while the app with DGC-SDK integration is running.

[popolla]

It's important to point out it's not any difference between deviceTime and serverTime; actually, there's a tolerance window.
The simplest check is:
(deviceTime minus serverTime) should be greater than 0, for timeline consistency, and less than 24 hours, which is the maximum interval between calls to the server for certs/rules update; I think the maximum interval is defined as a constant somewhere in the code.
The mimimun requirement is that the check is performed at the moment of DGC validation.

[rawmain]

Hello

Just submitted 2 PR linked to this issue :

• VerificaC19 App PR#182 = Time Change Receiver

• VerificaC19 DGC SDK Enhancement : Check Clock Alignment #52 = Clock Alignment checks

The related test-package is available here (tag 1.1.5-TIME).

---

Side notice :
Just minimum commits also in order to avoid potential conflicts with WIP code refactoring for DRL/revoke/blacklist additions (check the latest app & SDK feature branches' activities by @astagi - @nicola-95 - @Light2288)

[popolla]

Hi @rawmain,
if I understand correctly, the PRs above provide a check to be performed at the moment of update request for app data/rules, which is fine and useful, of course, but still I think that a check to be performed at the moment of GC verification, as discussed before, would be important as well, if not more useful. The procedure is simple, how do you see it?

[rawmain]

Hello @popolla

the PRs above provide a check to be performed at the moment of update request for app data/rules, which is fine and useful, of course, but still I think that a check to be performed at the moment of GC verification, as discussed before, would be important as well, if not more useful. The procedure is simple, how do you see it?

Current PR commits check indeed the clock alignment with API responses & disable the blue QR scan-button in case of time-mismatch > 2 minutes between device and server.

I haven't submitted yet the further commits for the TimeChangeReceiver execution & ServerTimeOffsetException + alert dialogs triggers, that prevent QR scan while already in the scan black window & in case of manual time-override.

.
Better indeed to wait for the approved changes into verificationviewmodel (SDK) and verificationfragment (app) in order to avoid conflicts.

In the next few hours - by Monday at the latest - there should be the feature->develop merge of the approved CRL / blacklist commits. Then I could update the PRs, obviously also according to their review process.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.