[EN-Apple] Why is there no "MatchCount" in the EN-Log with v2 of ENF?

[Ein-Tim]

Avoid duplicates

• [x] Question is not already answered in the FAQ
• [ ] Question has not already been asked in another issue (see this comment from @thomasaugsten)

Your Question

With CWA 1.9.1 (and v2 of ENF) there is no "MatchCount" anymore in the EN-Log. Also, in the UI from Apple "Matched Key Count" is only shown for the "Check Details" but no longer for "File Details". This makes analysis like #1675 impossible. @thomasaugsten already stated in #1703 that you will check this, I've opened this Issue to have a separate Issue about this topic and also a separate feedback channel.

Maybe @daimpi would like to check if the behavior is the same under Android, then this Issue could be transferred to the documentation Repo.

---

Internal Tracking ID: EXPOSUREAPP-4674

[daimpi]

Hey @Ein-Tim,

maybe you could add a screenshot of how this looks in the UI plus a snippet of how the corresponding EN log entry looks now under iOS?

Under Android not much has changed with CWA 1.9+ (i.e. ENFv2) it seems:

Corresponding EN log entry: {"timestamp":"22 December 2020, 12:57","keyCount":480776,"matchesCount":0,"appName":"Corona-Warn","hash":"jZh25T4dlz0TJlduh\/AlCuW5hDn8YnEX7AF\/xtTtwmI="}

• My EN log: me-22.txt

My device:

• Samsung Galaxy S8
• Android 9
• CWA 1.9.1
• ENF 18204516000

[Ein-Tim]

Hey @daimpi

UI before update to CWA 1.9.1 ("File Details" includes "Matched Key Count"):

