How are parameters passed around?

[pdehaye]

I have tried understanding how parameters are passed to the app.

I found some relevant code server side, which feeds into the bit below.

https://github.com/DP-3T/dp3t-app-ios-ch/blob/44ee83cd9f9911b4725ac42f7a576a2af6c061b1/DP3TApp/Logic/Config/ConfigManager.swift#L127-L137

Could you please tell me more?

This is related to PersonalDataIO/CoronaRiskScoring#3

[RSickenberg]

This seems to come from here: https://github.com/DP-3T/dp3t-sdk-ios/blob/master-alpha/Sources/DP3TSDK/DP3TTracing.swift#L45

If I check the caller of updateSDKParameters it's in the didSet which is called by https://github.com/DP-3T/dp3t-app-ios-ch/blob/develop/DP3TApp/Logic/Config/ConfigManager.swift#L101

And requested to the server here: https://github.com/DP-3T/dp3t-app-ios-ch/blob/develop/DP3TApp/Logic/Config/ConfigManager.swift#L73

If I understood correctly, you are asking how this is passed through the app?

Then I guess you found the relevant config on the server-side.

Let me know if you need more explanations @pdehaye 😀

[pdehaye]

I got more explanations in the interim through a public call with the DP3T team. It looks like they are not using a lot of the configuration options of the API, and only relying on the ENExposureSummary results.

Still need to dig deeper for this.

[pdehaye]

Ok, much easier for me to do with the information I just got in the seminar today.

(EDIT: goes on to paste code not relevant to this repo, since concerns Android version only:)

This then defines a weighted threshold for logging, based on relatively crude parameters:

https://github.com/DP-3T/dp3t-sdk-android/blob/4aa803897928a4d886d4bee97d2c0da5726639b5/dp3t-sdk/sdk/src/main/java/org/dpppt/android/sdk/internal/nearby/ExposureNotificationBroadcastReceiver.java#L38-L46

This defines according to what formula people who are at risk will be notified:
https://github.com/DP-3T/dp3t-sdk-android/blob/03e56b8c52ca5ecc96a5284481a53e99dd7b1c60/dp3t-sdk/sdk/src/main/java/org/dpppt/android/sdk/internal/nearby/GoogleExposureClient.java#L133-L142

We can see the weighting is extremely crude, based only on the sum of durations for which a token was received (so playing very safe). That setting seems to correspond to a willingness to risk very high level of false notifications.

[EDIT: It might be counterweighted by the fact that nothing is done based on this risk score, actually, but only attenuationThresholds are leveraged]

I am not sure this is the running code in the current system though.

[pdehaye]

This document was just posted, clarifying many of my questions so far.

Thanks!

[pdehaye]

(The text below actually applicable only to Android, wrong repo)

Update on some of the previous parameters, in the latest version of the code:

• ExposureConfiguration, extremely crude
• notification calculation, based on ExposureSummary

In the latter, I am not clear on where exposureSummary.getAttenuationDurationsInMinutes is defined. It looks, however, to be related to the length 3 list called attenutationDurations in the Google spec.

Also, does this code still run in the current version of the app?

[pdehaye]

In the iOS SDK, this info is passed around here and this seems relevant as well.

[pdehaye]

(a lot was wrongly posted here about Android, so has been moved to DP-3T/dp3t-app-android-demo#62)

[pdehaye]

I would like to understand if this iOS SDK code to fetch parameters and configure the API is run via the iOS app, and if so how/where?

Could you please tell me more?

[maerki]

Is this a good start to find an answer to your question? https://github.com/DP-3T/dp3t-app-ios-ch/blob/35fca01de72c4c8eacbe11485b21523fe3750ead/DP3TApp/Logic/Config/ConfigManager.swift#L131

[pdehaye]

Yes, so good that this is also where I started this issue ;-)

So, to be more precise, is this code from the SDK

https://github.com/DP-3T/dp3t-sdk-ios/blob/d29383ce3e731e71732aee0c04ad565270acb3be/Sources/DP3TSDK/Matching/ExposureNotificationMatcher.swift#L104-L116

run in the app now? If so what is the logic behind it? A minimum risk score of 0 if set, and all the events are marked as "at risk" (through nonsensical parameters), so then some risk calculation can actually be done based on the triples of weight and attenuation values, obtained from the ExposureSummary?

That logic still runs in the app now?

[UBaggeler]

The usage of the EN API is explained in EXPOSURE_NOTIFICATION_API_USAGE.md. If you think there is something missing or still unclear, let us know.

[pdehaye]

Thanks, that confirms to me what that my understanding was correct, and the code is still running.
I have more specific questions around EXPOSURE_NOTIFICATION_API_USAGE.md, but this is for a separate issue.