Embedded Files
Lessons learned
We immediately read the two white papers. Surprisingly (or not), many details are very similar to the solution we envisioned. But we also foresee some issues which aren't solved in the papers yet.
While we write, their version is 1.1
We immediately read the two white papers. Surprisingly (or not), many details are very similar to the solution we envisioned. But we also foresee some issues which aren't solved in the papers yet.
While we write, their version is 1.1
The following, is our reading of the technical standard progressively defined by Apple and Google.
The following, is our reading of the technical standard progressively defined by Apple and Google.
- BLE based: The white papers describe the signaling strategy, almost the same as we did in our proof of concept: all the smartphones will be advertising and detecting each other, at the same time. Despite some typo in the docs, the payload format looks like the usual iBeacon from Apple and it carries a 16Byte ID (properly named UUID). The only relevant change is that they registered a new tag code at the Bluetooth SIG (consortium), which will be used to identify the new beacon signals. The 16bit code is 0xFD6F and the service is labeled Contact Detection Service.
- BLE based: The white papers describe the signaling strategy, almost the same as we did in our proof of concept: all the smartphones will be advertising and detecting each other, at the same time. Despite some typo in the docs, the payload format looks like the usual iBeacon from Apple and it carries a 16Byte ID (properly named UUID). The only relevant change is that they registered a new tag code at the Bluetooth SIG (consortium), which will be used to identify the new beacon signals. The 16bit code is 0xFD6F and the service is labeled Contact Detection Service.
- Information flow: the advertising packet will contain an anonymized ID code, that will be used by cloud servers, to eventually trigger and route the alert messages. The matches against each user’s log, stays on the user’s own device, without being disclosed to the cloud servers.
- Information flow: the advertising packet will contain an anonymized ID code, that will be used by cloud servers, to eventually trigger and route the alert messages. The matches against each user’s log, stays on the user’s own device, without being disclosed to the cloud servers.
- Scalability: the giants’ information flow raises some doubt about scalability. It implies the central node will broadcast all the anonymized IDs of people who tested positive, to all the enrolled devices without a chance to shard the dataset.
- Scalability: the giants’ information flow raises some doubt about scalability. It implies the central node will broadcast all the anonymized IDs of people who tested positive, to all the enrolled devices without a chance to shard the dataset.
Google: “...a server that aggregates the Diagnosis Keys from the users who tested positive and distributes them to all the user clients who are using contact tracing. In order to identify any exposures, each client frequently fetches the list of Diagnosis Keys”
It could be a huge amount of data, when there are some hundreds of patient-zeroes all over the world, contacting other people around for 14 days each: it isn’t clear how they will manage the scalability of the system, in largely populated countries or to create a single international platform. A solution (that we envisioned in our design) would be embedding a shard-key into each ID, but the encryption model they described seems to prevent it. Another solution, less effective, is a sharding strategy based on time when the contacts happened.
It could be a huge amount of data, when there are some hundreds of patient-zeroes all over the world, contacting other people around for 14 days each: it isn’t clear how they will manage the scalability of the system, in largely populated countries or to create a single international platform. A solution (that we envisioned in our design) would be embedding a shard-key into each ID, but the encryption model they described seems to prevent it. Another solution, less effective, is a sharding strategy based on time when the contacts happened.
- Rolling IDs: the device IDs broadcasted in the BLE advertising packets, will be changing continuously, every 15 minutes. These IDs will be generated from a seed that changes every day. And the seed is generated from a static ID, carved into the app when the citizen installs. The citizen name doesn’t seem to be linked to these IDs, however some cloud API will associate the device’s static ID with that ephemeral ones broadcasted. In such architecture, the cloud servers must know which device a signal belongs to, but hackers in the streets should be hampered enough. Despite the big hype on the ever changing IDs, we still think the privacy issue is wider than this. Further details in next chapters.
- Rolling IDs: the device IDs broadcasted in the BLE advertising packets, will be changing continuously, every 15 minutes. These IDs will be generated from a seed that changes every day. And the seed is generated from a static ID, carved into the app when the citizen installs. The citizen name doesn’t seem to be linked to these IDs, however some cloud API will associate the device’s static ID with that ephemeral ones broadcasted. In such architecture, the cloud servers must know which device a signal belongs to, but hackers in the streets should be hampered enough. Despite the big hype on the ever changing IDs, we still think the privacy issue is wider than this. Further details in next chapters.
- Permission requests: usually, a permission to use localization services, was required to let an app access Bluetooth hardware resources, but we cannot find details on this in the specifications. Although we hope this permission, exceptionally, won’t be mandatory to be exposed, we guess such a strategy won’t be sustainable for Apple and Google in front of their customers opinion. So we guess, the two OS producers will re-introduce those permission requests anyway, or confirm those if they never intended to make a change. The only reference to permissions, is about accessing the log of contacts in iOS. While Google, included this comment in its own API code:
- Permission requests: usually, a permission to use localization services, was required to let an app access Bluetooth hardware resources, but we cannot find details on this in the specifications. Although we hope this permission, exceptionally, won’t be mandatory to be exposed, we guess such a strategy won’t be sustainable for Apple and Google in front of their customers opinion. So we guess, the two OS producers will re-introduce those permission requests anyway, or confirm those if they never intended to make a change. The only reference to permissions, is about accessing the log of contacts in iOS. While Google, included this comment in its own API code:
Google: If not previously used, this shows a user dialog for consent to start contact tracing and get permission.
Given this is a new dialog box for Android, and given the message is very specific for the new purpose, we guess, this will substitute the old generic permission request for location services. This linguistic detail, in our opinion, will affect dramatically the adoption of the app and will ease, also dramatically, the communication of its purpose. So we hope Apple too, will manage the topic with a similar solution.
Given this is a new dialog box for Android, and given the message is very specific for the new purpose, we guess, this will substitute the old generic permission request for location services. This linguistic detail, in our opinion, will affect dramatically the adoption of the app and will ease, also dramatically, the communication of its purpose. So we hope Apple too, will manage the topic with a similar solution.
- Scanning for devices: We guess, they won’t distinguish the background and foreground status of these exceptional apps: they didn’t write about yet. However, both Apple and Google stated that scan times which are more frequent than their usual policy would allow. It seems, it may slightly vary due to further optimizations but, currently, they cut/paste exactly the same sentence.
- Scanning for devices: We guess, they won’t distinguish the background and foreground status of these exceptional apps: they didn’t write about yet. However, both Apple and Google stated that scan times which are more frequent than their usual policy would allow. It seems, it may slightly vary due to further optimizations but, currently, they cut/paste exactly the same sentence.
Google = Apple: "Scanning interval and window shall have sufficient coverage to discover nearby Contact Detection Service advertisers within 5 mins".
In one paper, we read more clearly the logic they will use to optimise the scan timing, which should consider both battery efficiency, and the possible overlapping of many advertising signals. Sure, the density of advertisement signals we will deal with, is a quite new challenge also for the BLE standard, and it could bring surprises: signal collisions, too much background noise for low cost hardware, additional energy required. In our opinion, some kind of NTP synchronization and scrambling of the scans tasks, could easily reduce overlapping signals.
In one paper, we read more clearly the logic they will use to optimise the scan timing, which should consider both battery efficiency, and the possible overlapping of many advertising signals. Sure, the density of advertisement signals we will deal with, is a quite new challenge also for the BLE standard, and it could bring surprises: signal collisions, too much background noise for low cost hardware, additional energy required. In our opinion, some kind of NTP synchronization and scrambling of the scans tasks, could easily reduce overlapping signals.
- Advertisement signaling:
- Advertisement signaling:
Google: “The advertising interval is subject to change, but is currently recommended to be 200-270 milliseconds” .
Well, in our opinion, this should change by including at least 15 seconds of delay (explanation below, ref. “Citizen trails everywhere”). The short latency they purpose is a very redundant and robust advertisement. Sure we also understand their good reason: it will improve the success rate of the detections performed by all the smartphones, also implying that less energy will be consumed to maintain such a success rate. However, a global NTP synchronization of all the smartphones could be useful to have them detect each other in given timeframes, avoiding the waste of energy.
Well, in our opinion, this should change by including at least 15 seconds of delay (explanation below, ref. “Citizen trails everywhere”). The short latency they purpose is a very redundant and robust advertisement. Sure we also understand their good reason: it will improve the success rate of the detections performed by all the smartphones, also implying that less energy will be consumed to maintain such a success rate. However, a global NTP synchronization of all the smartphones could be useful to have them detect each other in given timeframes, avoiding the waste of energy.
- Secondary BLE advertising: this is innovative. It is the open option to broadcast an additional advertisement signal, to be used for calibrating itself the intensity measurement and, doing so, the distance between devices. It isn’t clear yet how it will be used, but it implicitly states the engineers sensibility about the need of fine ranging and prioritizing the contacts.
- Secondary BLE advertising: this is innovative. It is the open option to broadcast an additional advertisement signal, to be used for calibrating itself the intensity measurement and, doing so, the distance between devices. It isn’t clear yet how it will be used, but it implicitly states the engineers sensibility about the need of fine ranging and prioritizing the contacts.
Page updated
Report abuse