Cwa-documentation: Remote access is violating integrity, anonymity and data protection

[TomTeeJay]

The Scoping Document (only in german) https://github.com/corona-warn-app/cwa-documentation/blob/master/translations/scoping_document.de.md describes "supporting processes" in #User Story ID E07.01.

The RKI wants to manipulate tresholds directly on the devices. So forth the API is accessing and manipulating locally stored data directly on the device. It is intended to do this without any App Updates (ref. to 2: "Die Anpassung wird auf den Endgeräten vorgenommen, ohne dass ein Update der App erforderlich ist.")

It is not clear when and under what circumstances this will be done. The context of these supporting processes is not described in detail. Whether and how users are informed about this access is also not specified.

User Story E10.01 describes further changes of dynamic contents that are to be controlled centrally. A content management system is therefore updating elements within the App or the App is loading ressources from the web. In both cases this makes everybody identifyable.

Conclusion:

At least some "supportive processes" are violating basic privacy goals of data Integrity and anonymity due to the fact that certain tresholds and dynamic contents can be manipulated remotely.

[s-martin]

The RKI wants to manipulate tresholds directly on the devices. So forth the API is accessing and manipulating locally stored data directly on the device. It is intended to do this without any App Updates (ref. to 2: "Die Anpassung wird auf den Endgeräten vorgenommen, ohne dass ein Update der App erforderlich ist.")

But isn't that changing the parameters of the proximity algorithm and not modifying the data?

And this is not necessarily done by "remote access", the end user device could also pull the algorithm parameters periodically from a server.

[tkowark]

Thanks for pointing out this issue. We will provide more details on that process in upcoming documents.

[MalteJ]

For discussion of implementation details please wait for the release of our architecture documents and the app or backend code.

[egandro]

And this is not necessarily done by "remote access", the end user device could also pull the algorithm parameters periodically from a server.

Which is violating the privacy :) As you gain access to the IP + Timestamp you can easily estimate the location of the user. Having this with 30-50 mio phones - the privacy is gone....

[niklas2810]

Which is violating the privacy :) As you gain access to the IP + Timestamp you can easily estimate the location of the user. Having this with 30-50 mio phones - the privacy is gone....

...which can be done by any app on your phone. If you are really that paranoid, simply use a VPN on your phone and the problem is gone. There has to be a way to update parameters, and Play Store/App Store updates are just way too slow (and not mandatory).

Edit: And as MalteJ and tkowark mentioned, implementation details can be discussed when the actual architecture is released.

[TomTeeJay]

In my understanding the app must not lazy-load any content or ressources as egandro is correctly pointing out. These ressources de-anonymize users. And in your supportive processes you are even writing of changes to certain tresholds. And what about users using their devices offline without internet-access or behind personal firewalls?

Well with excitement I am looking forward to further code. But with an already broken App by Design and Default no code will make this better.

[egandro]

In my understanding the app must not lazy-load any content or ressources as egandro is correctly pointing out. These ressources de-anonymize users. And in your supportive processes you are even writing of changes to certain tresholds. And what about users using their devices offline without internet-access or behind personal firewalls?

That's the point. 3rd party can easily map IP/Timestamp to IMEI / Address / Clear Names. Having this possibility should be avoided by design!

[egandro]

Edit: And as MalteJ and tkowark mentioned, implementation details can be discussed when the actual architecture is released.

Design flaws should be discussed ahead!

Giving 3rd party the possibility to easily map IPs to Clear Names should be avoided by all means!

[MalteJ]

@egandro
I don't see where we give third parties the possibility to map IPs to clear names!?

[TomTeeJay]

@MalteJ : Well obviously one of us is missing something when your design document says, I quote:

Als RKI möchte ich die Inhalte der Applikation zentral verwalten, um Aktualisierungen von Texten, Links, Hotlines, etc. einmalig für alle Stellen in der App durchführen zu können.

Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert.

Aktualisierungen erfolgen in der ersten Version über ein App-Update.

There is no english translation of this yet, but this describes centralized tracking violating any descentralized approach.

[egandro]

@egandro
I don't see where we give third parties the possibility to map IPs to clear names!?

Really :(((

$ wget https://your-rki-server.de/settings.json

The server will get the IP of the devices. It creates a log file with a timestamp. So 50 mio users must trust YOU that 3rd party doesn't get access to this list of IPs...

Which they shouldn't!

Fun fact: I hope you don't use AWS / Azure Servers...

Find a better concept where this isn't possible by design! P2P, QR Code, ... there are so many many many posibilities.

[MalteJ]

@TomTeeJay it looks like you are not familiar with the "decentralized contact tracing architecture". Until we have released our design docs, you may find more information in DP3T's documents
https://github.com/DP-3T/documents

and from Apple:
https://www.apple.com/covid19/contacttracing/

[MalteJ]

@egandro

The server will get the IP of the devices. It creates a log file with a timestamp. So 50 mio users must trust YOU that 3rd party doesn't get access to this list of IPs...

True. But there are no clear names. Inherent to the internet design is the communication using IP addresses (pseudonyms). But we do not have any clear names and cannot provide any clear names to third parties.

[MalteJ]

By the way we will not persist the IP addresses. They are used temporarily for the time the connection is established.

[egandro]

@egandro
True. But there are no clear names. Inherent to the internet design is the communication using IP addresses (pseudonyms). But we do not have any clear names and cannot provide any clear names to third parties.

3rd party can do this :) Dial 112 and let them explain how easy a phone IP can be mapped to a name.

That's why nobody should trust this.

[egandro]

By the way we will not persist the IP addresses. They are used temporarily for the time the connection is established.

WHY should we trust this?

Get a better concept! Use P2P, use a QR-Code, use a Setting ID, ... there are so many many possibilities to solve this.

[niklas2810]

@egandro

WHY should we trust this?

You can never be sure whether the server provider uses the data responsibly. However, there is not much data collected (except for the IP address and current time, which is stored for every single request you make on the web, so I don't really get your point why this is such a critical issue on this particular project). The same issue could come up when submitting a positive test result (or similar cases where you have to communicate with an external server).

Get a better concept! Use P2P, use a QR-Code, use a Setting ID, ... there are so many many possibilities to solve this.

To my mind (!), fetching the updated settings from the server is the best approach. P2P can be really slow and will not affect people who don't have contact to others (these devices will update when they make contact again, which may be too late). Additionally, this would be way harder (and more time-consuming) to implement, could create new attack vectors (e.g. malformed data could corrupt the app, you could manipulate other user's settings, etc.) and would cause much unnecessary data transfer (as all devices would have to constantly compare their settings version). QR-Codes require manual user interaction, which will lead to many outdated client configurations.

[TomTeeJay]

Well. we are still talking about an Health App, aren't we?

If your App is using any dynamic content bypassing common update-mechanisms, then it's simply not considered as safe.

They are used temporarily for the time the connection is established.

Well even if this may be, or not, nobody knows. However this is not valid for anybody inbetween. The IP of a user already is an personal datum making him or her identifiyable. For instance as admin of a corporate network with hundereds of users I only need to wait till my users transfering a static ressource "I_am_infected.html" or a certain .json strings through my proxies to know exactly who is infected.

[QuadratClown]

WHY should we trust this?

At some point you have to trust a server you connect to, and i mean any server. Especially if you worry about IP addresses. P2P or QR-Codes are no solution if you dont want super bad fragmentation of update status (either by requiring manual entry or a inherently slow distribution protocol). So at that point its either "app is deployed completly finished and immutable" or bust. I don't think that'll work.

[egandro]

To my mind (!), fetching the updated settings from the server is the best approach. P2P can be really slow and will not affect people who don't have contact to others (these devices will update

I am no SAP / Telekom architect :) I don't do their job. I would avoid web calls to any Server by all means!

The whole point of #13 is, there is a privacy issue. I tried to explain how this is a problem. Collecting IPs is always an issues - weather you are allowed or not - this will be done by 3rd parties.

Here a better approach. Add a "RKI Mirror Server URL" - e.g. as Linux Distributions do it with their packet management. Put a GPG signature and let users create their own mirrors. Nobody can collect their device IPs.

In here you can have settings.json and warning.json.

People who trust the RKI can use this server.

[Ryuno-Ki]

GPG signature is a good point.
What about the server, from which data gets loaded, gets hacked?
Is there a way to detect this on client side?

I recall some Supply Chain Attack with Ukraine tax service servers or something like that …

[egandro]

GPG signature is a good point.
What about the server, from which data gets loaded, gets hacked?
Is there a way to detect this on client side?

I recall some Supply Chain Attack with Ukraine tax service servers or something like that …

This works for 20 years in Debian :) We have happy consistent mirrors.

Just using this infrastructure - instead of a REST based server can speed up the projects for weeks!

[niklas2810]

Here a better approach. Add a "RKI Mirror Server URL" - e.g. as Linux Distributions do it with their packet management. Put a GPG signature and let users create their own mirrors. Nobody can collect their device IPs.

I understand which point you are trying to make and I like this principle as well. But this can and will not work for the coronavirus tracing app. Why? An example: The settings.json file defines the minimum dinstance for a contact to be stored on the device. If there are 50 different mirrors out there, some of them may (let's be realistic: will) have different configurations. But that's not how the coronavirus works, we need common parameters to trace the infection chains in the most efficient way. And I don't want to start speaking about what happens when one of those mirror servers gets hacked, then I prefer one, but very secure, server.

For this settings.json data, this might include (which we don't know yet, because there is still a lot of work for the SAP employees to do! But I guess they will release it on GitHub, so we can have a look at it):

• Text, links (which can be manipulated then and may contain harmful content)
• The tracing parameters (which need to be commonly adjusted based on the latest scientfic evidence)

Additionally, the tracing keys of infected citizens will be stored on a central server as well (AFAIK), so I don't get the point why this should be an issue for the app configuration.

Edit: Most of the issues mentioned above be solved by verifying the central GPG signature. However, the implementation of such a system would take months and the app should be operational as fast as possible.

[egandro]

I understand which point you are trying to make and I like this principle as well. But this can and will not work for the coronavirus tracing app. Why? An example: The settings.json file defines the minimum dinstance for a contact to be stored on the device. If there are 50 different mirrors out there, some of them may (let's be realistic: will) have different configurations. But that's not how the

There are 51,000 Debian packages for 10+ Archs / CPUs.

So it can handle this :)

Edit:

settings.json {
   ttl: "2020-06-21T18:25:43-05:00",
  ...
}

Very very simple. If it's too old, your app gracefully tells you to update.

As debian mirrors already provide - it has a "last updated" timestamp.

So everything is solved!

[egandro]

Edit: Most of the issues mentioned above be solved by verifying the central GPG signature. However, the implementation of such a system would take months and the app should be operational as fast as possible.

SAP uses Sonatype Nexus anyway :) So a debian repository can be created with 2 clicks. It can be mirrored to a https server :)

GPG + Signature is included with basic CLI tools. A Debian client including GPG is available for all platforms.

I see no point in letting them collect IPs and then "fixing this because there is no time" later... NO! Won't happen.

[hirschnase]

I just want to mention that side-loading dynamic content would also collide with issue #14 as there would be no way to verify that, for example, links in the app are not manipulated or contain tracking id's.

[CodeExplorer22]

@egandro
I don't see where we give third parties the possibility to map IPs to clear names!?

It does via Bluetooth exploits. Try to fix that on old phones. Good luck. ;) Bluetooth was never secure and intendet to be used for something like tracking.

[egandro]

It does via Bluetooth exploits. Try to fix that on old phones. Good luck. ;) Bluetooth was never secure and intendet to be used for something like tracking.

This is all about a dedicated API.

So 3rd party might have direct access to the IP - which - needs be avoided by design.

The API for changing settings can be implemented without forcing users to trust a server.

[TomTeeJay]

In addition to the fact that the tracing app uses remote updates and dynamic content the app is not suitable for certain user groups with mobile phone and limited data traffic rates.

[MalteJ]

I am not sure about the legislation in regards to "Netzneutralität", but I could imagine that the mobile providers support this application by not billing traffic to the Corona-Warn-App servers.

[egandro]

I am not sure about the legislation in regards to "Netzneutralität", but I could imagine that the mobile providers support this application by not billing traffic to the Corona-Warn-App servers.

Please don't mock us :(

We really really want to help! The Debian-ish approach will cost you less development time and makes the app trustworthy. Of course your SAP / Telekom Geniuse Architects might have better ideas!

A REST call to a AWS / Amazon / RKI server will be a show blocker. You loose trust here!

There are so many many issues to solve - I didn't even find the Headlines in your documents, yet!

[ad2003]

@egandro

The server will get the IP of the devices. It creates a log file with a timestamp. So 50 mio users must trust YOU that 3rd party doesn't get access to this list of IPs...

True. But there are no clear names. Inherent to the internet design is the communication using IP addresses (pseudonyms). But we do not have any clear names and cannot provide any clear names to third parties.

When this app sees the users IP address just for one ms, it is not acceptable nor secure to use. Also other people around you would be tracked and so their IP addresses.

Right now, it would be the bundestrojaner2go.

I am glad you put it online, to have a discussion about it and that there is the open source approach, but seriously - this app should not be created and let into the wild without being secure.

Here is just a little thought play:
Let's assume, the app works. People are using it, they are traced and tracked - call it what you want. Now, one day, a person is infected and the app alert works - everyone else who was near this person's phone is now also seen a "threat" to health and society. Now you would only need a judge to decide, that this is dangerous for the society, and that there is imminent danger and in no time all IP addresses could be tracked back to the users to save society from those people - in the name of health. And then? People would be put in quarantine?

[egandro]

Let's assume, the app works. People are using it, they are traced and tracked -

Let's all be nice!

Please give us technical (not political) solutions here.

[MalteJ]

@egandro

I am not sure about the legislation in regards to "Netzneutralität", but I could imagine that the mobile providers support this application by not billing traffic to the Corona-Warn-App servers.

Please don't mock us :(

That was a response to the doubts in the post before that the app could consume too much traffic. So no mocking intended :)

[s-martin]

Right now, it would be the bundestrojaner2go.

That's a wild exaggeration.

It's an open source app, based on an open source protocol (please see https://github.com/DP-3T - many issues already discussed there) and when the code will be available here, everyone can review and improve it.

[egandro]

It's an open source app, based on an open source protocol (please see https://github.com/DP-3T - many issues already discussed there) and when the code will be available here, everyone can review and improve it.

True! But why should we trust a server that is collecting an IP + Timestamp?

3rd Party can easy map this to an address in realtime :) That is the issue about remote access.

[MaxFichtelmann]

@egandro if I understand correctly, the issue would be addressed, if the user could configure an alternative url as the settings source - from a mirror the user trusts.

A checksum derived from the currently used settings could be displayed to enable the user to verify that the settings are up-to-date.

Is there intention to push different configurations to different users (i.e. based on there location, due to differences in infection activity)?

[jeffreygroneberg]

Might be worth to have a look at: https://github.com/iCepa/Tor.framework

Tunneling http through the TOR network to avoid the real IP addresses of users.

[MalteJ]

I am not sure if we want to add 40M users to TOR using mobile devices. The mobile providers would kill us and we would probably kill the TOR network :D

[jeffreygroneberg]

How often do you want to pull data from the server? If its just a limited time on a frequent base there wont happen that much. Get a connection. Http call. Off we are. ;)

[seboslaw]

@jeffreygroneberg the problem is that once you "get the connection" and do the http call you've already setup the entire TOR stack, which doesn't come for free and will by itself put load on TOR. Plus, setting up the stack takes time (usually ~5-10 secs if there's no load) and the data transmission is slooooow :)
But maybe you could add it to the app as an onboarding option for people that desperately want it in a future release.

[egandro]

@egandro if I understand correctly, the issue would be addressed, if the user could configure an alternative url as the settings source - from a mirror the user trusts.

Yes! This works with Debian! 100% decentralized infrastructure.

In theory you can have even your FritzBox as mirror using a tiny App. With decentralized signed RKI files. It's very simple to setup.

I might consider doing a POC as soon as we have the source.

[egandro]

@jeffreygroneberg the problem is that once you "get the connection" and do the http call you've already setup the entire TOR stack, which doesn't come for free and will by itself put load on TOR.

TOR or what is better then nothing - add proxy support! Then we can fake our IPs

This is a 90 minute job for an IT student in 2nd semester.

[atdotde]

It seems to me the suggested problem is that a central instance learns the IP addresses of devices that have the app installed. This sounds practically unavoidable to me as long as you also need to communicate (even by polling) which IDs should be considered infected, any TCP connection has this feature. I don’t think this is a problem as it does _not_ contain any health or contact information which would be problematic.

[egandro]

It seems to me the suggested problem is that a central instance learns the IP addresses of devices that have the app installed. This sounds practically unavoidable to me as long as you also need to communicate (even by polling) which IDs should be considered infected,

NO :) Check this - http://ftp2.de.debian.org/debian/

This is the Debian mirror system. They use this for > 20 years now. We have a GPG signed file.

We could have a warningid.json file with a timestamp + list of IDs that are infected. This will be distributed to a mirror network. There is no need to ever do any communication to a server.

[LukasMasuch]

