Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Proposal: Cross-border interoperability with geo grid tiles #119

Closed
oberinspector opened this issue May 20, 2020 · 5 comments
Closed

Proposal: Cross-border interoperability with geo grid tiles #119

oberinspector opened this issue May 20, 2020 · 5 comments
Assignees
Labels
backlog documentation Improvements or additions to documentation enhancement Improvement of an existing feature

Comments

@oberinspector
Copy link

Proposal

Divide the surface of the world or a large area in almost equidistant grid tiles e.g. with an edge length of about 100x100km and give each of them an unique grid tile id.

Instead of ignoring the geolocations of the smartphone totally, the area ids visited during the last 14 days are stored localy in the smartphone. Triggerpoint to check and save grid tile ids may be BT contacts. When the individual is near (< n times bluetooth distance?) to a border of a grid tile the neighbor grid tile id is also stored. When the individual is near to the corner of a grid tile the 4 corner sourounding grid tile ids are stored.

The app NEVER stores exact coordinates but only the visited grid tile ids!

In case an individual was tested positive with corona he can transmit his own EphIds days and all stored area codes of the last 14 to a central server with an transfer code provided by trusted medical staff (as in DP-3T). Individuals can decide to omit contact time ranges (as in DP-3T) and individual or all grid tile ids.

Instead of distributing all data of infected individuals to each paricipating smartphone the client app can now ask for data only for that area codes where contacts occurred in the last 14 days. In times of corona the majority of individuals will only move around in 1-2 grid tiles so they will only receive data from the grid tiles near their home and from those infected individuals which declined the use of area codes.

Of course everyone can also decide not to use the area codes when requesting data of invected individuals. For those individuals the original DP-3T approach still works but with above mentioned drawbacks (all data is transferred).

Goal is to limit the amount of transferred and computed data for the majority of participating individuals.

Grid tile proposal

This proposal does not require an accurate geo grid tile with e.g. exact 100km x 100km squares but a simple way to compute the unique grid tile ids on each smartphone from gps.
A simple to achieve and pragmatic solution could be to use grid tiles of langitude and longitude. E.g. a 1 degree grid has an approximate 100x100 km grid tile size near to the equator and an approximate 100x50km grid tile size in central europe. So a 1 degree lat and a 2 degree lon grid tile size could be used in europe to get something like 100 x 100km. In fact the area size and the shape doesn't matter at all, as long the the grid tiles are large enough so paticipant detailed movement ist not tracked. With this approach it is possible to compute unique grid tile ids from latitude (0-180°) and longitude (0-360°) which fits in a 16 bit short or an 32 bit integer. E.g. the first 3 digits of the grid tile id represents the latitude and the last 3 digits the longitude of the left upper corner of the grid tile.

Privacy

To use the GPS of the smartphone may be a show stopper for a fration of users. Alternatively to use the GPS of the smartphone, users can decide to select their home grid tiles and the visited ones manualy e.g. by selecting them in an online map. Additional it is possible to decline the use of geo information at all. So they would have to download the total amount of data of the paricipating areas. On the other hand when they get infected their data is spread to all paricipating grid tile of the participating area. Since i expect only a small fracion of users who decline geo information at all, this solution would still work for the vast majority of users.

Server and data pools

The amount of data can be clustered by grid tile id ranges and by data without geo grid information (from infected individuals who declined usage of geo information).
So the client can request data for single grid tiles and data without geo grid information or can request all data without relinquish his own geo grid ids.
Its not necessary to have national app and server solutions, but this approach would also work with them, when there is a central server behind the national servers, which deals with the distripution of the infection data.

Global usage

This solution works from the first day of usage globaly and worldwide. All that is needed is a server infrastructure, which can handle, cluster and publish the amount of data and the free available App in the appstores. Also a special app is needed for trusted medical stuff which attests the infection and provide a transfer key for the infected individuals to allow them to upload their EphIds. Trustcenters for this need to be organized on national level. The amount of data sent to each smartphone does not grow with the number of participating countries but only with the size of the choosen grid tiles.

Bandwith saving example for europe

Generously seen europe has a dimension of 50 x 50 lat/lon degrees. With a 1 degree grid size we have 2500 grid tiles for whole europe. Subtracting the sea maybe something like 2000 inhabited tiles. So under assumption that the vast majority of all individuals accept the usage of geo grid information and stay in only one grid tile in times of corona, the amount of data to transferred to each smartphone is on average only 0,05% of the original DP-3T proposal would have for europe (optimistic assumed all grid tiles have compareable populations).

@oberinspector oberinspector added documentation Improvements or additions to documentation enhancement Improvement of an existing feature labels May 20, 2020
@oberinspector
Copy link
Author

oberinspector commented May 20, 2020

Same as Geo grid tiles to drastic reduce the amount of broadcasted data to each smartphone
An alternative proposal: Cluster data amount by region ids ...both proposals for DP-3T

@tklingbeil
Copy link
Member

See section 3.3 of the Exposure Notification API addendum by Apple:

A Contact Tracing App may not use location-based APIs [...] and may not collect any device information to identify the precise location of users

Basically the same applies to Android (see here, section 3.c.i):

Your App may not request the Location [...] permissions, or collect any device
information to identify or track the precise location of end users.

Now you could argue that we are not looking for the precise location, but to my understanding we are not allowed to access any location information at all...

@oberinspector
Copy link
Author

when its realy not allowed to use location-based APIs even when the exact position is not stored but used to dermine the grid tile id it would be possible to select home grid tiles and sourounding neighbor grid tiles manualy in a map after installation and later add further ones when traveling.

The grid tiles could be selected generous since it dosent matter much if we have 10 or 20 grid tiles compared to 2000 for whole europe as mentione in my rough bandwith saving example.

Using national solutions and implement an interoperabilitiy based on rooming detection might be complicated to implement and to coordinate.

So what would be the difference for privacy from a e.g. 100x100km grid tile compared to be in a country like luxemburg with a national app solution. Or an id "LUX" compared to an generated one like "006E049N"

This proposal could be a generic solution to handle cross-border cases in a borderless europe and also reduces the amount of transfered data to a fraction.

@oberinspector
Copy link
Author

grafik

@tkowark
Copy link
Member

tkowark commented May 25, 2020

Also thanks for this suggestion, @oberinspector ! Similar to #146, we'd like to close the issue for now to remain focused on the current implementation, but labeled it for future reference and will continue to closely monitor the BP-3T issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backlog documentation Improvements or additions to documentation enhancement Improvement of an existing feature
Projects
None yet
Development

No branches or pull requests

3 participants