First I'm very disappointed about SAP's decision not to prevent a re-occurens of the issue. ("there is nothing we will do")
Here the Questions:
getTemporaryExposureKeyHistory() | Retrieves key history from the data store on the device to upload to your internet-accessible server. Calling this method prompts Google Play services to display a dialog that requests consent from the user to gather and upload their exposure keys.The keys that are returned depend on the API version. These key include the past 14 days, but not the current day’s key. (This is different for allowlisted accounts, which also return the current day’s key.)The consent granted by the user lasts for 24 hours. The dialog prompting for consent appears only once for every 24-hour period, regardless of how many times the app calls the method.In v1.7 and higher: Allowlisted apps support returning keys that include the current day’s key, which is tagged with an expiration date (rollingPeriod). When the current key is released, the device stops using it to generate BLE beacons, and replaces it with a new key. Calling this causes a new key to be selected for the remainder of the current day. As a result, if this method is called multiple times, several keys with different rollingPeriod and identical rollingStartNumber can be released for those days it was called on. To enable this feature, contact your Google representative.
-- | --
So the devices were mistakenly part of the allowlisted accounts?
In the UTC time interval 2020-10-07 22:00 to 2020-10-08 2:00 at least one user uploads a same day key.
Can I assume that some of the keys in the 2020-10-08-hour-01.zip were created by a device that is still part of the allowlisted accounts?
There's a difference between allowlisted accounts and apps:
Note that both are referenced in the description of getTemporaryExposureKeyHistory().
So the devices were mistakenly part of the allowlisted accounts?
As per the above description, I guess you mean allowlisted apps 😉 No, it looks like there was a bug on Google side that caused same-day TEKs in CWA, despite the fact that CWA was not on the allowlist for this feature. This has been fixed by Google in the meantime through server-side config on their end.
Can I assume that some of the keys in the 2020-10-08-hour-01.zip were created by a device that is still part of the allowlisted accounts?
I think it's unlikely that this was an allowlisted account (see description above). I assume that this was either a device that had not yet received the server-side update from Google (my primary assumption) or the device had wrong device time.
Hi @mlenkeit
I assume that this was either a device that had not yet received the server-side update from Google (my primary assumption) or the device had wrong device time.
Iirc, @thomasaugsten mentioned somewhere in #933 that Google is able to push client-side config files to the ENF (without any version change). As all pushes to clients happen in waves, it could explain why some devices may still behave in that way.
@vaubaehn that's right AFAIK. Depending on the parameter and the kind of change, Google has different options to roll it out, such as updating all clients at once or in waves. I'm not entirely sure what option Google chose here but I assume it was "all at once".
@Tho-Mat have your questions from the original post been answered? If so, I would suggest that you close the issue.
@mlenkeit
Depending on the parameter and the kind of change, Google has different options to roll it out, such as updating all clients at once or in waves. I'm not entirely sure what option Google chose here but I assume it was "all at once".
Thanks for the additional information. It's fun to learn.
@Tho-Mat have your questions from the original post been answered? If so, I would suggest that you close the issue.
There was no more communication since one week so this issue will be closed.
Thank you very much for all contributors!
Best regards,
SG
Corona-Warn-App Open Source Team
Most helpful comment
@mlenkeit
Thanks for the additional information. It's fun to learn.