DP-3T also has a statement on this topic (TOR, IP anonymization) in their FAQ. They evaluated options for anonymous communication systems, but decided against it for their current version. There are also a few related issues on that topic in the DP-3T repository.

[MaxFichtelmann]

There is no need to ever do any communication to a server.

You would still need to transmit the TAN in case of a verified infection.

[egandro]

DP-3T repository.

This document is soooo funny :)

"In future versions of the app, if an approppriate anonymous communication network appears, we may include the option of submitting data anonymously to the backend."

... the option ... :) facepalm

[egandro]

There is no need to ever do any communication to a server.

You would still need to transmit the TAN in case of a verified infection.

I missed the word "central" server. Sorry. You can easily transfer the list of infected IDs by a decentralized server.... and I put in my app the mirror url https://mycastle/ ....

[jeffreygroneberg]

DP-3T also has a statement on this topic (TOR, IP anonymization) in their FAQ. They evaluated options for anonymous communication systems, but decided against it for their current version. There are also a few related issues on that topic in the DP-3T repository.

Thank you @LukasMasuch for the link!

[Spacefish]

Technical solution for this problem i propose:

• Do not download individual "parts" of information, but download a whole package, to avoid tracking usage of individual functions (like a "you might be infected" -> More information page) as this would straight out yield an IP <-> Possibly infected datapoint
• Do not put IP <-> Person data and Logs in the same hand (in this case Deutsche Telekom) as now we have a single entity that can log + de-anonymize.
• Do not put links like "click here for more information" which are exclusively visible to potentially infected persons, as this will leak the "potentially infected" status.
• For the "infected tokens" list it´s unavoidable for the app to download it, solution here would be to have multiple mirrors! The list is generated (hourly?) by RKI and the list "package" is signed. The app only accepts signed lists, but the source is not central but a randomly choosen mirror, there are probably dozens of organisations who would step up to host a mirror! The app is distributed with a list of mirrors included, one mirror is choosen at random on the first app-startup.. There has to be some circuit breaker logic in place which automatically selects a different mirror if one is broken though.
• Upload of recent tokens if a person is marked "infected" is unavoidable and has to be done, but is not an automatic thing but triggered by a user, so i don´t see that big of an issue here.
• Optional: Allow users to disable all data communication and supply the singned "infected tokens" list via an alternate source (like an external drive connected to the device)
• Optional: Allow export of all "seen" tokens to do comparison with "known infected" off-device / off-app. For example on a PC

I think it is really important that there is no data / privacy detail leakage by design, as otherwise this will surely get media coverage and would discourage tech-savvy as well as non-tech-savvy people from installing the app. This is a situation which should be avoided.

[simontb]

IMHO the concern most people criticizing the central approach was the possibility to track contacts, not the fact that an individual uses the app. Although I can understand this concern, let's acknowledge first that the more severe privacy issue has been addressed by going for a decentralized approach.

Yes, I know that an IP address can identify an individual person. But still with the proposed approach this could only identify who uses the app and not the contacts of a user or to determine if a user has been nearby an infected other user. That’s why I don’t agree with the thought play of @ad2003, because an IP address can only give a proximate location not accurate enough for contact tracing.

Additionally, I think people being concerned about this possible (project members already stated that IP addresses will not be stored) tracking also do not use a phone with Google Play services, so they wouldn’t even be able to use this app unmodified. But in #5 it was mentioned that for this scenario it’ll be possible to develop an publish a fork that is compatible with this app (https://github.com/corona-warn-app/cwa-documentation/issues/5#issuecomment-627860999). That fork could also use one or multiple mirrors of the RKI server.

IIRC the app will be open for PRs, so some of the suggestions could be even be addressed in this app. What I personally would like is if this app even accepted PRs for different product flavors (Android concept) like forFDroid and forPlay, but a fork would work as well.

Disclaimer: I am an SAP employee, but currently not involved in this project and this comment is based on my personal opinion.

[egandro]

IP addresses will not be stored)

As stated in this issue there are so many many many possibilities to avoid this. We use decentralized server infrastructures since day one of Linux.

WHY do you want a "Server"? There is no need to convince anybody if you decide against this architecture. A decentralized architecture based for example on a debian repository is so simple.

SAP uses Sonatype Nexus. It's 2 clicks and you have your Debian Repo. Use CLI tools to create a settings.json with timestamp or an infection-warning-list.json (with GPG signature).

Everybody can push this to their own servers and use a https://myhome-my-castle/ server URL.

For people who TRUST you - use a mirror of the government.

This is soo simple and it was explained in great detail many times! Go and talk to your architects.

[simontb]

IP addresses will not be stored)

As stated in this issue there are so many many many possibilities to avoid this.

Yes, but it seems the teams working on this did not make this a priority. But I hope they will be open to PRs offering the possibility to configure your own server (mirror). To me it looks like the decision for a REST server has been made. To me this is fine for now to get the app working in the first place. And once the code is published people not being okay with it (which I can understand although I don't share these concerns) can contribute PRs improving this app, fork the app, or even develop a new app from scratch. This is what makes open-source great! Let's hope the source code will be published soon. Then we can jump from conclusions from the docs to analyzing the source :)

Go and talk to your architects.

As said in the disclaimer: I'm not involved in the project and do not know more than is published already (incl. who is working on it).

[atdotde]

Yes, you could have mirrors of the RKI server. I am not sure if that additional level of complexity (you need to make sure the information on the mirror is up to date and if not how to you find other mirrors without quarrying a central service?) warrants the benefit (protecting the information that you are running the app (and nothing more) from the RKI moving it to the owners of the mirrors which again are "known" by IP address to the information providers one level up). I still think you are trying to solve a non-problem.

[egandro]

Yes, you could have mirrors of the RKI server. I am not sure if that additional level of complexity (you need to make sure the information on the mirror is up to date and if not how to you find other mirrors without quarrying a central service?) warrants the benefit (protecting the information that

Stop talking Fear, Uncertainty and Doubt!

We have this since day one of Debian! A decentralized server structure with GPG signed packages that can be mirrored by anyone.

No complexity! Just use what we already have.

[egandro]

Yes, but it seems the teams working on this did not make this a priority. But I hope they will be open to PRs offering the possibility to configure your own server (mirror). To me it looks like the decision for a REST server has been made. To me this is fine for now to get the app working in the first place. And once the code is published people not being okay with it (which I can understand although I don't

Let's wait for the opinion of the GI and the CCC about a centralized REST server :)

[Spacefish]

Let's wait for the opinion of the GI and the CCC about a centralized REST server :)

That should be avoided, as this will generate a lot of articles in the press like "Does the Corona App violates your privacy? XYZ says so". Which in turn will stop people from installing it.

There should be no privacy concern that could have been avoided from day 1 IMHO!

[Leseratte10]

I don't see the point in having this discussion here? If all the app is doing is talking to a server to check for parameters or download the list of infected IDs, then all the server knows is that at point A, there was a user of this app behind IP address B.

• The server doesn't know who you are
• The server doesn't know if you are infected
• The server knows a very vague region, based on the IP. IP locating, especially in cell phone networks, is very very inaccurate. Right now, geolocating my phone based on my IP gives me a location that is about 600km away from my actual location. All you are getting from this is the country, if you are lucky.
• The IP address, in cell phone networks, is shared between hundreds of users and changes all the time.

So basically, all the server knows from such a download request is that there is a person within Germany who has the app. The server doesn't know who you are, there's no unique ID, the server can't track you (as your IP changes all the time anyways on a cell phone), and it doesn't know how many phones are using the same IP.

I would agree that lazy-loading parts of the app would be a bad idea, but that seems easy to avoid. But IMHO, there's absolutely no reason to spend a whole bunch of time for a complex mirror infrastructure, just so the server doesn't see useless IPs.

[egandro]

I don't see the point in having this discussion here? If all the app is doing is talking to a server to check for parameters or download the list of infected IDs, then all the server knows is that at point A, there was a user of this app behind IP address B.

This is a bad design. Many many people here gave alternative concepts.

So let's have the discussion right here - right now!

I'll promise the CCC guys and GI will do this discussion.

There is absolutely no point in creating a REST API server! I know why 3rd party wants this, but it should be avoided by design!

[niklas2810]

I know why 3rd party wants this, but it should be avoided by design!

So you accuse the SAP devs of spying on the app users before even seeing their implementation? As the maintainers already said, this repository is for giving feedback, not for creating and implementing the software architecture (which is solely done by the SAP devs, at least as far as I am concerned), which is most probably already in development right now.

I think @Leseratte10 already pointed out quite well why a network request is not an issue. However, @Spacefish had some great thoughts on how to improve user privacy in his comment (even though I don't think that there is a need for a decentralized linux-package-likeI guess, but that's a thing we can focus on when we have actual code to refer to. But as I said, that's a thing we can focus on again when the actual source code is released and we don't speculate about things we simply don't know yet.

[evamvid]

This is a bad design. Many many people here gave alternative concepts.

I'm still unclear on what's inherently bad about this, since there doesn't seem to be any real privacy concern here.

My understanding was that most of the privacy concerns about a centralized server had more to do with the possibility of people's identifiable health information (i.e. names linked to test results) being stored on centralized servers, or the possibility of GPS data being stored on centralized servers, and the risk of that type of identifiable, personal data being leaked.

Since that's impossible by design with this protocol, I fail to see what the security risk of the centralized server is, especially given that every single user has the opportunity to use public wifi or a VPN or Tor or any of the other traditional IP obfuscation tactics if they really feel the need to.

And even if some sort of decentralized mirror server solution a la debian (and as far as I'm aware, the primary function of Debian's mirror system has more to do with load balancing than with any sort of privacy concerns) were to be implemented, doesn't that just shift the so-called problem? If the big concern is that IPs with timestamps might be being logged, who's to say that the hypothetical mirror maintainers aren't doing exactly the same thing?

[egandro]

we can focus on again when the actual source code is released and we don't speculate about things we simply don't know yet

Scope of this thread is a reference to a User Story.

Robert Koch-Institut (RKI)
Stellt epidemiologische Informationen und Handlungsempfehlungen für die Nutzer der App zur Verfügung (Content). Bestimmt die Parameter für die Messung der Kontakte (im Rahmen der technischen Möglichkeiten durch die API).  

WHY? is there an API on for a decentralized App?

This is a questionable design - before any code!

[niklas2810]

You still didn't answer on how you "know why 3rd party wants this".

This is a questionable design - before any code!

Quote from my previous comment: "As the maintainers already said, this repository is for giving feedback, not for creating and implementing the software architecture." Many other users already explained why this design decision is not an issue, and you didn't explain what is so critical about this design, as @evamvid already pointed out (except saying that this doesn't _have to_ be central, which is not a reason for changing the whole software architecture).

Nevertheless, please refer to the underlying implementation idea, which is the DP-3T protocol. In their simplified comic, you can see on page 8/9 why the parameters need to be adjusted (bc the 5min example is just an _example_) (in case you wanted to criticize that principle). Why the creation of a decentralized package-like system is not possible (or reasonable) was already discussed before, so I won't write or quote the same messages over and over again. When considering that the app's source code will be open to the public, you can make sure that they closely follow the DP-3T protocol and don't send any GPS data to their servers.

If you see an issue with their implementation, you can open an issue then.

[LukasMasuch]

WHY? is there an API on for a decentralized App?

Decentralized, in the case of this App, refers to the matching of exposures done locally in each phone instead of a central server. You can find more information on that topic in the FAQ of DP3T here (P7).

[Leseratte10]

This is not an API that is required for the contact tracing. It is an API for the developers to change the behaviour of the app. For example, to tune down the sensitivity if there are too many false positives. There is no reason to distribute these changes over mirror servers just to keep IPs of phones running the app secret.

And, of course, an API for the phone to access a list of infected clients.

[egandro]

And, of course, an API for the phone to access a list of infected clients.

Why not the phone downloading a list of infected IDs from a decentralized servers an comparing them to their own id?

We should trust 3rd party - why not 3rd party should trust us?

[egandro]

Many other users already explained why this design decision is not an issue, and you didn't explain what is so critical about this design, as @evamvid already pointed out (except saying that this doesn't _have to_ be central, which is not a reason for changing the whole software architecture).

The design IS an issue because 3rd party can access the server logs.

Why should we trust them that they don't do this "if there is en emergency"?

3rd Party can reverse map IP -> Address within a very short time. Why should we allow them to even consider this?

CCC and GI will explain why this is an issue in very great detail very soon :)

[Leseratte10]

HOW can they map IP -> Address? They CAN'T.
Geolocation is very inaccurate and, at most, gives you the correct state.

Google could also just access the server logs of Google Play and see who downloaded the app. Same issue.

[egandro]

HOW can they map IP -> Address? They CAN'T.

Go to your local police station - ask them "If a 3rd party of a government institution want's to map IP -> Address 'in case of an emergency' - how much time will this take?"

Why on earth should we give them access to such information? A lot of people fought for "no central data" - so why do you reverse this by a bad design?

If there is an API - it will be used for "a lot of things" in later revisions.

[evamvid]

Why not the phone downloading a list of infected IDs from a decentralized servers an comparing them to their own id?

"Decentralized server" is an oxymoron. A server is by definition a central point in the application's architecture, whether that server is operated by RKI or some sort of other maintainer. The only real way to truly decentralize this would be for all the necessary data to be transmitted via some sort of bittorrent-like peer-to-peer protocol, which is just so impractical and so far outside the scope of this project that it barely even is worth mentioning.

3rd Party can reverse map IP -> Address within a very short time. Why should we allow them to even consider this?

What 3rd party? And what exactly do you think can be done with this data? All than any potential bad actor who hypothetically gained access to a server with ip logs would be able to see is roughly the number of users of the app by rough geographical location. I'm not sure what exactly an attacker would be hoping to accomplish with the information that so-and-so many people in hessen have the app installed on their phone.

Go to your local police station - ask them "If a 3rd party of a government institution want's to map IP -> Address 'in case of an emergency' - how much time will this take?"

At least in the US, that process works by subpoenaing records from the ISP, and I imagine it's somewhat similar under german law. Your average joe can't just call up unitymedia and ask "who had this IP on this day at this time?".

Besides, anybody who has cause to be this worried about someone finding out their IP probably doesn't own a smartphone anyway, because that IP is logged by hundreds of untrusted servers per day, since literally every packet of data a device sends over the internet is stamped with it (unless, of course, they use a VPN or any of the myriad of other ways it's possible to change your IP).

[AlexanderS]

how to you find other mirrors without quarrying a central service?

Just use DNS. It it already decentralized and the entries can be signed. It can also be used to distribute the timestamp of the last update (TXT records).

[IXArcanumXI]

We're talking about IPv4 communication, right? Aren't the mobile providers using NAT (Network Address Translation, specifically CGN/LSN) anyway? So, if I'm not mistaken, the external server would only get the public IP, which should be the same for a large amount of mobile users, while the internal IP remains private between the user and the provider. Only exception would be communication while using WiFi.

[egandro]

since literally every packet of data a device sends over the internet is stamped with it (unless, of course, they use a VPN or any of the myriad of other ways it's possible to change your IP).

It's still using a server from the government :) This has direct access to 50 mio devices.

Do you see the acceptance problem here? That's the point.

You try sell a non technical - but ideological idea here.

If it's my server - my mirror - there is zero acceptance issues. I see what I download and I know what I download. I never ever send any data to a government server - by design.

[niklas2810]

You try sell a non technical - but ideological idea here.

Please keep in mind to be polite and do not make reproaches.

It's still using a server from the government :)

That may be correct as _we still don't know the technical infrastructure_. But it makes no difference since they are also obligated to follow the German legislation. If you per se don't trust the goverment that's not an issue of this project.

If it's my server - my mirror - there is zero acceptance issues. I see what I download and I know what I download. I never ever send any data to a government server - by design.

...and it would still need much more time to develop just a system. Please keep in mind that SAP has a contract with the Germany goverment to develop such a system at that they have to pay money for the development of this app (and therefore don't have the ability to invest weeks in creating such an extensive archtitecure). Alternative approaches like the usage of the DNS system or a package managment system are just incredibly complicated or have other downsides (such as slow spread of updates, complex architecture).

As this discussion is circulating around the same arguments and counter-arguments, I don't see any reason why we should proceed; we are discussing based on speculations, not facts (even though you claim that the system is inherently bad by design) and should wait until the source code is released.

[egandro]

That may be correct as _we still don't know the technical infrastructure_. But it makes no difference since they are also obligated to follow the German legislation. If you per se don't trust the goverment that's not an issue of this project.

Yes :) Wasn't this the main discussion during the last 4 weeks? No central server?

We learned two key concepts.

1) There is an RKI Api for changing settings and putting "content" to the device. This is what #13 is all about.

2) There is a "Heath server" from the government. This contains the list of infections. The devices will access this.

So yeah :) This needs discussion. No circulation detected - just fishy concepts.

[Leseratte10]

What information does the government gain from finding an address to an IP? That only tells them that you are using the app. Is THAT a fact that needs to be hidden? No, it's not.

And entities other than the government can't just go to an ISP and demand to know a name to an IP.

[simontb]

Yes :) Wasn't this the main discussion during the last 4 weeks? No central server?

No from my point of view the main discussion was about where to store the contacts of a user: upload to central server or leave them on the user's devices. The result was the latter.

You can discuss the necessity of a central server at all, but please do not mix this with the storage location of contact data. I think this would underrate how much more sensitive these contact data are compared to the data about who uses the app overall.

[egandro]

What information does the government gain from finding an address to an IP? That only tells them that you are using the app. Is THAT a fact that needs to be hidden? No, it's not.

Why give the government DIRECT ACCESS to the devices?!

There is no need for that.

[egandro]

You can discuss the necessity of a central server at all, but please do not mix this with the storage location of contact data. I think this would underrate how much more sensitive these contact data are compared to the data about who uses the app overall.

Contact data are meaningless IDs. A public list of infected IDs can't be used for any bad things. If it's signed - it's authentic. If it has a Timestamp - it's up-to-date.

So why should a device connect to a government server? A small list (the list has 100-200-1000-IDs) should be rather decentralized then having a REST server :)

The REST API will gain zero (!) acceptance. There is only one more step that it can be used for more stuff then downloading a list.

[Leseratte10]

Did you read what the interface is supposed to do? It's supposed to provide TEXTS and SETTINGS and infected IDs when asked by the App. It doesn't give anyone access to your device, or to update code.

Same as using Firefox to visit your government's web site doesn't give them access to your computer.

[clncln1]

Why give the government DIRECT ACCESS to the devices?!

This is simply a false claim. Having the app instances pull detection settings and UI labels from a server, does by no means give the government access to your device. Potential misuse of that interface in upcoming releases is avoidable since the code is open-source, and you can even go ahead and implement your own client.

All users who prefer a higher level of privacy by IP anonymization are free to do so, just like for any other internet traffic.

[hoelzlw]

Dear @egandro, could you explain at least once, which solution would satisfy you?
I've read the entire discussion, but I haven't found any constructive advice from you.
You keep saying do it like Debian, but you don't explain what exactly you want and how it should be done.
I'm talking about details; technical details; not just continuously repeating the word mirror.

I can understand your problem: All devices connect to a server run by RKI and download two files. RKI then has a list of IP addresses. You keep talking about a third party abusing this data. Who is this third party? The RKI?

You propose a mirror system as a solution. Okay. How do you deploy it? How exactly are the mirrors communicated, i.e. after installing the app, how does it chose the mirror?
Debian comes with a list of known mirrors and does a speedcheck after installation to identify the most suitable ones. This works, because Debian has this list of known mirrors.
So, the app needs a list of known mirrors, too. Who decides which mirrors go on that list?
Even if you implement the option to insert the address of your own mirror, the app must come with a working default.
Since most users do not understand what a mirror actually is, this doesn't improve anything, as they will stick to that default mirror.
The only difference is now, that tech-savvy people gain the possibility to insert their own mirror server.

What exactly is your improvement now?
Now, the RKI sees the IP of your mirror server fetching the files, instead of your mobile device's IP.
If you were on mobile network, you just cannot get a useful location from an IP, especially when NAT is involved.
But from a server? Location is now obfuscated if, and only if, you're renting some server in some datacenter. Running it at your home usually gives a good location.

Then: When you claim, the RKI collects all the IP addresses and does address lookups... what exactly prevents the people running the mirrors from doing exactly the same?
RKI is bound by GDPR (dt. DSGVO), as a third party contractor collecting data.
A private person running some mirror voluntarily is not bound by the GDPR as it's a private thing (Art. 2, Nr. 2, lit c).

I see, how a BitTorrent-like P2P network can increase privacy.
I see, how using TOR can increase privacy.
I see, how scanning a QR-code, shown in some TV-channel at the upper right corner, increases privacy.
But your mirror approach does not increase privacy, simply because the mobile device's IP address will end up at some server which offers the data.
We're talking about 50 Mio. devices. Even with 100 mirrors every mirror ends up with 500k daily connections.

The goal of Debian's mirror system was load balancing and this is, what you actually get.
You decrease the load of RKI's servers; but you don't get privacy.

[hoelzlw]

how to you find other mirrors without quarrying a central service?

Just use DNS. It it already decentralized and the entries can be signed. It can also be used to distribute the timestamp of the last update (TXT records).

Could you just elaborate how to solve this with DNS?
Given a list of mirrors
mir1.tld, mir2.tld, mir3.tld
as well as some official server
app.rki.de

In order to distribute the different mirrors via DNS, the RKI needs to put the mirrors' IP addresses in their zone file with the name of the official server.

Who decides what mirrors go into that zone file?
How to add your personal mirror?
How to avoid bad mirrors?

Finally: How do you prevent the people running the mirrors from collecting data?
I mean the data, that you accuse the RKI of collecting and abusing.

[CodeExplorer22]

If those private servers just work as a tunnle and those tunnles are trustworthy the IP issue would be solved. But we have the same problem with such infrastructure. Who can ensure that the tunnles are trustworthy???

The only way to prevent them from seeing your IP is to use a VPN provider of your trust. Then you can send the data directly to the main server.

The whole design concept of this app is flawed from start to finish.

[egandro]

Dear @egandro, could you explain at least once, which solution would satisfy you?

I already explained 5 concepts

Others have very nice ideas, too.

[egandro]

If those private servers just work as a tunnle and those proxys are trustworthy the IP issue would

No we don't want a direct REST based government access to 50 million cell phones!

This is will create no acceptance of the target group.

[egandro]

Given a list of mirrors
mir1.tld, mir2.tld, mir3.tld
as well as some official server
app.rki.de

That'a afaik the correct way. That is what Debian does for 20 years.

You can have your own mirrors even on your local Fritzbox or on your companies router...

[jarjarbentley]

Just wanted to bump this thread with two comments, 1. as @MalteJ said, we should wait for release of architecture documents and back end code before going too far down a hypothetical path. and 2. the scoping document is now out in english for those interested: https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md

[CodeExplorer22]

Given a list of mirrors
mir1.tld, mir2.tld, mir3.tld
as well as some official server
app.rki.de

That'a afaik the correct way. That is what Debian does for 20 years.

You can have your own mirrors even on your local Fritzbox or on your companies router...

And who ensures that all of these mirrors are trustworthy?

[evamvid]

No we don't want a direct REST based government access to 50 million cell phones!

@egandro, could you elaborate on the supposed danger of a REST API (what I'm wondering is why a REST API in particular is worse than any other HTTP request to a server)?

Also, I'm still not quite clear on how exactly the mirrors function to increase security.

[CodeExplorer22]

No we don't want a direct REST based government access to 50 million cell phones!

@egandro, could you elaborate on the supposed danger of a REST API (what I'm wondering is why a REST API in particular is worse than any other HTTP request to a server)?

Also, I'm still not quite clear on how exactly the mirrors function to increase security.

They can't, because they are not or not more trustworthy than the main server by default.

[s-martin]

Given a list of mirrors
mir1.tld, mir2.tld, mir3.tld
as well as some official server
app.rki.de

That'a afaik the correct way. That is what Debian does for 20 years.
You can have your own mirrors even on your local Fritzbox or on your companies router...

And who ensures that all of these mirrors are trustworthy?

I agree, at some point you have to trust somebody.
I don't understand why anybody providing a mirror would be more trustworthy per se to not collect IPs than the government agency.

If you don't trust them, then you can use a VPN or TOR, but then you have to trust these providers in a way.

[s-martin]

And how does the setup of Debian package mirrors prevents the collection of IP addresses by the provider of the mirror?

Debian solves load balancing with these mirrors, not prevention of collecting IPs.

[Leseratte10]

No we don't want a direct REST based government access to 50 million cell phones!

This is not a direct connection TO a phone. This is a phone connecting TO a server, whenever it wants.

That's like saying "we don't want government access to a web browser" just cause 50 million people visit the government website a day.

[jeffreygroneberg]

This is will create no acceptance of the target group.

lol :) Are you talking about the target group, that is running Facebook, Whatsapp, Instagram and TikTok on their devices? Then you mean the 95% of people that don't bother if an app is tracking their life. So they for sure do not bother if a hypothetic lookup of their mobile IP address might happen.

[CodeExplorer22]

This is will create no acceptance of the target group.

lol :) Are you talking about the target group, that is running Facebook, Whatsapp, Instagram and TikTok on their devices? Then you mean the 95% of people that don't bother if an app is tracking their life. So they for sure do not bother if a hypothetic lookup of their mobile IP address might happen.

That's not an argument. This app comes from the government. It has to be transparent, trustworthy and secure.

[jeffreygroneberg]

I am pretty sure this will be the case. Even though it is pulling data from a central instance. As it is open source you will see:

• The frequency of the pulls
• The parsed payload
• And even inspect if a bidirectional connection might exist (that should be avoided by all means)

[jeffreygroneberg]

But your mirror approach does not increase privacy, simply because the mobile device's IP address will end up at some server which offers the data.

Great comment and great content! Thanks!! @hoelzlw

Even with mirroring there WILL be a server having the data. So it's just a shifting of insights from one instance to another.

[CodeExplorer22]

I am pretty sure this will be the case. Even though it is pulling data from a central instance. As it is open source you will see:

• The frequency of the pulls
• The parsed payload
• And even inspect if a bidirectional connection might exist (that should be avoided by all means)

How easy is it to log the IP's. Nobody will notice that. Come on. ;) As I said earlier. The app is based on a complete insecure base. Bluetooth has multiple security holes. This app is a bad idea.

Can you make it work? Yes of course. Is it secure, no it will never be secure.

[djmaze]

@CodeExplorer22 Are you a Bluetooth expert? I recently listened to an interview with two Bluetooth security researchers. They argue that the way the proposed tracing works (by not even establishing connections at all) minimizes the attack surface and makes it really hard – if not impossible – to exploit devices this way.

[Leseratte10]

Yes, it is easy to log the IPs. But there is NOTHING you can do with these IPs. All that tells you is that there is a user in Germany that just requested data. You (as server owner) have no way to connect that IP to any real name, identity, COVID test result, or any other useful information,

Nobody forces you to use this app. Compared to other apps or software by the german government, what they are doing here is way, way, way better than anything ever before. Public github repo for early designs, and a planned public repo for app and server source code.

If YOUR 5-year old, no longer updated cellphone has bluetooth security holes, that is your fault. Not the fault of the government making an app that uses bluetooth. If YOU leave your phone laying around unsecured, it's not the government's fault if your spouse sees your COVID test result.

All this behaviour that happens in these github issues will just tell the government "okay, if we open source an app, all we get is junk issues (#13 (this), #20, #23, #28, #29, #53) or complains about Github (#9, #15) - all 8 created by the same user ...) or gendering PRs (#27)". That will certainly motivate them to put future stuff under an opensource license as well ... NOT.

[CodeExplorer22]

@CodeExplorer22 Are you a Bluetooth expert? I recently listened to an interview with two Bluetooth security researchers. They argue that the way the proposed tracing works (by not even establishing connections at all) minimizes the attack surface and makes it really hard – if not impossible – to exploit devices this way.

Google this: SweynTooth vulnerabilities. Older versions of android and older chips have more vulnerabilities.

[CodeExplorer22]

Yes, it is easy to log the IPs. But there is NOTHING you can do with these IPs.

What? It takes them 10 minutes or less to get you phonenumber and your name. What are you talking about.

Nobody forces you to use this app.
We will see. Nobody know it now.

If YOUR 5-year old, no longer updated cellphone has bluetooth security holes, that is your fault.

Come on. ANY Bluetooth (BC and BLE) chip and android version has holes like a piece of cheese. SweynTooth vulnerabilities allow you to crash android in the best case, in the worst case you take over the phone. Do you expect my 75 year old mother to keep her phone updated? This is irresponsible. 60% of all phones run Android 8 or lower and is not supported any longer. What should these people do. How will you get 50.000.000 users if you not securely support their platforms? This app is nonsese for many reasons. Do you realy think people will not exploit this with such many installations. Dream on.

Maybe they can force all vendors and Google to push updates until android 5. :D

[Spacefish]

What information does the government gain from finding an address to an IP? That only tells them that you are using the app. Is THAT a fact that needs to be hidden? No, it's not.

It could be! Imagine a legal case where person A goes to a "big public event", Persons As app told them before that they are potentially infected. During that event person A infects multiple other people and later on it was determined that person A was the "spreader", there is some suspicion that person A did know that he was potentially infected and visiting the event knowing that you are potentially infected was prohibited.
To prove that person A did know his status, one could ask person As ISP whether he used the app or not and on which device (IMEI), with this information there is reasonable suspicion to warant the confiscation of As mobile device with that IMEI.

Granted, this is a very constructed case, but such information is actually used in criminal cases and there are ways the info, that you used the App in the first place, can be used against you! It´s pretty hard technically to create plausible deniability in this case though.

[pitsch]

trust needs to be analyzed on the basis of what is already happening in the analogue world, with manual contact tracing. the graph of trust between doctor, test lab and health authority and probably hospital and other health providers is well described for various digital health applications. the communication overhead with two new entities introduced by this app (QR code and Hotline call center) needs to be simplified and replaced with only one secure and trustful channel, which is usually the local health authority where all the info is collected anyway for a positively tested person.

an exposure notification combined with light symptoms is legally a requirement to register at your health office. this leads to a recursive effect which can be helpful in tracing and testing to break infection chains to add preselected risk cases into the queue of the workflows of manual tracing teams.

in case your corona test turns out to be negative, its easy do disable and delete a "user registration" at a health authority with a trustful backend running SORMAS automatically.

and btw, telephone communication, reading and telling whats on the screen on your phone is surely an OPSEC risk of higher degree than described here, it adds more work load on all sides and is not to be confused with an air-gapped avoidance of an untrusted man in the middle or "centralized" server.

the whole app follows a incomplete design approach of DP3T which pretends that the health system is inherently not to be trusted. in germany its a federated infrastructure with 400 servers (if fully upgraded..) and the regionalized federalism is not recognized in the decentralisation/centralisation debate as the main operational principle to support with this app.

[Leseratte10]

What? It takes them 10 minutes or less to get you phonenumber and your name. What are you talking about.

Cell phones share their IP addresses with many other people. If I tell you the IP my phone currently has - 80.187.100.153 - there is absolutely nothing you or the government could do to get from this IP to an actual name. Even IF you asked my ISP and even IF they are 100% willing (or forced) to help, what are they going to do? All they could give you would be a list of the 1000 people that used this IP that day. If they are even logging that.

[CodeExplorer22]

Cell phones share their IP addresses with many other people.
Wifi?

[djmaze]

@CodeExplorer22

Come on. ANY Bluetooth (BC and BLE) chip and android version has holes like a piece of cheese. SweynTooth vulnerabilities allow you to crash android in the best case, in the worst case you take over the phone.

I just read up on SweynTooth. It affects only IoT devices (wearables etc.) but no smartphones. Please do a better research if you make loud and bold claims.

That said, there are real Android vulnerabilities like CVE-2020-0022. Looks like you need at least Android 8 in order to get fixes for that. So having an older phone without updates still poses a problem.

[Leseratte10]

Maybe they can just add a setting to force the app to use Mobile networks, force it to use WiFi, or use both. Then everyone can pick whatever they want. If you make it default to WiFi, you'll get privacy complains. If you make it default to mobile connection, you'll get complains that this uses your precious data. Just let the user decide what they want, and the problem is solved.

[simontb]

What information does the government gain from finding an address to an IP? That only tells them that you are using the app. Is THAT a fact that needs to be hidden? No, it's not.

It could be! Imagine a legal case where person A goes to a "big public event", Persons As app told them before that they are potentially infected. During that event person A infects multiple other people and later on it was determined that person A was the "spreader", there is some suspicion that person A did know that he was potentially infected and visiting the event knowing that you are potentially infected was prohibited.
To prove that person A did know his status, one could ask person As ISP whether he used the app or not and on which device (IMEI), with this information there is reasonable suspicion to warant the confiscation of As mobile device with that IMEI.

Granted, this is a very constructed case, but such information is actually used in criminal cases and there are ways the info, that you used the App in the first place, can be used against you! It´s pretty hard technically to create plausible deniability in this case though.

No! You can't derive whether a person has been warned. Yes, you know that this person used the app, but you can't know that the person has been warned (unless you gain access to the smartphone in which case you don't need any information the server has on person A anymore). The notifications to warn a user are not sent by the server, but instead the devices fetches all infected IDs and compares them locally to the IDs of the users person A met in the past days. So the notification is generated locally.

[hoelzlw]

Dear @egandro, could you explain at least once, which solution would satisfy you?

I already explained 5 concepts

Others have very nice ideas, too.

Ehr, no, you didn't explain anything.
You just keep repeating the word mirror.

Look, we are not incompetent idiots who are too stupid to spell the words PC or CPU. We know what a mirror is, but you don't seem to understand the problems with that approach.

I see your problem with 50M devices accessing a server run by the RKI, but let's get in more detail here.

We have the following problem: One server has some data, 50M users want that data and we use a communication protocol which exposes a pseudo-identity to the other party. Now distribute this data such that privacy is maximized. How do we measure privacy? Apparently by minimizing the number of IP addresses a server gets to see.

So, as long as we have only a small number of mirrors, the users' IP address is a delicate information and the mirrors' providers get to see that information. The moment we have a large number of mirrors, the mirrors' IP addresses becomes a delicate information and the official server gets to see that information.
There is absolutely no gain in privacy, when everybody runs their own mirror on their own router at home, simply because their router has to fetch the data from the official server, leaving the router's public IP address in the server logs.
Just explain, how that's different from the user's mobile device fetching the data from the official server while being connected to their wifi. Because that will also leave their router's public IP address in the server logs, just saying.
This simply renders your "Everybody runs their own mirror on their private router at home"-approach useless.
If you have a mirror at work, you have to have a way to inform the app about this.
However, the initial installation must have a working configuration and you must have a working configuration for everybody whose employer does not set up a mirror.

Apparently, there is a sweet spot somewhere around the square root of the number of users. If we had 7000 mirrors and each of those provides data to 7000 users, everybody gets the data while the official server only gets 7000 server IPs and every mirror only gets 7000 user IPs.
Increasing the number of mirrors just makes the mirrors' IPs more valuable and trackable and decreasing the number of mirrors just makes the users' IPs more valuable to the mirror providers.
(See note at the end).

Then: How do we decide which server gets on the mirror list? Because we need to ensure, that the person running the mirror does:

1. Keep their system up to date without any security vulnerabilities.
2. Provide the latest data from the official repository.
3. Does by no means ever collect any user IPs.

Note: The Debian project does not ensure any of these! Everybody can ask them to include their mirror into the official mirror list: https://www.debian.org/mirror/submit
Of course, nobody can push malicious packages, because the packages are GPG-signed.
But nobody prevents anybody from collecting IPs -- and, collecting IPs is the problem we try to solve here, no?
The Debian mirror system is designed as a load balancer and not to prevent the user's IP address to show up at the Debian server logs!
Right now Debian has 425 mirrors: https://www.debian.org/mirror/list
Given 50M users, this results in 120k IPs per mirror per day.
If devices change the mirror on a daily basis, it takes a month to collect nearly 4 million IPs.
In order to make this system private, we need to create a huge base of mirrors (around 7000, i.e. 16 times the mirrors Debian already has) in record time.

Then: Even, if we agree that a few hundred mirrors are enough, it is not enough to just use that many different servers. In fact, we needed a few hundred different and non-cooperating parties to run these mirrors, as nothing will prevent them to combine and aggregate their data.

This leads to the next problem: How to get so many non-cooperating parties running a mirror? Private volunteers?
Why would they be more trustworthy?

Serious question: If you had a mirror mirror.egandro.de, why on earth should I trust you to not collect my IP address?
Should I trust you because you promise not to?
Since you do it for private fun, you're not bound by the GDPR and, thus, you wouldn't even face consequences for doing it nonetheless.

You just move the point of initial trust away from the RKI to another party without explaining why anybody should trust a random stranger on the internet.

Here is a solution for your problem:
The server at the RKI (which is probably some anycast cluster anyway) is set up in such a way, such that it doesn't log any IP addresses. Data that isn't stored cannot be abused.
How do we ensure this? By a proper audit.
Who should do the audit? CCC and GI, and if necessary, you; the people who criticize the most and who have the highest chance to create and prevend FUD.
How could Iran prove they have no nukes? Easy: By having their biggest enemies USA and Israel confirm they haven't.

This, however, comes with the precondition, that a setup that satisfies CCC and GI, and other people like you actually exists in the first place.

Summary, just in case you keep repeating saying mirror:

• There's nothing that prevents the mirror providers from collecting and abusing the IP addresses from the systems connecting to it. If the providers are private volunteers, they don't even face consequences.
• There is no basis why a random stranger on the internet should receive more trust than the RKI.
• Having everybody run their own private mirror is useless, as the official server could simply collect these mirrors' IP addresses.

Note at the end:
Actually, a hierarchical approach is best for maximizing privacy.

• 7000 mirrors contact the official server -> 7000 mirror-IPs at the RKI
• 80 sub-mirrors contact one mirror -> 80 sub-mirror-IPs at every mirror
• 8 sub-sub-mirrors contact one sub-mirror -> 8 sub-sub-mirror-IPs at every sub-mirror
• Every device contacts one sub-sub-mirror -> about 12 device IPs at every sub-sub-mirror

This is like a multigrid-scatter-all-algorithm for distributing data while minimizing communication.
Minimizing communication automatically leads to a minimal number of IP-addresses at every server.
Now you just have to deploy these sub-sub-mirrors to the devices... in a private way, mind you, because downloading a mirror list automatically means contacting a central server.

[TomTeeJay]

Data that isn't stored cannot be abused.

Well, quite true. The fact that RKI or a stakeholders does not store IPs takes not into account that everybody else inbetween may do this. Every "Eve", wifi-operater, admin in corporate network, wifi-wardiver may act as MitM.

Nevertheless, I suggest we put our 2nd thoughts aside and wait till we see some code or advanced documentation.

[hoelzlw]

Given a list of mirrors
mir1.tld, mir2.tld, mir3.tld
as well as some official server
app.rki.de

That'a afaik the correct way. That is what Debian does for 20 years.

You can have your own mirrors even on your local Fritzbox or on your companies router...

No, Debian does this for load balancing and not for privacy.
Nobody on this planet tries to prevent the official Debian servers from seeing the IP addresses of machines running Debian.

1. You need to distribute the list of mirrors to the devices without the devices contacting the official server.
2. Mirrors are not just there. Someone has to set them up and has to run them. However, there is no authority that prevents these providers from collecting IPs.
3. A mirror on your company's router doesn't appear from alone in the app. You need to communicate this information somehow.
4. A mirror on your local Fritzbox is useless, as your Fritzbox will have to fetch the data from the official server, leaving your public IP in the server logs. Since this is most likely a landline endpoint, such an IP address is easier locatable than a mobile IP. This means, your proposal to use your local router makes the thing you try to solve even worse.

[hoelzlw]

Data that isn't stored cannot be abused.

Well, quite true. The fact that RKI or a stakeholders does not store IPs takes not into account that everybody else inbetween may do this. Every "Eve", wifi-operater, admin in corporate network, wifi-wardiver may act as MitM.

There's absolutely no way to prevent this other than using a VPN or pushing the information via a daily App Store or Google Play Store update.

[TomTeeJay]

There's absolutely no way to prevent this other than using a VPN or pushing the information via a daily App Store or Google Play Store update.

of course there are federated, decentralized and distributed possibilities

[egandro]

Summary, just in case you keep repeating saying mirror:

• There's nothing that prevents the mirror providers from collecting and abusing the IP addresses from the systems connecting to it. If the providers are private volunteers, they don't even face consequences.
• There is no basis why a random stranger on the internet should receive more trust than the RKI.
• Having everybody run their own private mirror is useless, as the official server could simply collect these mirrors' IP addresses.

I can mirror the data do my own local server - from a mirror - or from a submirror. Maybe a simple Fritzbox App or a simple PC / mac / Linux / ESP32 Program.

My Phone IP is still concealed. According to my knowledge - that you can't map the ID that was used for BT to my Phones IP.

None of the server knows that my phone even exists or existed...

[hoelzlw]

There's absolutely no way to prevent this other than using a VPN or pushing the information via a daily App Store or Google Play Store update.

of course there are federated, decentralized and distributed possibilities

Really? Which one, other than TOR?
Why don't you just provide a link, rather than claiming the existence of well known solutions (you're talking plural here)?

If any of you had a solution which is inherently superior without any drawbacks, you could just name it and the developers will consider it.

Decentralized means creating a distributed system which answers the requests.
How do the devices contact that distributed system without a publicly known entry point?
How do you prevent the Eves of this planet from joining the distributed system and collecting the IPs?
How do you detect an Eve in that distributed system and how do you punish them in case they become malicious?
Who is part of that decentralised system and why should people trust them more than the RKI?

The only real way is TOR, but when you really plug 50M mobile devices into the TOR network, the people running the end nodes will "jump in your face with their naked butts".

[egandro]

How do the devices contact that distributed system without a publicly known entry point?

Answer: enter a URL: https://mycastle/ instead of https://rki.de/

Why do we need a bidirectional communication :) Check the scope of #13

It's about loading "content" and a "settings" file.

Please explain...

[hoelzlw]

Summary, just in case you keep repeating saying mirror:

• There's nothing that prevents the mirror providers from collecting and abusing the IP addresses from the systems connecting to it. If the providers are private volunteers, they don't even face consequences.
• There is no basis why a random stranger on the internet should receive more trust than the RKI.
• Having everybody run their own private mirror is useless, as the official server could simply collect these mirrors' IP addresses.

I can mirror the data do my own local server - from a mirror - or from a submirror. Maybe a simple Fritzbox App or a simple PC / mac / Linux / ESP32 Program.

You accuse the RKI of collecting IP addresses.
In case the really do, now they just collect the IP address of your router.
Since it's landline, locating that IP address is way easier than locating the address of a mobile device.
This contradicts your entire argument about prevention of IP address-based location and you don't even notice it.

Furthermore: How do you get the mirror list?
Where is it stored?
Who decides which servers to add to that mirror?
Finally: How do we prevent the people running these mirrors from collecting IP addresses?

My Phone IP is still concealed. According to my knowledge - that you can't map the ID that was used for BT to my Phones IP.

If you're in your home's wifi, you either use your home's public IPv4 via NAT or your home's public IPv6 prefix alongside with a temporary private IPv6 address.
Your router or your local server does the same when connecting to the server for fetching the data.
There's no difference here.
Having everybody running their own private mirror is no improvement in privacy, as one then just collects the mirror addresses.

The only way for this to conceal your IP would be a dedicated server in a datacenter.

Furthermore: Why would the BT-ID be transferred to the server?
How could the server know the BT-ID?

None of the server knows that my phone even exists or existed...

Who cares about your phone?
I have your IP and you keep telling us that that is enough to uncover your identity.

[hoelzlw]

How do the devices contact that distributed system without a publicly known entry point?

Answer: enter a URL: https://mycastle/ instead of https://rki.de/

Why do we need a bidirectional communication :) Check the scope of #13

It's about loading "content" and a "settings" file.

Please explain...

How about you finally explaining at least once, how your local mirror mycastle.tld gets the data from the official repository?
You accuse the RKI of collecting IP addresses, but with having mycastle.tld running in your home network rather than in a datacenter, the official server you pull from will learn your IP address.
If I decide to use your mirror server, how can I be sure that you're not collecting my IP address?

Mirrors for concealing IP addresses work, if and only if, many users hide behind a mirror.
If everybody runs their own mirror, there's no gain in privacy, as the official server can easily collect the mirrors' addresses.
Now, the point of initial trust is moved to the mirrors.
Who guarantees, that these mirrors are trustworthy, especially when they're provided by volunteers?

[egandro]

Who cares about your phone?
I have your IP and you keep telling us that that is enough to uncover your identity.

• giving 3rd parties a direct REST base access to 50 mio phones is a generic acceptance violation
• giving 3rd parties the fastes possible opportunity to directly map an IP to an ID is a generic acceptance violation
• using a REST API with a public address gives companies with corporate firewalls the opportunity to log and check every byte that is transfered via https (we are still talking about medical data that is protected by the law)

[egandro]

How about you finally explaining at least once, how your local mirror mycastle.tld gets the data from the official repository?

Using debian mirror tools we use now for > 20 years?

I can use a German mirror - a US mirror - a China mirror. The integrity of all files is guaranteed by a GPG signature.

Edit: to be 1000% crystal clear - https://mycaslte has NO tld! it's just my local mirror (Laptop, ...)

In the end you can't discover - by design - which phone eventually is using this data.

[hoelzlw]

* giving 3rd parties a direct REST base access to 50 mio phones is a generic acceptance violation

Parties? Plural? We're only talking about the RKI and nobody else.

* giving 3rd parties the fastes possible opportunity to directly map an IP to an ID is a generic acceptance violation

How does the RKI get the ID?

* using a REST API with a public address gives companies with corporate firewalls the opportunity to log and check every byte that is transfered via https (we are still talking about medical data that is protected by the law)

HTTPS is encrypted.
With certificate pinning there's no way for a corporate firewall to do a MitM.

[egandro]

HTTPS is encrypted.
With certificate pinning there's no way for a corporate firewall to do a MitM.

Really :) Sophos has nice software for this... and it's used in corporation, insurances, government, banking, ...

https://www.avanet.com/kb/sophos-firewall-ca-zertifikat-fur-https-scanning-installieren/

[hoelzlw]

How about you finally explaining at least once, how your local mirror mycastle.tld gets the data from the official repository?

Using debian mirror tools we use now for > 20 years?

I can use a German mirror - a US mirror - a China mirror. The integrity of all files is guaranteed by a GPG signature.

Edit: to be 1000% crystal clear - https://mycaslte has NO tld! it's just my local mirror (Laptop, ...)

In the end you can't discover - by design - which phone eventually is using this data.

Wrong. The person running the mirror can easily discover who is connecting to them by simply logging IP addresses.

mycastle needs to be resolved to an IP address somehow.
Even if you set up DNS in your home network to resolve mycastle to your private mirror, your private mirror needs to fetch the data somehow.
The server, your private mirror fetches from then sees your IP.

The debian mirror tools you're talking about make no attempt to introduce privacy.
Everybody can add a mirror and nobody can control whether that person respects the connecting users' privacy.
These mirrors are distributed via a mirror list and the Debian people accept literally anybody, as long as they refresh their local repository every six hours.

[hoelzlw]

HTTPS is encrypted.
With certificate pinning there's no way for a corporate firewall to do a MitM.

Really :) Sophos has nice software for this... and it's used in corporation, insurances, government, banking, ...

https://www.avanet.com/kb/sophos-firewall-ca-zertifikat-fur-https-scanning-installieren/

https://de.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Edit: Rather Certificate Transparency
https://en.wikipedia.org/wiki/Certificate_Transparency

[egandro]

Wrong. The person running the mirror can easily discover who is connecting to them by simply logging IP addresses.

Well i guess you need to monitor a lot of servers in China?

[hoelzlw]

Well i guess you need to monitor a lot of servers in China?

You want to put the data to servers in China?
So, that the people running the servers in China get to see the IP addresses of the users?
You consider this to be more trustworthy than the RKI?
And you really think, the people in Germany would rather fetch the data from some server in some country operated by some stranger on the internet rather than the RKI?

[egandro]

You want to put the data to servers in China?

Dude :(

I just want to avoid - by design - a REST API of the government to 50 mio phones.

That needs to be prevented in any case. There is NO technical need to allow this for tracking.

If I can put a mirror - that is located beyond the possibilities of 3rd parties to access log files - this helps.

[simontb]

giving 3rd parties a direct REST base access to 50 mio phones is a generic acceptance violation

No, 50 mio phones have access to the REST server not vice versa.

giving 3rd parties the fastes possible opportunity to directly map an IP to an ID is a generic acceptance violation

The ID is not transferred to the server. Unless you're infected and report yourself positive in which case I don't see an issue as COVID-19 is a notifiable disease. In this case it's even better to have a central server, because with this you only report yourself infected to the public authorities that have access to this information anyway and not to any 3rd party.

using a REST API with a public address gives companies with corporate firewalls the opportunity to log and check every byte that is transfered via https (we are still talking about medical data that is protected by the law)

Yes, your employer can see that you use the app, but not whether you had contact with an infected person. The same applies to the any network admin (cafe, or even at home if you're not the admin, but e.g. your wife). If you report yourself infected in company network, then they may notice this, as the URL differs. But I hope in case you're suspecting being infected you're not going to work but stay home from where you report yourself infected ;)

[hoelzlw]

You want to put the data to servers in China?

Dude :(

I just want to avoid - by design - a REST API of the government to 50 mio phones.

Do you confuse REST with a persistent connection?

Just for your information: REST means the format of the content doesn't change and that the entire thing is stateless, thus you don't need information from the past in order to interpret the current content.

Simply downloading a file via curl as a cron job is compliant with REST.

Many people applying REST use a persistent connection with keepalive messages in order to prevent reoccuring TCP handshakes.

Since the entire purpose of the app is downloading a file once a day, this can easily be done via curl and cron (or the specific equivalents on the mobile device); calling it a REST API is then just a buzzword.

That needs to be prevented in any case. There is NO technical need to allow this for tracking.

If I can put a mirror - that is located beyond the possibilities of 3rd parties to access log files - this helps.

Maybe you should really wait, until further documentation is available.

[s-martin]

I just want to avoid - by design - a REST API of the government to 50 mio phones.

I don't know, if this is a subtle spelling mistake, but there is NO REST API FROM the agency TO the phones, but from the phones to the RKI servers.

That needs to be prevented in any case. There is NO technical need to allow this for tracking.

The use case is that the RKI wants the possibility to improve the algorithm parameters on the phones, so the phones would need to poll the parameters from time to time from a server.

If I can put a mirror - that is located beyond the possibilities of 3rd parties to access log files - this helps.

Yes, you could set up your own server, but that's not feasible for 50 mio end users to set up a server themselves.
And again why would you trust a stranger on the internet who sets up a server more than the RKI?

[atdotde]

• giving 3rd parties a direct REST base access to 50 mio phones is a generic acceptance violation

I have to bring you bad news: The RKI has already a REST server probably serving about that number of requests from different hosts. It's called www.rki.de and it answers on port 80.

• giving 3rd parties the fastes possible opportunity to directly map an IP to an ID is a generic acceptance violation

No. The ID is not communicated. All of the communication is "Hey RKI, I am 127.0.0.1, what's todays threshold for the distance?" - "Nice to meet you 127.0.01, It's 2,2m."

The ID is only communicated if you have a positive test. But if you have a positive test, you go on record anyway at your local Gesundheitsamt, as the disease is "meldepflichtig".

• using a REST API with a public address gives companies with corporate firewalls the opportunity to log and check every byte that is transfered via https (we are still talking about medical data that is protected by the law)

Again, the information is public. It is "it is 2,2m", as everybody learns who asks the RKI server. That is the "S" in REST.

[egandro]

Simply downloading a file via curl as a cron job is compliant with REST.

Why do you implicit install the possibility to directly upload stuff :)

That's never possibly by design using a passive server infrastructure with decentralized servers.

[egandro]

No. The ID is not communicated. All of the communication is "Hey RKI, I am 127.0.0.1, what's todays threshold for the distance?" - "Nice to meet you 127.0.01, It's 2,2m."

How do you know? https://rki.de/settings.json?id=1245678u76543 < very very easy.

"Oh sh*t - we accidentally pushed the publish button. Sorry about that debug version".

This happened so many many times. Why not just avoid this by design?

[s-martin]

So previously you were concerned about IPs being recorded and now you are suddenly saying someone passes IDs to a server?

I suggest to read the concept of DP-3T again.

No. The ID is not communicated. All of the communication is "Hey RKI, I am 127.0.0.1, what's todays threshold for the distance?" - "Nice to meet you 127.0.01, It's 2,2m."

How do you know? https://rki.de/settings.json?id=1245678u76543 < very very easy.

"Oh sh*t - we accidentally pushed the publish button. Sorry about that debug version".

That's why the code will be open source and can be reviewed here.

[niklas2810]

...and that's why the app will be open source so you can have a look at such requests.

[mohe2015]

@egandro

"Oh sh*t - we accidentally pushed the publish button. Sorry about that debug version".

This will be published to some app store which means you will be asked to install the update so you could also check if the code is fine. (If there will be reproducible builds you could probably even just build the code in the future and check if they match)

[egandro]

That's why the code will be open source and can be reviewed here.

While the publication isn't :) that's why we need a design protecting for accidents xD

[niklas2810]

While the publication isn't :) that's why we need a design protecting for accidents xD

Oh yes of course, because a company such as SAP has no CI/CD and they won't have a close look on the app as it is of very high importance... Sorry, but to my mind this is getting redicolous. I'm logging off from this thread and ask everyone else to do the same until we are dealing with facts and not speculations.

[egandro]

Sorry, but to my mind this is getting redicolous.

Yes :) my main question isn't answered :)

Why a REST API xDD it's still not covered by any answer.

I just gave you examples how a REST API can be used for 3rd parties for "their needs" in seconds.

Endusers might not accept this possibility!

A decentralized server infrastructure makes this not possible by design.

[hoelzlw]

using a REST API with a public address gives companies with corporate firewalls the opportunity to log and check every byte that is transfered via https (we are still talking about medical data that is protected by the law)

Yes, your employer can see that you use the app, but not whether you had contact with an infected person. The same applies to the any network admin (cafe, or even at home if you're not the admin, but e.g. your wife). If you report yourself infected in company network, then they may notice this, as the URL differs. But I hope in case you're suspecting being infected you're not going to work but stay home from where you report yourself infected ;)

I find these concerns hilarious.
People are concerned that their employer might man-in-the-middle their communication with the RKI server and intercept their COVID-19 test result.

Just a question: If you're tested positive and want to conceal this from your employer, what exactly do you say to them that you cannot come to work for the next, uhm, six weeks?
And even if you get a good excuse, don't you think they might get suspicions when all of a sudden all of your co-workers get a message, that they should get tested because they were in contact to someone positive?

[hoelzlw]

Sorry, but to my mind this is getting redicolous.

Yes :) my main question isn't answered :)

Why a REST API xDD it's still not covered by any answer.

Uhm, a webserver which delivers a static non-changing webpage, and closes the TCP-connection immediately afterwards is fully compliant with REST, i.e. it implements a REST API.

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

[egandro]

Just a question: If you're tested positive and want to conceal this from your employer, what exactly do you say to them that you cannot come to work for the next, uhm, six weeks?

Ask your local guy of the "Betriebsrat". Just the existence of such a plausibility will cause legal issues.

It can be a false alert (tracking an ID of a user that worked in the next building). It can be somebody else used his work phone . etc.

[egandro]

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

Yes?! But https://mycastle won't create any data on public servers :) just on my server

[hoelzlw]

Just a question: If you're tested positive and want to conceal this from your employer, what exactly do you say to them that you cannot come to work for the next, uhm, six weeks?

Ask your local guy of the "Betriebsrat". Just the existence of such a plausibility will cause issues.

It can be a false alert (tracking an ID of a user that worked in the next building). It can be somebody else used his work phone . etc.

FFS if you're tested positive, you need to tell your employer and all the people you live with, in addition to all the people you had contact with who don't use the app anyway; and you need to stay at home.

Which issues are we talking about here?

Concealing a positive test result will definitely cause way more significant issues!

[hoelzlw]

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

Yes?! But https://mycastle won't create any data on public servers :) just on my server

Uhm... How exactly is the latest settings- and infections-data transferred from the official servers to mycastle?

Doesn't mycastle somehow need an internet connection and, well, fetch it from somewhere?

[egandro]

FFS if you're tested positive, you need to tell your employer and all the people you live with in addition to all the people you had contact with who don't use the app, and you need to stay at home.

Yes! That's true.

But how is a positive tracking result related to that? It's no prove. It has no legal consequences (if you trash your device). It can be a false alert (tracking an ID of a person who is behind a wall). It can be a person who used your phone for a short time....

[s-martin]

Ask your local guy of the "Betriebsrat". Just the existence of such a plausibility will cause issues.

Please read the docs at https://github.com/DP-3T
There are no direct results "I'm infected" exchanged.

Second of all, why would your smartphone communicate via your company's network?

It can be a false alert (tracking an ID of a user that worked in the next building). It can be somebody else used his work phone . etc.

Now, you are mixing things up.

[egandro]

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

Yes?! But https://mycastle won't create any data on public servers :) just on my server

Uhm... How exactly is the latest settings- and infections-data transferred from the official servers to mycastle?

Doesn't mycastle somehow need an internet connection and, well, fetch it from somewhere?

No! It does not need any internet! Just a local phone <-> computer connection. It can be a 100% offline device that was mirrored via VPN?

[s-martin]

I

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

Yes?! But https://mycastle won't create any data on public servers :) just on my server

The mycastle IP is recorded on a public server, that was your biggest concern.

[egandro]

Second of all, why would your smartphone communicate via your company's network?

Because installing a corporate certificate on a phone might be the only way to do so in a corporate environment? You might need this for a corporate APN, too.

[hoelzlw]

The Debian servers / mirrors you fetch your updates from are REST servers, too.
Just sayin...

Yes?! But https://mycastle won't create any data on public servers :) just on my server

Uhm... How exactly is the latest settings- and infections-data transferred from the official servers to mycastle?

Doesn't mycastle somehow need an internet connection and, well, fetch it from somewhere?

No! It does not need any internet! Just a local phone <-> computer connection. It can be a 100% offline device that was mirrored via VPN?

But... ok, let's put this together.
So, you're setting up a VPN connection from your local device to some VPN provider.
Then, you kind of create a network sharing with mycastle, e.g. via a private wifi hotspot.
Then, mycastle fetches the data and then your phone fetches from mycastle.

Couldn't your phone just talk connect to the VPN and then talk to the official server directly?

[egandro]

The mycastle IP is recorded on a public server, that was your biggest concern.

No :) dude!!! WHAT?!

In the App i have the posibility to use https://rki.de ... OR add my own URL (still speaking about #13). So how will be https://mycastle ever be public???

[egandro]

Couldn't your phone just talk connect to the VPN and then talk to the official server directly?

NO! This would allow a malicious coded App to directly transfer information to 3rd party.

You finally understand the privacy issue behind #13.

With a decentralized server - this is NOT possible by design.

[hoelzlw]

The mycastle IP is recorded on a public server, that was your biggest concern.

No :) dude!!! WHAT?!

In the App i have the posibility to use https://rki.de ... OR add my own URL (still speaking about #13). So how will be https://mycastle ever be public???

Okay, step by step.
How does the necessary data from RKI get to the server behind your own URL?

[egandro]

How does the necessary data from RKI get to the server behind your own URL?

13 that is what we are talking here - is about

"Robert Koch-Institut (RKI)
Stellt epidemiologische Informationen und Handlungsempfehlungen für die Nutzer der App zur Verfügung (Content). Bestimmt die Parameter für die Messung der Kontakte (im Rahmen der technischen Möglichkeiten durch die API).
"

So this is also called sideloading. According to the docs this will be done by an API.

So WHY?! do we need this at all? Recompiling the APP would also be a posibility Why do we need an API here?

The API violates the integrity, it violates the anonymity and there are issues with data protection.

Please explain!

A decentralized approached will help here!

[hoelzlw]

Second of all, why would your smartphone communicate via your company's network?

Because installing a corporate certificate on a phone might be the only way to do so in a corporate environment? You might need this for a corporate APN, too.

A MitM is impossible if the correct certificate for https://data.rki.de is pinned to that domain.
Lookup certificate transparency (I erroneously mentioned public key pinning earlier; that was the predecessor).

Try online banking in your corporate network and you can see, whether your corporate firewall tries a MitM.

[s-martin]

Because you need the parameters of the algorithm to be consistent for all users.

If you change the parameters only by app update you get different parameters over the user base, because not every user updates the app right away.

[egandro]

Try online banking in your corporate network and you can see, whether your corporate firewall tries a MitM.

It doesnt try a MitM it will act as "client". The browsers on the client use Corporate CA signed certificates. The firewall will resign the content and send this to the browser.

We have this in every corporate / government / ... institute.

[hoelzlw]

Try online banking in your corporate network and you can see, whether your corporate firewall tries a MitM.

It doesnt try a MitM it will act as "client". The browsers on the client use Corporate CA signed certificates. The firewall will resign the content and send this to the browser.

We have this in every corporate / government / ... institute.

What exactly do you think is a man-in-the-middle-attack?

[egandro]

Because you need the parameters of the algorithm to be consistent for all users.

This still doesn't answer the question why we need a bidirectional API and no stupid (mirrorable) one way content delivery system - like the Debian mirrors.

[s-martin]

Is it bidirectional? I haven't seen any docs or code yet, which explain the technical details.

Let's postpone this discussion until more info is available.

[egandro]

Is it bidirectional? I haven't seen any docs or code yet, which explain the technical details.

The official Docs introduced the term "API".

This implies "calling a function with parameters and getting a result" :)

[hoelzlw]

So WHY?! do we need this at all? Recompiling the APP would also be a posibility Why do we need an API here?

Given 50,000,000 users, recompiling is not an option for like 49,500,000 of them (number pulled out of the body part im sitting on right now).

REST API means:

1. There is an URL that won't change on a daily basis.
2. There you'll find two files in a well documented format.
3. The format doesn't change on a daily basis.
4. The requests do not depend on any state acquired in former communications.

This is exactly what your Debian update mirrors do.
They implement a REST API.

[s-martin]

Yes, the device pulls info from a server, but no central instance accesses the device.

[egandro]

This is exactly what your Debian update mirrors do.
They implement a REST API.

I am Talking about the CONTENT - not how syncing works (that's not the issue at ALL! - this can use REST!)

Except -that having a local mirror for content/settings (still we are talking about #13)
will give me a priori possibilities to inspect the content and how to treat parameters to watch and monitor any POST/GET/... parameters :)

[Leseratte10]

You can monitor the requests by checking the source code, which will be available.

MITM does NOT work when the server is correctly set up using Key Pinning. It MIGHT work for some employers, but only because they control the end point (the computer / the browser) and just turn it off. An attacker can't do that.

[mohe2015]

This will be my last post here but I will try to explain their idea to you without actually knowing how it works:
every like 1 hour or so your device does the following request:
GET rki.de/parameters.json
...

HTTP/2 200 OK
{
"safe_distance_between_people": "2.1",
"safe_time_between_people": "5"
}

then the app will parse the json and use these parameters to do the magic. You can review the code in advance that parses and uses these parameters and there will not be any code that will be executed. If you really wanted to check the data you could just recompile the app with your own server edited into the code (as it will be public) and then just do a download at your server and check the data.

[hoelzlw]

This is exactly what your Debian update mirrors do.
They implement a REST API.

Except -that having a local mirror for content/settings (still we are talking about #13)
will give me a priori possibilities to inspect the content and how to treat parameters to watch and monitor any POST/GET/... parameters :)

Jesus.
You can see what the app does by directly inspecting the open source code.

Reproducible builds will further guarantee, that the code you see and compile is really the code that gets installed on your system.

Furthermore: If you really think, the server will send commands to your device, the code that is necessary for interpreting these commands will be visible in the source code.

I think, we will all agree with you, when we see the code and find calls to exec and a python interpreter.
But, so far, everything the app will do is
curl $URL -o $FILE
as a cron job.

[egandro]

GET rki.de/parameters.json

WHY not have a

GET mycastle/parameters.json.sig
GET mycastle/parameters.json
validate
[...]

[hoelzlw]

GET rki.de/parameters.json

WHY not have a

GET mycastle/parameters.json.sig
GET mycastle/parameters.json
_validate_
[...]

Because the validity of the server you're talking to is already properly established by TLS.

[mohe2015]

As a recommendation to the developers: You could also commit this parameters file to git (if not planned already) so it could be downloaded from there and reviewed if somebody wants to. This would also mean it would be signed and targeted mitm attacks would be impossible.

[egandro]

Because the validity of the server you're talking to is already properly established by TLS.

Yes :))))))

This is not the issue on data validity!

It's a:

1) Why should we trust a direct connection?
2) Why should we trust it won't be used for "bad things" in 4 weeks?
3) Why should we help 3rd parties / government to collect our IPs in a very very easy way?
4) It's a step for a centralized strucutre
5) Doing a "SELECT *" of all collected IDs is a 20min job for a skilled coder.

It's a generic acceptance issue.

This infrastructure will ever happen and never gain trust for 30-50 mio required users!

[hoelzlw]

As a recommendation to the developers: You could also commit this parameters file to git (if not planned already) so it could be downloaded from there and reviewed if somebody wants to. This would also mean it would be signed and targeted mitm attacks would be impossible.

And hand over all these precious IP addresses to Github and Microsoft?
Haven't you read #9?

:D

[hoelzlw]

Because the validity of the server you're talking to is already properly established by TLS.

Yes :))))))

This is not the issue on data validity!

It's a:

1. Why should we trust a direct connection?

2. Why should we trust it won't be used for "bad things" in 4 weeks?

3. Why should we help 3rd parties / government to collect our IPs in a very very easy way?

4. It's a step for a centralized strucutre

5. Doing a "SELECT *" of all collected IDs is a 20min job for a skilled coder.

It's a generic acceptance issue.

This infrastructure will ever happen and never gain trust for 30-50 mio required users!

Ah, now I understand your entire point.
Of course, number 3 of your list does not even remotely apply if we used a server from some unknown stranger on the internet instead.

By the way, why relying on the RKI for the settings at all?
Why not simply fetch the setting as well as the infected IDs from /dev/random?

[egandro]

Ah, now I understand your entire point.

That's the point of the bug description. Not "my" point.

Of course, number 3 of your list does not even remotely apply if we used a server from some unknown stranger on the internet instead.

Please don't do this. If A is evil, B might is also evil. The discussion TLS vs. GPG "what is more secure" should be done somewhere else.

By the way, why relying on the RKI for the settings at all?

settings.json is not the main concern - it this might be proximity settings and it might be ok - but still questionable from a security point of side loading.

The so called "content" is evil. If this is HTML/JS it's a 100% K.O. acceptance criteria for the public!

This would give 3rd party a 100% opportunity of running 3rd party code within a browser in your App. So this won't happen! With a decentralized approach this can be easily validated before uploading to the device!

[Leseratte10]

This would give 3rd party a 100% opportunity of running 3rd party code within a browser in your App. So this won't happen! With a decentralized approach this can be easily validated before uploading to the device!

Yeah, same when you open a web page in your browser. So? That doesn't mean it can do anything malicious. There's a reason browsers are sandboxed and only allow specific Javascript calls.

[hoelzlw]

This would give 3rd party a 100% opportunity of running 3rd party code within a browser in your App.

What. Are. You. Talking. About? O.o

URL="https://app-data.rki.de"
curl -O "$URL/settings.json"
curl -O "$URL/infected.json"

This, executed as a cron job once a day.

Where's the problem?

[egandro]

This would give 3rd party a 100% opportunity of running 3rd party code within a browser in your App.

What. Are. You. Talking. About? O.o

"Als RKI möchte ich die Inhalte der Applikation zentral verwalten, um Aktualisierungen von Texten, Links, Hotlines, etc. einmalig für alle Stellen in der App durchführen zu können.
Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert."

Dynamic "Content" of the RKI that might contain HTML with JS Code on your device. That runs in a browser - in your app.

[Leseratte10]

Yeah. Same as when you open your browser and go to rki.de. Or to google.com. What's the problem with that? It's just javascript. Not forced app updates.

[egandro]

Yeah. Same as when you open your browser and go to rki.de.

NO :(

In android - only god knows - what HTML webkit you are using. This highly depends on your Rom, the availability of updates. etc. It's not the most recent and patched Chrome/Firefox/Edge.

That's why it's so dangerous!

Please do not try to convince me of your point.

The CCC showed during the last 7 years how to hack any major console - by the embedded HTML Browser :)

[hoelzlw]

Please do not try to convince me of your point.

But that's only fair if you do the same to us.

[egandro]

But that's only fair, if you do the same to us.

Ok - so - I changed my mind! convince me.

[s-martin]

Please do not try to convince me of your point.

So you don't want an open discussion, but that everyone agrees to your standpoint?

[Leseratte10]

@egandro Yeah, that's what I'm saying. Opening the app, downloading an HTML from rki.de is the same process with the same issues as opening your browser and going to a web page.

Any security issue that could be exploited in the RKI app can also be exploited in the phone browser. So the security issue is already there and doesn't get more dangerous just because another App (RKI) uses the same browser engine.

Nearly every app has some kind of web access nowadays, aren't you using any of them for fear of browser exploits?
Any normal user is using the browser on his phone all the time. I don't know anyone who says "I regularly use my phone, but never its browser, that would be dangerous" ...

[egandro]

@egandro Yeah, that's what I'm saying. Opening the app, downloading an HTML from rki.de is the same process with the same issues as opening your browser and going to a web page.

I agree that downloading is equivalent. On Android - it's opened in Webkit - which might be very old, insecure and not patched for years.

Why do you want to allow code execution in such and environment and try to find acceptance for 50 mio users?

[hoelzlw]

@Leseratte10 Additionally, if the app is configured to only contact rki.de, then no third party can insert any code.
Since the user story only specifies that RKI wants to update hotline number, model parameters, etc. one can simply build a "more or less static" webpage that regularly pulls some data via .json-Files.

[Leseratte10]

@egandro You already have that acceptance. Because every smartphone user already uses his smartphone's browser. So clearly people are okay with that risk. Doing the same thing in another app doesn't increase the risk, at all.

[hoelzlw]

@egandro Do you have any confirmation that the app is just a webpage opened in the in-app browser?
Were did you get that knowledge from?

One can also build a normal app and fetch the files on a regular basis using curl.

[Leseratte10]

@hoelzlw that doesn't matter, if they want to download HTML and JS then that is the same.

[hoelzlw]

@Leseratte10 True, but if anything the app does is curl -O $URL to a publicly accessible URL which can be inspected in every browser, there's no need to be afraid from some code execution.

Since the code is open source, we can easily determine, what the app does with the downloaded data.

Why would it have to fetch HTML anyway?

[egandro]

@egandro Do you have any confirmation that the app is just a webpage opened in the in-app browser?
Were did you get that knowledge from?

From the document. It clearly quotes "dynamic content" not "Open a Website".

What else "dynamic content" do you know? mp3 files playing sound?

[hoelzlw]

@egandro How about this: A static skeleton with a field for a phone number.
The app fetches a json from the server, parses it and fills the field for the phone number with the number it just downloaded.
That's dynamic content.

It does the same with the necessary settings for the mathematical model.
Download a json, parse it, read out the values and populate the algorithm with the newly obtained numbers.
That's dynamic content.

How do you interpret the term dynamic content?

[egandro]

@egandro You already have that acceptance. Because every smartphone user already uses his smartphone's browser. So clearly people are okay with that risk. Doing the same thing in another app doesn't increase the risk, at all.

There is a difference. On Android you can open a Website with Chrome/Firefox/Edge... that is done with a up-to-date browser.

If done with webkit it can be an ancient component depending on your ROM and the patches that are available. This is a major security issue :( We do side loading here! We can't trust the code they send us, because we can't audit it ahead.

[egandro]

How do you interpret the term dynamic content?

Fancy texts and stuff with images, shadow buttons, comics to allow to good citizens to educate themselves!

Not nerd json :)

[tkowark]

Thank you all for the lively discussion. Just a gentle reminder to wait for the actual source code and more detailed technical documentation before jumping to conclusions which content will be loaded in which ways.

[hoelzlw]

We do side loading here! We can't trust the code they send us, because we can't audit it ahead.

Of course you could audit it ahead if the jsons are available via a publicly accessible URL. Just point your browser to that URL and inspect its contents.
Then come here to GitHub and inspect the code that handles the downloaded json.
If the code does nothing but parsing it and then reading the data in order to populate the algorithm, then where's the problem?

Right now your entire argument is: If they implement it like that, they could do this and that.
Yes.
But so far you don't have access to any implementation, so everything you do here is just speculation.

Example: The .deb-files you download from the Debian mirrors contain bash code. The people at Debian may put malicious code in their packages.
But: This is not a problem for you, simply because the people at Debian don't do this.

Now, imagine the following: The app simply downloads the jsons, parses them and reads the data.
Yes, the app could abuse some things.
But just imagine it doesn't.
This would completely remedy all your concerns regarding the REST API.
Wouldn't that satisfy you?

Remember: It's open source. You can check yourself whether something strange is going on.

[egandro]

We do side loading here! We can't trust the code they send us, because we can't audit it ahead.

Of course you could audit it ahead if the jsons are available via a publicly accessible URL. Just point your browser to that URL and inspect its contents.

Really :)

"If IP_OF_DEVICE_AND_ID == Bad_Citizen" { send_bad_code(); }

Can you avoid this ahead?

With a decentralized server - yes - by design! You can validate any content of the server!

With the REST approach there is zero zero zero acceptance for the App - and he or she tells all his or her friends... The server can send you anything that is not opensource.

[hoelzlw]

But you have the code for the app!
You can check what the app does with the returned json.
If it's only parsing and reading, you only have to check the parser for possible backdoors.
You can see exactly how each byte returned from the server is handled and whether it could cause a code execution or not.

Finally: If you don't trust them that much, don't use the app.

[hoelzlw]

With the REST approach there is zero zero zero acceptance for the App

Why do people in the Debian world accept it for their update mechanism then?
All these servers implement a REST API.
REST is way more than just sending JS to the browser.

[egandro]

But you have the code for the app!
You can check what the app does with the returned json.

Yeah! If they add proxy support.

If not - you have to trust in your god.

Finally: If you don't trust them that much, don't use the app.

A decentralized server approach will gain so much more trust. If a REST server with direct access is used, it won't get the required acceptance of the public.

[egandro]

Why do people in the Debian world accept it for their update mechanism then?
All these servers implement a REST API.
REST is way more than just sending JS to the browser.

We are not talking about debian REST API for the update syncing of the servers! This is 10000% find ok and super cool! Nobody ever talked about using the Sync protocol of Debian's server for the Corona App!

I am talking about Debian's way of decentralized package management.

The App's settings.json - is a package
The App's "RKI Content" - is a package

Every package is signed.

Everybody can setup their own mirrors. The App will do - in the end the SAME https call as with the REST api :) + a sig check.

However - by this architecture - it can be your own content mirror or the RKI mirror.

I am NOT (!) speaking about adopting the Debian Sync REST Server for the - no idea how this even came up! That's crazy / stupid and not intended!

It's the content what we want to mirror!

[Leseratte10]

Looking at debian, a parameter JSON wouldn't be packaged and signed. It would be downloaded over HTTPS from a web server as well. You don't package JSON configs.

[Leseratte10]

And you don't need proxy support. Just read the source of the App, then you know if it could do something malicious with the payload. You don't need to know the payload.

[egandro]

Looking at debian, a parameter JSON wouldn't be packaged and signed. It would be downloaded over HTTPS from a web server as well. You don't package JSON configs.

We don't know the cardinality of the settings - can be one file - can be two - can be twenty. That's why I used the term package, since it works with 1 or x files.

[hoelzlw]

A decentralized server approach will gain so much more trust.

If the media has to explain that the data stems from some servers from arbitrary internet strangers who possibly host their servers in China, this won't get any trust.

If a REST server with direct access is used, it won't get the required acceptance of the public.

You keep assuming that they will implement a server which pushes code to your device and that the app will be able to execute that but you simply cannot know this.
If they do that, it will be visible in the code and there will be a great debate.
If they don't do that, it fulfills all your requirements.
The existence of a REST API doesn't mean it's going to be abused in the worst possible way.

We are not talking about debian REST API for the update syncing of the servers!
...

There seems to be a confusion about what REST actually is.

All Debian mirrors implement a REST API.
REST means, that access to the packages follows a well known format that doesn't change over time and that everything is stateless, i.e. the communication doesn't depend on requests from the past.
The moment you have this, and a static webpage already has this, your server implements a REST API.

In your decentralized approach every single mirror would have a REST API.

[Leseratte10]

Yeah. But it wouldn't be downloaded from the debian mirror. Config JSONs for applications are downloaded - who would have guessed - by the application from the developer's web server, if needed. Not from the debian mirrors.

[egandro]

Yeah. But it wouldn't be downloaded from the debian mirror.

GET https://rki.de/settings.json ...

replace with

GET https://mycalste/settings.json.sig
GET https://mycastle/settings.json ...

Debian mirror SOFTWARE (not actually Debian infrastructure!!!) is used to allow

rki.de -> foo.bar -> mycastle

mirroring.

Got it?

[hoelzlw]

What's the problem with
GET https://rki.de/settings.json
and code that is non-vulnerable to any payload?

[egandro]

What's the problem with
GET https://rki.de/settings.json
and code that is non-vulnerable to any payload?

The acceptance :)

https://github.com/corona-warn-app/cwa-documentation/issues/13#issuecomment-629234787

Edit:

Just to be clear!

I coundn't agree more with you with any project for the industry :) I would put there a hardcoded URL.

This application is all about acceptance.

[Leseratte10]

Everyone who is tech-savvy enough and willing to operate their own mirror can also just recompile the App with their own URL inserted, no?

it will generate enough trust among normal users. Same as users trust their web browser rendering the web site they access.

[egandro]

Everyone who is tech-savvy enough and willing to operate their own mirror can also just recompile the App with their own URL inserted, no?

It's not about people who can recompile apps. It's about a generic trust issue you are creating here.

Just stick with me for a while.

Lets assume SAP & Telekom are creating a "Trading platform". Do you think the will use the Alibaba REST API without any level 7 firewall?

Of course they want to inspect every single character that enters or leaves the companies database before sending it to a not so trustworthy server.

So why do you assume people should comply and trust the German Government - without - having such a possibility?

Super smart people form the CCC and GI will talk about this - if it's not fixed...

[Leseratte10]

They don't have to trust the German government. They can take the source code and change it however they want, including adding a mirror server.

There is no trading platform where you need a level-7-firewall.

[hoelzlw]

Everyone who is tech-savvy enough and willing to operate their own mirror can also just recompile the App with their own URL inserted, no?

Not, if changing the URL breaks the signature.
Apple and Google will only allow one official app per country.
That's why reproducible build are so important.
This way, you can compile on your own and reuse the signature, as the hashes will be identical.

[hoelzlw]

Super smart people form the CCC and GI will talk about this - if it's not fixed...

Super smart people will audit the app and point out whether there are vulnerabilities or not.

Quick question: Will you accept the centralized REST server from RKI if the super smart people from CCC and GI say the app is okay and that there's no necessity for mirrors and no danger from the REST API?

[Leseratte10]

Then change the DNS to route to your own mirror. Or use a proxy in your smartphone that redirects to your own mirror. When the files are hosted with a signature, HTTPS is not needed and that works just fine.

[karottenbaum]

There is a difference. On Android you can open a Website with Chrome/Firefox/Edge... that is done with a up-to-date browser.
If done with webkit it can be an ancient component depending on your ROM and the patches that are available.

Hi @egandro, just to put this into perspective:
With Android >=5.0 (which has a 97.5% market share in Germany) WebView is based on Chromium and automatically updates via the Play Store. This means that 97.5% of Android users are not even affected by this in the first place and frankly, if your phone is still running Android <5, an old WebView is the least of your problems.

[egandro]

Quick question: Will you accept the centralized REST server from RKI

Acceptance is no "me" problem. It's a "will any doubt make 25mio so afraid that they don't install the app"?

Yes! The direct device access is a no go!

[Leseratte10]

Stop claiming that this is a direct device access. The server has no access to the device.
It's exactly identical to using a web browser, and millions of people do that without issues.

[hoelzlw]

@egandro But then we come back to the problem of:
How do we distribute the mirror list?
How do we decide who gets on that list?
How do we enforce, that the people running these mirrors don't abuse the users' data?

This is a much bigger acceptance problem.

Edit: And you still evade the question. Will you accept such an audited solution or not?

[egandro]

With Android >=5.0 (which has a 97.5% market share in Germany) WebView is based on Chromium and

So 100-97,5 = 2,5 % -> out of the 50 mio users (assume 50% android) you need ... that are 1.250.000 / 2 = 625.000 can be easily hacked by an malicious javascript?

Cool acceptance :)

[Leseratte10]

No. There are 625,000 who probably already HAVE a hacked phone that's under control of an attacker since all the exploits have already been abused.
Also, I doubt the app will even run on something way older than 5.0.

[egandro]

How do we distribute the mirror list?

We don't ... everybody who want's a mirror just tells the world "I have a mirror".
Mirrors know when they were replicated.

I really have no issue to mirror from rki.de - that's 1000% ok.

I don't have to reveal my phones IP.

[egandro]

No. There are 625,000 who probably already HAVE a hacked phone that's under control of an attacker since all the exploits have already been abused.

Sure! but 5 million will tell their friends, that they read something about the App might be hacked...

[Leseratte10]

No. The app doesn't get hacked. Their phone gets hacked because it has a 7-year-old OS, which would happen with any app.

PLEASE, try to understand that if you use Android 4, your phone can get hacked through ANY app, from ANY server. Even with mirrors. This isn't something that the RKI needs to fix.

The only way you could prevent that would be make the App require Android 8+. Is THAT a better solution? No.

[hoelzlw]

We don't ... everybody who want's a mirror just tells the world "I have a mirror".
Mirrors know when they were replicated.

WHAT?

Please point me to the technical documentation explaining this broadcast mechanism and how devices access this distributed system.
Especially since you pointed at Debian and this is not what Debian does.

[egandro]

No. The app doesn't get hacked. Their phone gets hacked because it has a 7-year-old OS, which would happen with any app.

I agreee 1000000%.

Running Android 5 in 2020 is a big big issue. However - knowing this. Won't help you with the acceptance on OLD phones :)

[egandro]

Please point me to the technical documentation explaining this broadcast mechanism and how devices access this distributed system.

In debian you can put in your mirror list.

https://mycastle.

In the App - instead of the default URL https://rki.de I change this with https://mycalste

[Leseratte10]

The people who use Android 4 in 2020 don't give a fuck about security. And they are not in the IT industry. Otherwise they wouldn't be using that old versions. So they also don't give a fuck about implementation details of this app.

[Leseratte10]

And the question isn't HOW you get the app to use mirrors. The question is, what RELIABLE method do you use to let people know which mirrors exist.

[egandro]

The people who use Android 4 in 2020 don't give a fuck about security. And they are not in the IT industry. Otherwise they wouldn't be using that old versions. So they also don't give a fuck about implementation details of this app.

So if they just notice somewhere "if you have an old phone, it's bad to install the app" for example by their 12 year old boy - they tell this to their friends :)

[Leseratte10]

If you have an old phone, it is bad to install ANY app. This has ABSOLUTELY NOTHING to do with this app.

[egandro]

And the question isn't HOW you get the app to use mirrors. The question is, what RELIABLE method do you use to let people know which mirrors exist.

FritzBox. "Install your RKI App mirror"
Microsoft Store "Install your RKI App mirror"
MacOS "Install your RKI App mirror"

and then just put in http://fritzbox ... windowspc, ... and so on

very very very simple and stupid

[Leseratte10]

So what do you gain if YOUR fritzbox or YOUR MacOS has a mirror? The RKI would still get your IP - from your fritzbox or MacOS.

[egandro]

If you have an old phone, it is bad to install ANY app. This has ABSOLUTELY NOTHING to do with this app.

I agree :) But that's not the scope of this project - while this issue is about a trust issue.

[egandro]

So what do you gain if YOUR fritzbox or YOUR MacOS has a mirror? The RKI would still get your IP - from your fritzbox or MacOS.

omg :)

_NOT_ of the phone :)

How on god's flat earth would they know I synced against THIS fritzbox or THAT mac or the server at work? for the settings?

[hoelzlw]

And the question isn't HOW you get the app to use mirrors. The question is, what RELIABLE method do you use to let people know which mirrors exist.

FritzBox. "Install your RKI App mirror"
Microsoft Store "Install your RKI App mirror"
MacOS "Install your RKI App mirror"

and then just put in http://fritzbox ... windowspc, ... and so on

very very very simple and stupid

Yes, this solves your imaginary problem with the scary REST API, but does not address your imaginary problem with the official server collecting and abusing IP addresses from the fetching mirrors.

[Leseratte10]

They would get the public IP of your fritzbox. which is linked to your ISP connection. They can do even better tracking with THAT IP than they could with the cell phone connection IP.

[IXArcanumXI]

The API will be pushed through PlayServices to Android 6.0 and newer. No need to talk about Android <6.

[jeffreygroneberg]

Yeah. Of course. If there is one thing that “casual” people really bother about it is possible tracking and exposure of data... sarcasm You should check stats of decreased user bases after leaks (PSN, WhatsApp, TikTok, Facebook, ...). Guess what!? No one cares.

You make assumptions on your own “feelings” and project this on the whole user base.

Let’s just sum things up:

• Someone (SAP and Telekom) wants to develop an app using common and well known paradigms to help the people
• Someone else points out (you @egandro ) that we live in a 1984 world and the central instance having not one single access to the consumers will allow admins, hackers, whatever to expose every single mobile device and its user
• Many people tell you that this is one of fastest feasible implementations with an (academic) compromise in regards to security
• Each line of the source code will be open sources so you can find malicious code lines at any time

I still don’t get why you rather have no app than an app that will try to be as transparent as possible and help the people.

[egandro]

Yes, this solves your imaginary problem with the scary REST API, but does not address your imaginary problem with the official server collecting and abusing IP addresses from the fetching mirrors.

I never had a problem with this...

As we talked about 5 hours ago - I can create MY Mirror in China - and a sub sub mirror back in Germany.

That's very easy to solve.

[Leseratte10]

You can also route your phone traffic through Tor or other VPNs or proxies. Same result (no IP tracking), way easier.

[egandro]

I still don’t get why you rather have no app than an app that will try to be as transparent as possible and help the people.

Don't put words in my mouth!

I want a REST API not "violating integrity, anonymity and data protection" - that's what #13 is covering.

[jeffreygroneberg]

You can also route your phone traffic through Tor or other proxies. Same result (no IP tracking), way easier.

Exactly. If he is paranoid and needs this. He can do. Just fair.

[egandro]

You can also route your phone traffic through Tor or other proxies. Same result (no IP tracking), way easier.

Exactly. If he is paranoid and needs this. He can do. Just fair.

That's won't help. We have no way of checking the content that is loaded to the phone before it's processed by the app.

Why should we trust this?

[Leseratte10]

Nobody is putting words in your mouth. A simple JSON downloaded with parameters, that can be accessed through proxies, Tor or a VPN doesn't violate integrity (can be signed), doesn't violate anonymity (since you can hide your IP using proxies) and doesn't violate data protection (since you can hide your IP, and there is no data other than that).

[egandro]

Nobody is putting words in your mouth. A simple JSON downloaded with parameters, that can be accessed through proxies,

Sure! Why not allow this on my own decentralized server?

[hoelzlw]

I want a REST API not "violating integrity, anonymity and data protection" - that's what #13 is covering.

What if I told you that it is indeed possible to have a REST API without violating integrity, anonymity and data protection?

You just cannot judge the app regarding these things without the actual source code.
Just because it's theoretically possible doesn't mean it's done.

[Leseratte10]

@egandro Yes, you can. Just download it onto your computer by accessing the public URL. Your phone's request, coming from the same IP, will get the same data.

[jeffreygroneberg]

I still don’t get why you rather have no app than an app that will try to be as transparent as possible and help the people.

Don't put words in my mouth!

I want a REST API not "violating integrity, anonymity and data protection" - that's what #13 is covering.

Then we should ask Vitalik if he allows SAP/Telekom to put code in the Ethereum network for free offering a decentralized REST API and data storage.

Many people told you here in this discussion that is almost impossible to map a device with an IP to a name.

[egandro]

Many people told you here in this discussion that is almost impossible to map a device to a name.

Really :))))

Ask your local police how much time and eford it requires to map a phone IP to a user :)

This can be done in minutes - if 3rd party wants this. SO why give them the IPs?

[hoelzlw]

Many people told you here in this discussion that is almost impossible to map a device to a name.

Yes, and then @egandro changed the subject to how the RKI is pushing malicious code to people's devices and how this can be solved with a mirror. 🙄

[hoelzlw]

Ask your local police how much time and eford it requires to map a phone IP to a user :)

As someone who has experience with this and is qualified to answer your question: It takes a court decision to do that. In case of imminent danger the decision is delivered afterwards.
With the decision it's indeed a matter of tens of minutes.

Edit: If the IP-person-record hasn't been deleted by the ISP in the meantime.

This can be done in minutes - if 3rd party wants this.

Only if we agree, that this third party is a German court, which is a strange name for a court.

[jeffreygroneberg]

The backend might also just generate common json with a validity date and push this to CDNs and the client then can randomly take one of them in an internal list. Or there might be Redis shards in front of the backend. So many possibilities. Let’s wait for the architecture blueprint and stop talking about hypothetical things that MIGHT happen. In the end IMHO should the speed of development and the support of the people stand above possible academic security holes. Developing under time constraints is always a compromise. Always.

[egandro]

Many people told you here in this discussion that is almost impossible to map a device with an IP to a name.

There is the use case.

• You and your family go to vacation.
• Your cell phone is updating every 2 hours the settings.json ... so we know from the IP not your exact position - but we can estimate your movement
• You arrive at 2020-07-15 at your destination and leave it at 2020-08-01
• RKI learns that an infection was present at your vacation destination at 2020-07-29

So with the IP they can easily track you back :) It's not a 100% solution - but the IMEIs in a cell at 2020-07-29 an be easily recovered :)

This is NOT part of the deal of the Corona App - but "in case of an emergency" it can be easily done.

[egandro]

The backend might also just generate common json with a validity to CDNs and the client can randomly take one of an internal list.

CDNs can't be used :( you will need some signature.

That's what makes "stealing" the Debian mirror system so smart. They solved this 20 years ago.

[hoelzlw]

Many people told you here in this discussion that is almost impossible to map a device with an IP to a name.

There is the use case.

* You and your family go to vacation.

* Your cell phone is updating every 2 hours the settings.json ... so we know from the IP not your exact position - but we can estimate your movement

* You arrive at 2020-07-15 at your destination and leave it at 2020-08-01

* RKI learns that an infection was present at your vacation destination at 2020-07-29

So with the IP they can easily track you back :) It's not a 100% solution - but the IMEIs in a cell at 2020-07-29 an be easily recovered :)

This is NOT part of the deal of the Corona App - but "in case of an emergency" it can be easily done.

How does RKI track you back with the IP alone and without a court decision for getting your address?

[egandro]

How does RKI track you back with the IP alone and without a court decision for getting your address?

They don't! They have no legal power on that.

3rd party / government institutions do.

[jeffreygroneberg]

The backend might also just generate common json with a validity to CDNs and the client can randomly take one of an internal list.

CDNs can't be used :( you will need some signature.

That's what makes "stealing" the Debian mirror system so smart. They solved this 20 years ago.

They can just generate JWTs and put the content in the body. Signature is based on the private key of the RKI instance pushing the data to CDN. Client downloads it, check signature with public key. Done. Must not be a JWT? You can sign ANYTHING and put it as a binary somewhere.

[egandro]

They can just generate JWTs and put the content in the body. Signature is based on the private key of the RKI instance pushing the data to CDN. Client downloads it, check signature with public key. Done.

Yes! That's fancy and that makes money to Telekom Stock owners!

Edit: and still doesn't hide my phone's IP :)

[hoelzlw]

3rd party / government institutions do.

Which 3rd party?

[jeffreygroneberg]

They can just generate JWTs and put the content in the body. Signature is based on the private key of the RKI instance pushing the data to CDN. Client downloads it, check signature with public key. Done.

Yes! That's fancy and that makes money to Telekom Stock owners!

Oh boy. After this statement... :(

[egandro]

Oh boy. After this statement... :(

1000 Active Servers vs. 1000 passive Webstore Servers?

and still no Explaination why we need them? :)

[hoelzlw]

>

So with the IP they can easily track you back

How does RKI track you back

They don't! They have no legal power on that.

This is kind of amusing and frustrating at the same time...

[hoelzlw]

Oh boy. After this statement... :(

1000 Active Servers vs. 1000 passive Webstore Servers?

and still no Explaination why we need them? :)

Probably because it's easier to buy more and use spare ones later than buying to few and make the start of the app fail.

Anybody here who remembers the launch of Diablo 3?

[egandro]

Which 3rd party?

Use this link.
https://www.gdp.de/gdp/gdpnrw.nsf/id/953562AE7EFE0D9BC1257CDE00452C56/$file/Polizeigesetze_Laender.pdf?open

This is a mess in Germany who and where and what and how.

[hoelzlw]

Which 3rd party?

Use this link.
https://www.gdp.de/gdp/gdpnrw.nsf/id/953562AE7EFE0D9BC1257CDE00452C56/$file/Polizeigesetze_Laender.pdf?open

This is a mess in Germany who and where and what and how.

Yeah, that's a list of the police laws for every state.
And?
What now?
Police cannot do anything without a court decision, why do you refuse to understand that?

[jeffreygroneberg]

Oh boy. After this statement... :(

1000 Active Servers vs. 1000 passive Webstore Servers?
and still no Explaination why we need them? :)

Probably because it's easier to buy more and use spare ones later than buying to few and make the start of the app fail.

Anybody here who remembers the launch of Diablo 3?

:) Me. Was an awesome night....sleeping.

[egandro]

Police cannot do anything without a court decision, why do you refuse to understand that?

Did you read "in case of an emergency"?

[Leseratte10]

Even in an emergency they need a judge to sign an emergency order. And corona tracking is no emergency.

[hoelzlw]

Police cannot do anything without a court decision, why do you refuse to understand that?

Did you read "in case of an emergency"?

Yes.
This is called imminent danger (dt. Gefahr im Verzug).
In this case police / prosecution must deliver the court decision afterwards.

There is always a court deciding.
No police officer and no prosecutor has the power to simply get personal information from an IP address.
You're watching too many TV shows.

[egandro]

Even in an emergency they need a judge to sign an emergency order. And corona tracking is no emergency.

Sure! 10000% agreed.

But why should we collect the IPs for them "just" by downloading a settings.json?

[Leseratte10]

We don't need to, that's correct. But it is by design that a server has to know the address of a client that is requesting stuff. Whether that will be logged and stored is different.

[hoelzlw]

Even in an emergency they need a judge to sign an emergency order. And corona tracking is no emergency.

Sure! 10000% agreed.

But why should we collect the IPs for them "just" by downloading a settings.json?

Are you aware that the US government can force Apple and Google via a national security letter to reveal the Apple- and Play Store-Ids of every single account that downloaded the app?

Doesn't this make you, kind of, uncomfortable?

[egandro]

In this case police / prosecution must deliver the court decision afterwards.

You're watching too many TV shows.

Just go and watch a couple of CCC videos on that :)))) NO IPs - no Logs - no court xD

[Leseratte10]

Yeah. And the easiest way to do that is just implement the server in a way that it doesn't log. Not by spinning up a huge mirror system with implementation and backends.

[hoelzlw]

@egandro Are you aware that the people running these mirrors are in the position to collect IP addresses "for them"?

[egandro]

@egandro Are you aware that the people running these mirrors are in the position to collect IP addresses "for them"?

Yes!

I have no problem mirroring rki.de from an IP the RKI can happily collect!

I have also no problem of gaining access on my local mirror of my local phone!

Hint: I know the IP of my phone even before calling my local server.

[simontb]

Many people told you here in this discussion that is almost impossible to map a device with an IP to a name.

There is the use case.

• You and your family go to vacation.
• Your cell phone is updating every 2 hours the settings.json ... so we know from the IP not your exact position - but we can estimate your movement
• You arrive at 2020-07-15 at your destination and leave it at 2020-08-01
• RKI learns that an infection was present at your vacation destination at 2020-07-29

So with the IP they can easily track you back :) It's not a 100% solution - but the IMEIs in a cell at 2020-07-29 an be easily recovered :)

This is NOT part of the deal of the Corona App - but "in case of an emergency" it can be easily done.

You just keep making up new points once you run out of arguments. For this new scenario of "why the app will be horribly bad if not everything is done exactly like @egandro wants it" you wouldn't even need an app. You can find out from the cellphone providers which citizens have logged in their mobile devices in superspreading city XY. But still you'd need a court order.

[jeffreygroneberg]

Guys. I liked the discussions here a lot. But it has shifted from reality to a black mirror show.

Looking forward to the architecture blueprint and keeping my fingers crossed this app will help the people as soon as possible! For the sake of credibility and for further open source projects I would suggest to close this issue or put it on hold and reopen later!

[egandro]

Yeah. And the easiest way to do that is just implement the server in a way that it doesn't log. Not by spinning up a huge mirror system with implementation and backends.

Won't work. That doesn't increase the trust issue.

https://github.com/corona-warn-app/cwa-documentation/issues/13#issuecomment-629234787

[egandro]

But still you'd need a court order.

I agreed 3x times on that.

But why do you want to happily sell 50 mio users in the trap that they can be easily covered by such a court order?

This is a trust issue.

[hoelzlw]

Yeah. And the easiest way to do that is just implement the server in a way that it doesn't log. Not by spinning up a huge mirror system with implementation and backends.

Won't work. That doesn't increase the trust issue.

#13 (comment)

The comment you linked does in no way disproof what @Leseratte10 wrote.

Everything you say is completely based on speculation about how the app could theoretically do this and that.

The solution is easy: Let CCC and GI run the server. They will run it in a way such that it doesn't record IP addresses -- hopefully.
If this doesn't satisfy @egandro, then there's no way at all to write such an app.

[simontb]

But why do you want to happily sell 50 mio users in the trap that they can be easily covered by such a court order?

If you read my whole comment and not just the part you cited, you'd know that this has nothing to do with the app. This could be done for every cellphone user (not just smartphones).

[egandro]

If you read my whole comment and not just the part you cited, you'd know that this has nothing to do with the app. This could be done for every cellphone user (not just smartphones).

I agree 100000000% with that. IP -> Adresse can be mapped with a court order! Sure. I agree with this. I 10000000% resonate with you!

Question: When we DON'T collect IPs - for no good reasons - can good citizens be covered under such court orders?

[egandro]

If this doesn't satisfy @egandro, then there's no way at all to write such an app.

I think that was the 10th+ personal attack. I didn't acknowledge that on purpose until now.

Can you please kindfully don't do personal attacks? I don't know you.

I really really think you are a smart and decent passionate lovely person!

[simontb]

If you read my whole comment and not just the part you cited, you'd know that this has nothing to do with the app. This could be done for every cellphone user (not just smartphones).

I agree 100000000% with that. IP -> Adresse can be mapped with a court order! Sure. I agree with this. I 10000000% resonate with you!

Question: When we DON'T collect IPs - for no good reasons - can good citizens be covered under such court orders?

Okay, then there was a misunderstanding. What I wanted to say: You don't need a server that logs IPs (which was promised it doesn't, but that's not the point here, as we want to assume that this promise can't be trusted) or an app at all. One (let's say the RKI) can go to court and ask a cellphone provider (let's say Telekom, but realistically all German providers) for the records of individuals who have been in superspreading city XY.

[Leseratte10]

So.
Let's assume the App would support mirrors.
Then you can set up one mirror in another country, make that pull the data, then make your phone pull data from your mirror. That way, the server only sees the IP of your mirror.

Did I understand that correctly so far @egandro , that that is what you want to do?

Now assume the app doesn't support mirrors. You set up a proxy server in another country (VPN, socks proxy, Tor like, whatever you want). Then you make your phone pull data through that proxy. That way, the actual server also only sees the IP of your mirror.

So why do you need mirror support in the app again?

[egandro]

What I wanted to say: You don't need a server that logs IPs (which was promised it doesn't, but that's not the point here, as we want to assume that this promise can't be trusted) or an app at all.

That is what SAP told us. Again - why should 50 mio+ Germany App user trust what the government claims about this?

I just posted a link covering all German police laws. If only one dude get's crazy "hey we need this for xyz reasons" - it's over!

Do you really really really think 50+ mio users will follow the story "No we don't log?" why did we have then the discussion about a decentralized storage for weeks ahead?

This indicates a major lack of trust - by experts!

[Leseratte10]

why did we have then the discussion about a decentralized storage for weeks ahead?

To determine where the really important data - the contact information - is stored. Not to determine potential, far-fetched "what if" scenarios about IPs.

[egandro]

Let's assume the App would support mirrors.

I wrote this 5 times :)

There is NO problem running a local mirror from rki.de directly from my DSL / internet café / workplace. RKI can collect whatever IP I use for mirroring.

In the end I have an offline mirror.

In the end this is just a wget -r https://rki.de/corona-stuff ...

When I use my phone to sync - RKI doesn't know anything about the phones using the server!
It could be 0 phones that sync from my (offline) mirror or 20000 phones.

[Leseratte10]

That would be the same in the situation I described.

If you run a server, and use that as a proxy. Then the RKI also doesn't see phone IPs (just the IP from the server), and also doesn't know how many phones use the mirror.
Just because you write something 5 times doesn't make it true.

[egandro]

the contact information

Which is just a meaningless ID and a list of IDs you met :)

[egandro]

If you run a server, and use that as a proxy.

