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
The current implementation of checkContacts supposes that the clocks between the sender and receiver are perfectly synchronized. It should test the day before and the day after the proposed epoch, too.
For security reasons, it should neither check for the the day bucketDate nor for the day after bucketDate. See #17.
Regarding clock desynchronization, the specification is even too liberal in that it does not prevent easy targeted false positives, should such desynchronization happen. See issue reference_implementation/#12 and issue documents/#99.
We recently undertook a massive refactoring to integrate Apple's official ExposureNotification framework in favour of our custom Bluetooth and Key-generation implementation. Going forward, we will only support the official Apple framework that handles all bluetooth communication. Please update to the latest SDK version and subscribe to the notifications so you keep up to date with the latest changes.
The current implementation of
checkContacts
supposes that the clocks between the sender and receiver are perfectly synchronized. It should test the day before and the day after the proposed epoch, too.See also DP-3T/documents#135
The text was updated successfully, but these errors were encountered: