Cwa-wishlist: [Feature Request] QR code scanner for IDs of (indoor) locations

[medienintegration]

Virologists point out that the virus appears to spread in over 40% of the infections caused by aerosols, which can remain in the air for up to several hours in closed rooms. I think it could be helpful to create a possibility for restaturants, hairdressers etc. to be part of the tracing process without using a Bluetooth device, e.g. with the help of QR codes.

Guests would scan the respective QR code when entering and leaving such a store and the app would rate the transmitted IDs as contacts. If it turns out that an employee has tested positive for Corona, the IDs would be uploaded to the backend server as infected and all guests who have been in this room in e.g. the past 2 weeks (or five days before the onset of symptoms) will be informed by the app.

Such a solution would require a server that provides IDs based on a public url for the participating shops / locations.

---

Internal Tracking Id: EXPOSUREAPP-2124

[tkowark]

Thanks a lot for your proposal. In the initial version, the app scope will adhere to the scoping document.

But, of course, we welcome discussion and ideas around potential future functionality and leave this issue open for others to discuss and refine the idea.

[egandro]

We used QR Codes in a lot of projects.

It can be trolled by a simple photo :)

So you need somehow signed NFC stickers to gain a minimum of security.

• You need a direct contact to NFC stickers (this creates a new hotspot!)
• NFC can also be copied...

I see no possibility implementing this using customer cell phones.

[medienintegration]

The possibility of misuse with an insecure technology such as QR codes should of course be considered and evaluated. Perhaps this discussion will help developing a robust concept, possibly with the involvement of health authorities or 'Ordnungsämter' who regularly check the QR codes used.

Ultimately, the QR code is just the way the link is copied, the app could perhaps also display the location's data (name, address, logo) as confirmation.

[TomTeeJay]

No @medienintegration. I disagree. There are already a lot of 2nd thoughts and well-known Show-Stopper. The App has one job, let it do accordingly and stop mixing functions. Its very easy to understand:

With the mixing of functions the discrimination of non-App users increases.

It's also horrific how complexity is increased.