I want to > avoid < by design a REST API because of trust issues.

That was covered before here: https://github.com/corona-warn-app/cwa-documentation/issues/13#issuecomment-629234787

[Leseratte10]

Oh, is that so? Then why do you want all that distributed stuff?
So lets go back to a closed-source app with a central server if they are just meaningless IDs?

[egandro]

Oh, is that so? Then why do you want all that distributed stuff?

Because allowing any DIRECT API calls is a trust issue.

We don't know what "somebody" decides in 4 weeks - and we have connected 50 mio phones to a wire by the government!

[Leseratte10]

I don't think you understand what a REST API is.

The server can be a normal HTTPS download of a file. No "API" needed. You can still proxy or tunnel it through your own server.

[egandro]

The server can be a normal HTTPS download of a file. No "API" needed. You can still proxy or tunnel it through your own server.

API is the word that is used in the SAP/Telekom document :)

[Leseratte10]

You have the source code of the App.

It doesn't matter if the server is malicious. From looking at the client source, you know exactly what the server is capable of doing. Even when it gets hacked or the government decides to become malicios, the server still can't do things the client doesn't support.

[egandro]

Even when it gets hacked or the government decides to become malicios, the server still can't do things the client doesn't support.

As I told you before. If SAP + Telekom were making an e-commerce project and using the Alibaba REST API - they wouldn't trust it without installing a Layer 7 firewall.

Every character needs to be evaluated before it's used in their database.

Why should we trust the government without giving us the possibility to do so with their API?

The simplest L7 Firewall is using decentralized servers without any active REST API - just files.

You can open them offline ... read + study ... send them to your device.

[Leseratte10]

Stop talking about e-commerce and Alibaba. This has absolutely no relevance here.
There is no "API".
There is a static service that has a parameter file like "time_contact=5m;" or other settings. There is no need for any firewall or any database. The RKI decides on the time, and it is sent to the phones.
Then in the app source code you can see that the only valid parameter is "time_contact" and that it takes a time in minutes.

No need for firewalls anywhere. No need to study the server code. If it sends anything malicious, other than "time_contact=X", the client will drop the reply, and you will be able to confirm that in the source.

[hoelzlw]

If this doesn't satisfy @egandro, then there's no way at all to write such an app.

I think that was the 10th+ personal attack. I didn't acknowledge that on purpose until now.

This is regarded a personal attack?
I'd like to see the other attacks.

No, this was not an attack.
It was just an observation that apparently no answer can satisfy you.

Anyway: We asked you mutliple times what exactly needs to be done in your eyes such that this issue is solved.
At first your biggest concern was about the official server collecting IPs and your proposed solution was a mirror system, especially a private mirror at your home router at first, then some server in China.
We explained to you in detail, why such a mirror system does not improve privacy at all, especially when using a machine in your home network.
We also explained what needs to be done in order to make the mirror system respect users privacy and why this is simply unreachable.

Then you changed the subject to the REST API, which -- according to you -- allows the RKI to offload malicious code to the users' mobile devices.
We explained to you in detail, why this isn't a problem and that it's basically a misinterpretation of the buzzword REST by you.

We provided a ton of counter examples for all your claims, but you just ignore them.
You cite only the parts that seem to fit your arguments and you keep repeating the same stuff over and over again, even though it was already disproven multiple times before.

This is frustrating, because we don't know, whether you're a troll who doesn't deserve an answer at all, or whether you're someone who simply doesn't know and who really needs help.

We provided multiple solutions, but you just wipe them away, because you only accept the app in the way you want it -- but you just don't tell what you want; at least not in a way that is useful for programmers.

We already reached theories about police gaining access to all these IPs from RKI without a proper court decision.

This is my last reply.
I unsubscribe right away and seriously ask the maintainers to close this issue.

[egandro]

There is no "API".

"Robert Koch-Institut (RKI)
Stellt epidemiologische Informationen und Handlungsempfehlungen für die Nutzer der App zur Verfügung (Content). Bestimmt die Parameter für die Messung der Kontakte (im Rahmen der technischen Möglichkeiten durch die API).  "

[Leseratte10]

Just because they call it an API doesn't mean it is one.

"Bestimmt die Parameter für die Messung der Kontakte". They want to provide the phone with parameters / settings about the contact tracing. Like the one I described. And a text message about what to do. Just data, no payload. No malicious stuff that needs protection by an application-level firewall.

[egandro]

Just because they call it an API doesn't mean it is one.

Again :) We don't know what we don't know. They used the term API.

According to my definition an API implies "calling a function with parameters and getting back a result".

Just data, no payload.

"2. Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert".

According to my definition "dynamic content" might be HTML. Which is - if they mean that - a heavy payload that runs code.

[Leseratte10]

"dynamic content" just means that THEY can change it, to update texts. It doesn't mean they are updating the App. And even if they send JavaScript - the App requires Android 8, that has been confirmed. On Android 8 and above, the Chromium engine is used that gets updated directly by Google, so all phones get Chrome updates. That means JavaScript also isn't a security issue due to old phones.

[egandro]

That means JavaScript also isn't a security issue due to old phones.

But it's a trust issue that you have remote code execution. :)

Edit: It's IN the process realm with all permissions of the App - not within the realm of Chrome that can't access the Apps database etc.

[Leseratte10]

No, it is not.
1) you have that on any website you visit
2) JavaScript is in a sandbox and can't do stuff outside of the website. It doesn't run in the RKI app. It juns in the Chrome layer that just happens to be displayed within the App.

The Javascript can't access app data.

[egandro]

The Javascript can't access app data.

If the earth would be a nice place - you are right!

Edit: it's still the process realm of the tracking app!

As i wrote - 4 hours ago - talk to the CCC guys who showed during the last 7 years that it can be easily done on any console :)

Again - trust issue! Do you really really really think this convinces 50 mio people?

[Leseratte10]

It can be done on consoles - because these don't get browser updates and use age-old versions.

Again - if you find an exploit that gets you out of the Chrome sandbox - you don't need to hack the RKI app. You can just hack all devices directly using Chrome.

[egandro]

Again - if you find an exploit that gets you out of the Chrome sandbox - you don't need to hack the RKI app. You can just hack all devices directly using Chrome.

That's true! So we should then make it very very hard for 3rd party (if they can hack Chome) that in case they can, that they cant get the database of the tracking app in a very easy way.

Maybe by just removing the HTML / JS stuff at all :)

[Leseratte10]

If they can exploit Chrome, on the phone (not in the RKI app!) and get full access to the phone, they can download the tracking database from the phone. Independantly from the question if the RKI app itself uses JS or not.

If you exploit Chrome and get full access, you can read ALL data on the phone. No matter what you do in the RKI app, it will always work.

[falkTX]

if you find an exploit that gets you out of the Chrome sandbox - you don't need to hack the RKI app. You can just hack all devices directly using Chrome.

I do not think this is a valid response.
There are groups that collect vulnerabilities for sale, there is a very high price for them.
The ones that get fixed are the ones that we end up finding about, the stuff that gets public somehow.

A website can very well serve content without JS, or the browser(view) disabling JS altogether.

[Leseratte10]

Yes, that is correct. But IF there is an exploit in Chrome, you don't need to exploit the RKI app. It doesm't matter if the RKI app has enabled JS or not.

You just wait until the user uses Chrome, then provide him with the hacked JSON when he visits any web page, then hack the phone and grab data. As I said above - independantly from the RKI app.

[falkTX]

You just wait until the user uses Chrome, _then_ provide him with the hacked JSON when he visits any web page, then hack the phone and grab data. As I said above - independantly from the RKI app.

True, but that requires a user to visit a very specific page. Phishing can be used to trick users, but takes a long time.
An app using webview and JS, installed by millions of people, facilitates delivering the malicious code.
By checking IP of the request, the server could serve regular content to everyone but have a special payload for specific IPs that have been blacklisted.

This is all theory, but still possible to achieve.

[Leseratte10]

That would be the same for every high-traffic web page or android app, and wouldn't really be specific to this app. No other app or website gives you the ability to mirror and verify all their JS before it is executed. So why would this app do that? The end result's the same, it doesn't matter if hackers hack the super-secure, safe RKI app that allows you to check the JS; or if they hack the 0,99€ pay-to-win minigame you downloaded from a questionable source.

Doing that is just useless work, unless every single app and every single website would do that.

Data on the phone can be read when the phone is hacked. Making one of the hundred apps on a phone secure against that doesn't matter, then the phone will get hacked through one of the 99 others.

[falkTX]

As been stated here, it is all a question of trust.

Maybe I am being naive here, but I think government should lead by example, rather than just going with whatever everyone else is doing.
Because everyone else is doing something, does not make it right to do so.

Avoiding potential security issues is a nice goal, something to be proud to achieve.

Avoiding JS is one such way.
If the app does not have to render any JS, it becomes more trustworthy.

The case here, as far as I understood, is not the app doing something malicious.
We can be sure that it does not, because we (will) have the code to inspect.
But we cannot say the same about the server side.
In there, it can in theory deliver malicious payloads. if we allow the application to render JS from the server, it becomes a potential backdoor.
I think that is the issue of trust here.
EDIT: I am not saying it is ever going to happen, only that if the option is not even there to begin with, we can be more at ease and trust it more.

[Leseratte10]

I can somewhat agree with that statement.
But look at web pages of governments or government institutions. JavaScript has become a web standard, you'll find very very few web pages without JavaScript. And probably no government website without it. If the government had such an exploit, and wanted to use it, they just need to plant it on their website (or the RKI website).

Setting such an unrealistic requirement for the RKI app, just because it's the RKI app and for no real technical reason wouldn't be a good idea either, in my opinion.

[MaxFichtelmann]

The originally stated issue is still fetching some settings.json from a server - not executing code provided from the backend, right?
Executing code from the backend would undermine the open-source character of the app but I don't believe that to be a goal here.

[Leseratte10]

Yes, it is. But even if the app were downloading JS code from a server, that could only influence the webView, not the app itself, so even that wouldn't undermine the opensource character.

[falkTX]

But look at web pages of governments or government institutions. JavaScript has become a web standard, you'll find very very few web pages without JavaScript. And probably no government website without it. If the government had such an exploit, and wanted to use it, they just need to plant it on their website (or the RKI website).

Yes, and that is very sad to see actually.
Some governments even went the ugly way of using google analytics for their official infrastructure :(

Setting such an unrealistic requirement for the RKI app, just because it's the RKI app and for no real technical reason wouldn't be a good idea either, in my opinion.

I do not think it is truly unrealistic, IF starting something from scratch.
Going the long way, taking security very seriously, will make it so that more people will trust it and use it.
I can understand we can always go an extra step security-wise, and at some point might be not cost effective anymore.
It is up for the developers here to decide, I just hope they make good decisions.

The originally stated issue is still fetching some settings.json from a server - not executing code provided from the backend, right?
Executing code from the backend would undermine the open-source character of the app but I don't believe that to be a goal here.

I think so too, but at some point JS got mentioned and that the app might render some page coming from the server.
Maybe that is not the case at all, if yes, then sorry for the noise.

[jeffreygroneberg]

For those interested: https://github.com/google/exposure-notifications-server

[egandro]

This is all theory, but still possible to achieve.

That's the point. We don't know if they would - but with the app the build the infrastructure and they COULD.

So this leads to trust issues - with no need to create this structure at the first place.

[egandro]

For those interested: https://github.com/google/exposure-notifications-server

Thank you for the link.

How is that related to downloading settings and content as mentioned in #13 ?

[Leseratte10]

Not at all. It's still interesting and related to the app.

[AlexanderS]

If settings.json is small enough, it could be distributed with DNS TXT records. This would support mirrors, is decentralized, can be signed and even have ttl values.

[jeffreygroneberg]

Not at all. It's still interesting and related to the app.

It is. It shows an example architecture how to distribute exposure data. And I am pretty sure some things of this implementation can be found in this server, too ;)

[egandro]

It is. It shows an example architecture how to distribute exposure data.

So we are at the decision "centralized server" :)

Related question to that:

Question: Why are the TicToc REST Server (run in China) considered "evil" and the Corona App REST Server (run by the German Gouvernement) considered "ok"?

I see no point :)

[Leseratte10]

Because TikTok servers control user created content and actual user data. The RKI servers don't contain any user data. Just settings.

But you are running in circles and repeating yourself.

[falkTX]

So we are at the decision "centralized server" :)

An example is no decision, as far as I know.
Just shows one possibility on how things could be done.

Related question to that:

Question: Why are the TicToc REST Server (run in China) considered "evil" and the Corona App REST Server (run by the German Gouvernement) considered "ok"?

I see no point :)

Not sure how this is relevant, but TikTok is more than just a REST server. I would say it is not even a REST server. TikTok is a mobile app, it has both frontend and backend as usual.
The frontend apparently does shady stuff and sends it all away to the backend, but how they communicate is not even relevant. They could be not even using HTTP.

I get what you are trying to do here, but you are not going to achieve that the way you are just writing things.
Just makes others not take you seriously.

[egandro]

The frontend apparently does shady stuff and sends it all away to the backend, but how they communicate is not even relevant. They could be not even using HTTP.

That's the main point :) why create the infrastructure for having shady things (later) anyway?

[falkTX]

If we have reproducible builds and no web/JS viewer, frontend can't do shady stuff here at all :)

[Leseratte10]

A simple read-only data interface for settings that can be polled by the client isn't an infrastructure for shady things. As already explained in the other 334 comments on this issue.

[mohe2015]

If settings.json is small enough, it could be distributed with DNS TXT records. This would support mirrors, is decentralized, can be signed and even have ttl values.
comment

This may actually be a good compromise. At least I couldn't see any real reason against it.

[egandro]

If we have reproducible builds and no web/JS viewer, frontend can't do shady stuff here at all :)

We also covered that :) You have no access to the signing/uploading. So you have a lot of trust.

[falkTX]

If settings.json is small enough, it could be distributed with DNS TXT records. This would support mirrors, is decentralized, can be signed and even have ttl values.
comment

This may actually be a good compromise. At least I couldn't see any real reason against it.

This is off-topic a bit I guess, but how can DNS TXT records be signed? I am interested on reading up on this, but don't know where to start..

[egandro]

This may actually be a good compromise. At least I couldn't see any real reason against it.

It's still considered side loading.

[mohe2015]

This is off-topic a bit I guess, but how can DNS TXT records be signed? I am interested on reading up on this, but don't know where to start..

I don't really know anything about that but I think it's called DNSSEC
Edit: in case of the rki.de website you could search for "denic dnssec"

[falkTX]

@egandro is there a specific approach you can recommend to use? Because I think I can also find problems in any of them you could post. At some point maybe we can say "ok, that is good enough"

[egandro]

@egandro is there a specific approach you can recommend to use? Because I think I can also find problems in any of them you could post. At some point maybe we can say "ok, that is good enough"

Topic: Remote access is violating integrity, anonymity and data protection

Integrity / Reproducible Builds

• no side loading at all - recompile the app
• never use a settings.json that can do "things" we don't know! an unknown parser/buffer overflow bug etc. is root of a lot of evil
• Content -> don't load any dynamic content in the App - use an URL and open a browser (not sure if this can be done 1000000% avoiding passing a specific device ID/IP to that url...)

anonymity

• use a decentralized server infrastructure. Never trust any 3rd party here if you have the chance to keep anonymity just do it by design!
• give the user the possibility to have proxies
• add in the application a log file / log viewer (with interaction) to actually "see" what traffic is transferred and add a "STOP > Send a 500 Error to the application, I don't want this!" Button

data protection

• basically the same as with "anonymity"
• add real world examples WHY you need a specific access for tracking (=scope)! e.g. settings, content
• Explain why it can't they be done with a QR code or a settings code you enter via keyboard in great detail! Why you tried that and why it didn't work.

SAP / Telekom Architects should really have 1000+1 solutions for all this (simple) things.

Every step that will gain 0.01% trust is necessary.

[mohe2015]

I have not enough time to answer you in detail (but probably somebody else will do) but I don't think this corona warn app will be for you. It also needs to be usable for an average person who didn't "study computer science"

[falkTX]

@egandro not sure how useful that is tbh. you tell the ideas, not the actual how, the tech we can use to make it possible.
I have a suspicion that you are asking for something you do not truly understand. because some of those things do not even seem feasible or make a lot of sense to me.

I can comment on one thing..
opening content within the app or within a URL/browser on the phone is the same thing.
for a malicious server to do anything special, it has to break browser boundaries, and that is then irrelevant where it happens exactly.

[egandro]

It also needs to be usable for an average person who didn't "study computer science"

True! But if a not so average person tells them "Hey - I don't really know what this app is sending to whom. We can't see this, we can't audit this, we just have to trust the German Government".

Then it's no so ok for the average person :)

[tkowark]

We hope that many of the discussed issues are covered by the newly released architecture document.

As stated there, no remote access from servers to the app takes place and new configurations and diagnosis keys are downloaded via a CDN.

For uploading data to the servers, a dedicated transport metadata removal actor removes identifying information, such as IPs prior to the information reaching the cwa-server backend.

If further issues regarding this topic arise from the newly published documents (architecture document) and source code (cwa-server), we kindly ask you to open a dedicated issue for them.

We thank you all for an extremely lively discussion!