Native support for 'traveler' bit

[mikehelmick]

Feature description

Provide a traveler bit in the batch upload, specific to an individual TEK. When this is set to true, mark that TEK as being present in all participating countries.

• This could either do server-side fanout (preferred, but would break end-2-end batch signature)
• Pass the traveler bit all the way through the batch, where downloaders can interpret this as "has been in my country" when the bit is true.

As an alternative, provide an endpoint where a fresh list of all participating countries can be obtained so that this fan-out can be done on the client side.

Problem and motivation

The Google exposure-notifications-server and the Apple+Google Exposure Notifications Express program does not give the granularity of individual countries a TEK may be been in, but instead has home country plus traveler (or not).

The current solution is for the exposure-notifications-sever EFGS integration to say that a given key is all participating countries - but any given server implementation has no way to know this. So our current integration will just send ALL ISO codes. This is lots of wasted bits over the wire and in the database, when a boolean captures the same item.

Is this something you're interested in working on

Yes

[mikehelmick]

This is specifically what I'm worried out. With the "traveller only" roaming model, and the current need to do fan out client side, we will be passing a rather large list absent the ability to get it dynamically: https://github.com/google/exposure-notifications-server/pull/1095/files#diff-0ae5d7acb5bc1b9b2a36d8a7e622155209a0dec7249e64d4c7cf1ac87b189738

I would be happy to submit PRs to add support for a "traveler" bit directly, greatly reducing the key size on the wire and in the database.

[alstiefel]

Thank you for the input, the underlying issue already generated a number of discussion between the participating countries. @SchulzeS will follow up the discussion.

[mikehelmick]

Hello - any guidance here?

I'm happy to contribute PRs to add support for the Apple + Google roaming model (home country + traveler boolean)

[SchulzeStTSI]

Hello,

Currently we add all EU+EFTA countries listed on this page if you are using Traveller or OneEU/World Pattern: https://ec.europa.eu/eurostat/statistics-explained/index.php/Glossary:Country_codes

Your idea with the traveller bit it is good for upload, but in the download not transparent, because there are mixed patterns in the keys. A new route to give out the existing onboarded members is under discussion.

[mikehelmick]

I don't believe the traveler bit is any more or less transparent. It conveys the information that is known about the key in total, which is origin country of the key + traveler status.

[SchulzeStTSI]

The bit itself is not intransparent, but the meaning and the interpretation on the national backend side. If you set this bit, it means you are a traveller, but the country of interest interpretation didn't know where do you travel to. Of course we can define something like "bit means DE,NL,AT,... etc pp" But this is not very explizit. It avoids simply some mb of traffic. The same effect is also reached with a custom value in the visitiedCountries Array like "visitedCountries:[]" which has the same effect. I saved some bytes but everyone needs to know what that means. This needs a lot of alignment between all attendees. Of course the insertion of explizit countries is not beautiful, but it's currently explicit and understandable. It can also turn back to a country of interest pattern without so much effort. (just country list is smaller) We must be very careful here. Would be the solution also an acceptable way for you?

[mikehelmick]

For the Apple+Google roaming model, traveler=true indicates that key may have been in all countries.

Having visitedCountrues:[*] could function the same way, but having to look for a sentinel value in an array would seem to be more error prone than an explicit boolean value.

We could work with either solution.

[mikehelmick]

I'm gong to close this issue out. We're no longer requesting this change.