UI after update to CWA 1.9.1 ("File Details" doesn't include "Matched Key Count"):

---

EN-Log before update to CWA 1.9.1 (includes "MatchCount"):

   {
      "Hash" : "1A9ED80561685CEC9DB933243156323CC2459659BEB46189B34A73D5A6480116",
      "MatchCount" : 0,
      "KeyCount" : 14913,
      "AppBundleIdentifier" : "de.rki.coronawarnapp",
      "Timestamp" : "2020-12-08 13:59:52 +0100"
    },

EN-Log after update to CWA 1.9.1 (doesn't include "MatchCount"):

   {
      "Hash" : "00C686AE0EE143B139E7DD85FDB7B8D02F92115F56CECA013D7DFAE17D9EA06C",
      "KeyCount" : 31881,
      "AppBundleIdentifier" : "de.rki.coronawarnapp",
      "Timestamp" : "2020-12-22 20:49:21 +0100"
    },

Whole log: ExposureChecks-2020-12-22.txt

---

My device:

• iPhone XR
• iOS 14.3
• CWA 1.9.1

---

After looking at your Log and Screenshots it seems like Android does still provide this number, while iOS doesn't.

The question which has to be answered: Is this a bug or is this intentional?

Any iOS-users here who can see the "MatchedKeyCount" ("Übereinstimmende/Abgeglichene Schlüssel") in the UI respectively "MatchCount" in the Log even after the update to CWA 1.9.1? (cc @ndegendogo)

[ndegendogo]

iOS still shows by far more details than Android. On top level both show the timestamp of the check, and number of matches. Android additionally shows the total number of keys in this check - and that's it. No more details. iOS can zoom into the details: the list of the key files, each with a timestamp and with its hash and number of keys. No matches per file.

[ndegendogo]

... and, tbh, I am afraid that not showing the matches per key file is indeed intentional.... but let's wait for the "official" answer.

[Ein-Tim]

@ndegendogo

... and, tbh, I am afraid that not showing the matches per key file is indeed intentional....

Mh, I don't know because it would be very weird if Android devices will continue to show the matches but iPhones doesn't... But yeah, lets wait 👍

[ndegendogo]

Android devices will continue to show the matches but iPhones doesn't

@Ein-Tim Android does show matches on top level. iPhone the same, on top level I see the matches. Android shows only top level. The ENF log is not part of the API, and they implemented it differently.

[daimpi]

@ndegendogo

[…] iPhone the same, on top level I see the matches.

Could you post a screenshot of how this looks like? In the EN log the corresponding entries for MatchCount don't exist anymore though, right? B/c I couldn't find anything resembling them in @Ein-Tim's log.

[ndegendogo]

@daimpi sure.

First screenshot shows overview over the checks with their timestamps.

I can then select a single check and get its summary: list of files (by their hash), and total number of matches. No total number of keys here, but ....

... I can then select a single file and get its details: timestamp and number of keys. Timestamp per file has proven very useful in the past to detect unexpected patterns in the timing of the check procedure. Up to cwa 1.7 (ENF v1) these details also showed matches per key file. This information is lost / suppressed since ENF v2 (cwa 1.9).

Matches per key file was very interesting because it allowed to see that a fresh match appeared at the same time where an old match expired.

[ndegendogo]

... and of course, everything that is shown on the screenshots is also visible in the ENF log file. Nothing more, nothing less.

Edit: Not everything - the number of matches are indeed suppressed in the log file.

[daimpi]

@ndegendogo thanks for sharing the screenshots I now understand what you mean by "matches being visible on the top level" and I agree that the missing Matches per key file are a step backwards for debugging purposes.

One thing I'm wondering though: when you say

... and of course, everything that is shown on the screenshots is also visible in the ENF log file. Nothing more, nothing less.

where in the EN log do you find the Abgeglichene Schlüsel/MatchCount entry? B/c as I said above I couldn't find them in the log @Ein-Tim shared.

[Ein-Tim]

And thats the problem @daimpi. If I am not completely blind, the EN-Log with v2 of ENF does not include any number of Matches anymore... Neither on top level nor for the separate files.

[ndegendogo]

@daimpi @Ein-Tim ooops... yes, you are right. The numbers of matches are shown to the user, but not exported in the ENF log file.

[daimpi]

The numbers of matches are shown to the user, but not exported in the ENF log file.

Ok, thanks for the confirmation. This is imho quite problematic in terms of debugging, as now you would need screenshots in addition to the EN log to get all the information. I hope this is just a bug and Apple will fix this with future updates.

[ndegendogo]

I hope this is just a bug and Apple will fix this with future updates.

We will see what they say. Some people might interprete number of matches could maybe be personal / private data, so it could be intentional. On the other hand, as you said, very useful for analysing what is going on ...

[daimpi]

Some people might interprete number of matches could maybe be personal / private data, so it could be intentional.

Yes, unfortunately I could imagine this (flawed) line of reasoning actually being a motivator for Apple.

Why flawed? B/c your EN log is anyway by default as private as the display which shows you "Abgeglichene Schlüssel". No one forces you to share this with anyone else but hiding matches in the log unnecessarily complicates debugging efforts even if you yourself just want to look at the data on your phone e.g. by importing it into a spreadsheet.

[ndegendogo]

Yes, unfortunately I could imagine this (flawed) line of reasoning actually being a motivator for Apple.

The American companies are sometimes unsure what exactly European data privacy laws like GDPR / DSGVO mean, and how to fulfil them correctly ...

[fsbaraglia]

hi @Ein-Tim

I don't think that the problem is the ENF version from 1.9 to 2.0. I installed the Italian Immuni App and in the exposure, I can see the matchCount, I think that the corona warn app is missing to confirm the matching to the ENF report. I can see the MatchCount: 1 as well in the Exposure log for the Immuni Italian app but not in the CoronaWarn app:

{
"Hash" : "xxxxxxxxx",
"KeyCount" : 26879,
"AppBundleIdentifier" : "de.rki.coronawarnapp",
"Timestamp" : "2021-01-05 20:44:29 +0100"
}

{
"Hash" : "xxxxx",
"MatchCount" : 1,
"KeyCount" : 15991,
"AppBundleIdentifier" : "it.ministerodellasalute.immuni",
"Timestamp" : "2021-01-05 23:17:20 +0100"
},

I put here my screenshots:

[fsbaraglia]

[Ein-Tim]

Hey @fsbaraglia

This is not a contradiction to my finding.

I noticed that after the update from version 1.7.1 to version 1.9.1 of the Corona-Warn-App the "MatchCount" in the log disappeared. With version 1.9.1 the Corona-Warn App updated from version 1 Legacy Mode of the underlying API, the Exposure Notification Framework, which is provided by Apple, to version 2.

So my current assumption is that the "MatchCount" is hidden in the Log and in "Dateidetails" with version 2 of ENF (Exposure Notification Framework).

Immuni seems to be using version 1 of the ENF and so the log shows the "MatchCount" and the number of matches is also shown in "Dateidetails".

To clarify which version of the ENF Immuni is using, I have opened this Issue: https://github.com/immuni-app/immuni-documentation/issues/154

[fsbaraglia]

Hey @Ein-Tim ,

I tested other apps, the Spanish app (RADAR) looks like to use as well the ENF v2. I posted in their git repo as well the same questions :D https://github.com/RadarCOVID/radar-covid-ios/issues/47

[ndegendogo]

corona warn app is missing to confirm the matching to the ENF report

@fsbaraglia interesting idea. Are you thinking of a specific confirmation / call to the ENF that is missing? Do you have more information (like API docu)? Or is it more like guesswork from 'blackbox' observations?

[fsbaraglia]

Hi @ndegendogo , hi @Ein-Tim ,

this is what I found in the apple official docu: https://developer.apple.com/documentation/exposurenotification/building_an_app_to_notify_users_of_covid-19_exposure https://developer.apple.com/documentation/bundleresources/information_property_list/enapiversion

here part of their test code: `func ENManagerIsAvailable() -> Bool { return NSClassFromString("ENManager") != nil }

enum SupportedENAPIVersion { case version2 case version1 case unsupported }

func getSupportedExposureNotificationsVersion() -> SupportedENAPIVersion { if #available(iOS 13.7, ) { return .version2 } else if #available(iOS 13.5, ) { return .version1 } else if ENManagerIsAvailable() { return .version2 } else { return .unsupported } }`

I guess that SupportedENAPIVersion is used to fix which ENF version should be used. Follow my finding from the other apps: Immuni : https://github.com/immuni-app/immuni-app-ios/blob/618ab3853504c289671485a40b166e54f58c215a/project.yml

info: path: Immuni.plist properties: .... **ENAPIVersion: 1**

Immuni uses v.1

Radar App (Spain) : https://github.com/RadarCOVID/radar-covid-ios/blob/7ada4eb6a2f225d31b44b1edcb1dabdf34da2166/RadarCovid/Supporting/Info.plist

Radar uses as well v1 (but I am not 100% sure) `ENAPIVersion

1` Today I installed as well the App from Ireland I have as well the ENAPIVersion 1 https://github.com/HSEIreland/covid-tracker-app/blob/522ff2bc16304d5995b5d94fb88ede1fd7ca0f6c/ios/COVIDTracker/Info.plist 

[fsbaraglia]

Conclusion :

if the App has this file Info.plist (I guess the name of the file .plist , it is passed during the build process) and it contains :
ENAPIVersion = 1 -> MatchCount is there in the Exposure.log and in the IOS tracking

ENAPIVersion = 2 -> MatchCount is not in the Exposure.log anymore and in the IOS tracking

here the official Apple docu: https://developer.apple.com/documentation/bundleresources/information_property_list/enapiversion

[fsbaraglia]

Corona-warn-app:

With this commit got changed the ENAPIVersion from 1 to 2

https://github.com/corona-warn-app/cwa-app-ios/commit/c76432ca683b685d06d4075182fa3a1d16b06b3d

What I don't understand how it is possible that the file got build and released with version v.1.10.x of the App, but I see that the commit is for the release 1.11.x

[Ein-Tim]

@fsbaraglia

What I don't understand how it is possible that the file got build and released with version v.1.10.x of the App, but I see that the commit is for the release 1.11.x

The update of the ENF from version 1 to 2 was in the release 1.9.1 (see #1457). The commit https://github.com/corona-warn-app/cwa-app-ios/commit/c76432ca683b685d06d4075182fa3a1d16b06b3d belongs to #1457 (first commit of the PR).

You are seeing this commit in the 1.11.x branch (that's why this is shown). After the branch you are seeing for which releases this commit was tagged: As you can see it started with 1.8. and goes all the way up till the RC0 of v1.11.0 (since the commit was included and will be included in all these releases).

[ndegendogo]

I guess that SupportedENAPIVersion is used to fix which ENF version should be used.

@fsbaraglia yes, this is also my understanding.

[Ein-Tim]

@thomasaugsten you said you will address this do you have any news for us?

[thomasaugsten]

Apple is still processing the request

[dsarkar]

Internal Tracking ID: EXPOSUREAPP-4674

[Ein-Tim]

Did Apple respond to the request? @thomasaugsten

[thomasaugsten]

Not in a sufficient way we need to wait here

[Ein-Tim]

More than 9 months later: Did Apple respond @thomasaugsten?

[thomasaugsten]

No clear response if this is on purpose or not.

[Ein-Tim]

Mh, I really wonder how long Apple takes to respond to so easy questions like this. Don't they document their changes anywhere, is there nobody available who actually developed ENF v2 and can comment on this...

[ndegendogo]

my guess would be: privacy reasons

[larswmh]

FYI @ndegendogo @Ein-Tim "Match count" was removed by Apple and not added in later releases, therefore the internal ticket was set to obsolete.

[Ein-Tim]

@larswmh So Apple responded that this is intentional?

[larswmh]

So Apple responded that this is intentional?

@Ein-Tim This is not clearly communicated, however it seems more like a personal discovery by us than an official reponse from Apple. Nonetheless, we don't expect anything to change here sadly.

[Ein-Tim]

@larswmh

Ok thanks for the feedback!