I'm sorry that this request may be out of places. But I couldn't find out where I should ask this feature.
Context
Exposure Notification(EN) provides a way to check whether we contacted infected persons. It can be seen as a post-confirmation feature.
What about infection protection? We are suggested to keep social distancing. It may be easy for healthy persons to keep doing that. But it may be difficult for visually challenged persons to do the same thing. In addition, it is important for many people to know if there are/were crowd of people before to go there.
Some APPs provide a measurement feature by using BLE tech. But these APPs work in many case only when each other launch same APP or use same service.
Problem of EN
APPs based method causes a dependent on spec of them. And advertising timing should be as shorter as EN's one to easy to find out by many kind of devices. Of course, it should take care of power consumption.
So, I think it is best way that OSs or Platforms should take care of this to broadcast signal with lowest power consumption and efficiency.
Basically, we can not get a measurement of distance by using EN before getting TEKey/ENIntervalNumber. Even if we don't care about a distance of each other and just find other EN devices, there are some privacy problem.
If certain APP has stored EN RPI/EM Key and infected person's TEKey/ENIntervalNumber were leaked, it can find out when this device was close to infected person. This matter must be unfavorable. (So, iOS seems to hide EN UUID from user.)
Then it is possible to be such as beacons. But as already we know, there are some differences in their specification. (e.g. iBeacon and Eddystone) And fixed UUID of device causes any privacy issues.
And here is the thing, common and unified format is most important!
My proposal
I'd appreciate it if platforms(iOS and Android) would consider to advertise new packet additionally.
Here is my draft proposal.
Advertise Packet
Length |
Type |
Flags |
0x02 |
0x01 (Flag) |
0x1A |
- Complete 16-bit Service UUID
Length |
Type |
Service UUID |
0x03 |
0x03 (Complete List of 16-bit Service Class UUID) |
0xXXXX (Social Distancing Service) |
- Service Data - 16 bit UUID
Length |
Type |
Service UUID |
SubType |
TxPower |
Rolling Proximity ID |
Rserved |
0x17 |
0x16 (Service Data - 16-bit UUID) |
0xXXXX (Social Distancing Service) |
1Byte |
1 Byte |
16 Bytes |
2 Bytes |
- SubType
- [7:6]: Major version (current: 2b'01)
- [5:4]: Minor version (current: 2b'00)
- [3:0]: TxPower Level at ...
- 4b'0000: 0 [m]
- 4b'0001: 1 [m]
- 4b'1111: may not be calibrated
- TxPower: -127 ~ 127 [dBm]
- Rolling Proximity ID
- Periodically changed UUID for Proximity
- Rserved (muxt be 0x0000)
- Notes
- MAC Address must be changed periodically
- MAC Addresse changing should be sync with wall clock as possible.
- easy to prevent from duplicated counting or to decrease false positive
- MAC Address between EN and Social Distancing Service must not be linked