https://medium.com/personaldata-io/inferring-distance-from-bluetooth-signal-... In sostanza, Google e Apple cercano di ridefinire il concetto di contact tracing per adattarlo ai cellulari. Ma NON faranno contact tracing, perché non funzionerebbe. Mica scemi! (loro) Giacomo Contact tracing apps intend to predict exposure to a COVID-19 infection, where exposure is computed as some function of time and distance to an infected person. The distance is inferred from Bluetooth signal strength, which is a step that has not been empirically tested properly. We review evidence coming from the developing teams of what might or might not work to deduce distance from Bluetooth signal strength, and eventually question whether this is truly the goal of all those who implement contact tracing apps. [...] # Apple & Google APIs It is very hard at the moment to know how Apple & Google intend to let apps infer distance from signal strength. In fact, every indication seems to be that they don’t intend to do that. They seem to want the apps to instead infer transmission risk from signal strength directly. Caveat: There seem to be changes, between v1.2 (cryptography, Bluetooth) and v1.3.1 (Android) of their protocol that relates to precisely this point. There is certainly divergence between Google and Apple, at least in the documentation available, since Google’s Android API v1.3.1 mentions AttenuationThresholds while iOS’ API doesn’t. For the moment, one thing we can productively evaluate is the core of the API already made available. It shows how the risk calculation will be derived. We include a few screenshots below of Android vs iOS. Android API for configuring the Exposure Risk calculation (taken from Android API v1.2, now superseded by v1.3 which doesn’t include the graphic anymore; v1.3 changes the way attenuationScores are computed) iOS ENExposureConfiguration (no version number available) Note that there are subtle but significant differences between the two: the range of the parameter values start at 0 or 1, and more crucially the final risk is calculated multiplicatively resp. additively. Definition of the parameters presented above, in the iOS API. We see that the attenuation is averaged to just one number, that is then passed to the app. Based on the fact that a simple average is returned instead of the actual sampled signal attenuation values, and all the difficulties outlined above, I infer that the Apple and Google APIs intend only to help apps deduce the infection risk from Bluetooth measurements, and not the distance itself (which could then be fed into epidemiological models). The Apple and Google APIs thus change the definition of the notion of contact for epidemiological purposes. Inferring infection risk from Bluetooth signal strength instead of distance is not a neutral act. Almost everyone is equal in understanding and assessing a recommendation of social distantiation of 2 meters, and able to discuss the politics of remediation for those who are not capable of following this rule. As a society, we also have much more common cognitive basis for discussing the politics tied to manual contact tracing and the consequences that follow from that process (for instance in carefully balancing false positives and negatives in manual contact tracing). With Bluetooth-based proximity tracing leveraging the Google and Apple API, we lose that common cognitive basis. Apple and Google get to define the rules, and will progressively get to introduce new data as input (if indeed, like everyone else, they conclude this is a necessity). It also will lead to a substantive shift in what constitutes a false positive and a false negative.