I also recall this prematurely closed and not understood issue (https://github.com/corona-warn-app/cwa-documentation/issues/23)

But of course I could miss the point, that this could be the strategy right from the beginning. To integrate as much as possible in order to nudge as many as possible.

Let me say this very clearly: This will not work!

[sventuerpe]

@TomTeeJay

With the mixing of functions the discrimination of non-App users increases.

It's also horrific how complexity is increased.

On the one hand I agree that things should be kept simple and focused. On the other hand, this project has skipped design exploration and is taking an arbitrarily set approach. It should not surprise us that alternative approaches keep popping up in various forms. This project lacks a design rationale.

[MalteJ]

@medienintegration
Sorry, until the BLE approach is not proven to be ineffective/broken we cannot concentrate on different solutions. I have to close this issue. Feel free to re-open as soon as there is an indication the BLE approach does not work in your sketched environment. But I am pretty sure you have described a perfect setting for BLE contact tracing 😉

Malte

[sventuerpe]

@MalteJ Could the idea of @medienintegration be implemented as a protocol extension based on BLE? Imagine a location participating in contact tracing with its own device(s). If an infected person has visited the location recently, this location becomes exposed and if locations are distinguishable from persons one could in this case notify secondary contacts.

I have not thought this through – some form of authentication and location-binding will probably be needed and one will have to analyze the privacy implications – but dismissing the entire idea without much discussion seems premature to me.

[medienintegration]

@MalteJ I understand that the focus should be on developing the core function. However, the point is not that the BLE approach is ineffective / broken, but that scenarios are conceivable that could save valuable time with the help of QR codes (or stationary devices). In other scenarios, the BLE approach would just not work (simple example: I am in the barber shop with 2 employees and another customer in one room - and I am the only one who has installed the app).

@sventuerpe Actually, stationary BLE devices were my first idea, but after a discussion with a friend, she had the idea with the QR codes, which I find much less problematic. As you mentioned, stationary devices would have to be authenticated. In addition, they should not leave the place, otherwise they would trigger a myriad of "contacts". But maybe someone has an idea for a working solution.

[darkdragon-001]

Another situation where the current approach fails, is a chef in a kitchen with access to the meal of a customer but behind a Bluetooth impenetrable barrier (metal kitchen walls, far distance, ...)

[tkowark]

Reopening now as part of the wishlist.

[MATTiVOLTARii]

This great idea could finally put an end to the prevailing problem with the registration on paper for visiting localities and would be finally compliant with gdpr. Could also increase the attractiveness of the app and the number of users.

Could be so easy:

[medienintegration]

If I understand the specifications of Google's and Apple's API correctly, there is no way to add your own IDs that are not received via Bluetooth to the collection of transmitted IDs. But maybe there is still a possibility to include locations in the tracing process and to use parts of the CWA infrastructure for this.

As already described, this would require a server that provides IDs that are assigned to locations via public links. As a location, I would have to register with name, address, logo etc. and would receive the link in the form of a QR code, which visitors can scan when entering and leaving the location. To confirm that this QR code is correct, the app could display the name / address / logo it received from the server.

The app would save the provided IDs / timestamps regardless of the BLE IDs. If a positive Corona case is associated with a participating location, the relevant IDs would be published and the app could carry out a risk calculation and inform the user if necessary. The configuration parameters (duration risk, days risk) of the RKI could also be used for this calculation (or differ in the case of a different recommendation).

This function could be added to the app as a feature / plugin, which is deactivated by default, so that the users could decide whether they would like to use this function.

I know that this feature would probably be enough for another single app and, as @TomTeeJay emphasized, the mix of features could be problematic. Nevertheless, I find such a feature worthy of discussion due to the success of the app and the current problematic visitor tracking in restaurants and other locations.

[alanrick]

I understand @tkowark ‘s statement that this is not in the scoping document, but is that by design or lack of foresight? Similarly, it is one thing if the current BLE API does not support this but quite another if the topic hasn’t been broached with Google/Apple.

I ask because I found it very convenient and hygienic in the UK to use qrcodes taped to the pub tables to register, and at the same time I notice a deterioration in friends’ willingness in Germany to submit correct details in the bar lists. Squirting Random IDs into a local (cloud) server would be more private and comfortable.

Ultimately, it’s RKIs call. But it does seem a wasted opportunity not following up on this armed with tracing-center success/failure statistics and epidemiologist, psychologist and IT expert opinions.

[f-re]

Strongly support this, as NFC and as QR code solution.
To mitigate misuse by copy (for unsigend NFC or QR) possibilities are:

• the codes as stickers can be replaced quickly by just using a new QR sticker.

• indirect to a server URL that issues a fresh UUID. The server can disable abused QRs centrally.

This is also a good solution for public transport ("scan when enter"). As users only touch their mobiles I see the risk of creating local hotspots quite low.

[alanrick]

The UK hasn't had success with their app so far, but they are intending supporting QR codes. Is the CWA team in contact with their developers for know-how transfer on the pros and cons of the method to be used?

[jniediek]

This was issue #272 previously, now moved here due to overlapping scope. Note however that the proposal below goes beyond a mere addition to BLE-based ID transmission.

Feature description

As repeatedly discussed by Prof. Drosten and others, it's crucial to identify infection clusters. Here is an idea towards this goal.

1. Create a website to print specific QR codes. These printed codes are used to identify rooms or closed spaces in general, such as class rooms in schools, offices, workplaces, restaurants, maybe even train compartments. Anybody can print a code and display it inside the room. Each QR code contains two pieces of information: a unique ID (generated by the backend behind the website) and some nickname for the room (not necessarily unique, such as "McDonald's at Berlin Hbf" or "Commerzbank München Office 210"; provided by the user who prints the QR code). For privacy concerns see below.

2. Use CWA to scan the QR code when you enter a room. The unique ID is stored only locally on the device, and the nickname of the room is stored only locally on the device in the form of some "my closed rooms diary" together with a time stamp, visible to the user of CWA.

3. If a user is tested positive, three things happen:

• The user can send his/her list of room nicknames to the health authorities/Gesundheitsamt. This will improve the contact tracing interviews a lot: they will be more precise, more complete, and faster, because the list of visited rooms will help the patient to recall what happened during the last 14 days. For privacy, of course the user will be able to delete items from the list before sending, and of course sending the list will be voluntary at any time. This is the main benefit of the suggested feature. Additionally:

  • The scanned room IDs + timestamps will be used in the same way that CWA is working right now: The patient can (voluntarily) upload the list of scanned unique room IDs, CWA can download the list, and CWA can then display a warning to anybody who scanned the same ID at around the same time: "a covid patient was in the same room with you". This could be more precise than the current BLE for example in restaurants or offices with bad ventilation, where people can sit 20 m apart and still catch the virus through aerosols.

• The server side of CWA can compute statistics on room IDs scanned by people tested positive to find infection clusters. These highly relevant room IDs can be downloaded by CWA, which can then display a warning such as "you were in a room where several people got infected. Please inform the health authorities". This could help the health authorities to prioritize some investigations above others. For example, they could call contacts of somebody who was found to be in a cluster situation earlier than contacts of somebody who was not found to be in such a situation.

Problem and motivation

Current problem: contact tracing interviews are slow, and results are imprecise and incomplete. Imagine people had the option to quickly scan a QR code every time they go into a closed room. This would greatly improve the outcome of contact tracing interviews. Furthermore, it would have positive side effects as described above.

Is this something you're interested in working on

Yes

[daimpi]

@jniediek sounds good 👍

You might also wana check out the tread in #138 which discusses a similar issue and related solution proposals 🙂.

[alanrick]

Is the CWA team in contact with their developers for know-how transfer on the pros and cons of the method to be used?

Did anyone find time to contact the UK developers for _Do’s and Dont’s_ based on their experience of this capability in their live app (albeit a different mechanism)?

[AndreasHGIT]

Think the most of the people discussing this feature are aware of Luca, if not i guess it would be helpful to discuss the concepts, thoughts and so on with that project. https://luca-app.de/

[AndreasHGIT]

Hello Tim,
LUCA I see as a addition to the contact tracing the App does today.

The main use case I would see for Restaurants, Events and so on where today there is the obligation to have paperlists with persons, so that they can be informed if there was a COVID incident. In that case the Health authorities are checking the restaurants papers.

For sure in must be really discussed if the trust to the App would suffer if there is a additional functionality which requires a registration with personal contact data.

Regards

Andreas Hezel

Am 30.12.2020 um 15:39 schrieb Ein_Tim [e-mail]:


@AndreasHGIT

Thank you for the link, I did not know luca before.
If I understand correctly, this App still transfers the Data to the Health Authority (not anonymous)...
I think for CWA we should consider an approach without the health authority, since they already now have far too much work and, as already done by the UK App, it should be possible to introduce this without data transferred to the authority by building this on top of the GAEN-Framework (which also keeps the anonymity of everyone).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.