Differences and rationale from DP-3T

[oiime]

I am trying to figure out the rationale for this project when projects like DP-3T already exist and are completely open. what is the technical differentiation for this project and why can't it be built on top of existing open source initiatives? As the code is still not available in any form it's hard for me to try to figure this out myself but going by solution_architecture.md there is nothing particularly novel about it to justify a whole new standalone project. It'll be nice to have that being clarified.

Thank you

[tklingbeil]

Please look carefully before claiming that no source code is available yet. You will see that the repository for the server code is indeed available: https://github.com/corona-warn-app/cwa-server

[oiime]

Please look carefully before claiming that no source code is available yet. You will see that the repository for the server code is indeed available: https://github.com/corona-warn-app/cwa-server

The server code is not particularly relevant or interesting, the design is and should be that the privacy issues are handled at the client end, you might aswell have a closed source backend and it would be of equal trust value to the user as it can not be vetted by anyone anyway once deployed.

but the question was more about the justification of making a separate project with less oversight, what is the technical reason to do so? what do you do so differently that merits a whole new project? I think addressing that would calm some of the concerns around it

[AndiLeni]

@oiime DP-3T is a specification, while the Apple/Google Exposure Notification API on which this app is based on is an implementation according to the specification.

[oiime]

@oiime DP-3T is a specification, while the Apple/Google Exposure Notification API on which this app is based on is an implementation according to the specification.

I'm a bit confused by that. DP-3T is a specification but also has implementations for various devices. an implementation that would probably be prioritized by google/apple as it is the more common one. Regardless, it is surely not derived from the documentation here that this project is an implementation of DP-3T, at best it states it is "like DP-3T" which could mean anything.

As the implementation here is developed behind the scenes while at the same time given the mandate to become the official app from the government you can understand why that answer seems a bit insufficient

[AndiLeni]

I can understand your thoughts about development behind closed doors, even if I do not share them.

However, there should be no concerns regarding the implementation. On the github page of dp3t-sdk-android you can read: "This is the first implementation of the DP-3T protocol using the Exposure Notification Framework of Apple/Google." So the official version of the DP-3T SDK is also based on the API of Google/Apple. On the "prestandard" branch, which does not need the API, it is explained that a pure implementation on the DP-3T side has limitations that are unavoidable without the help of the API.

It is also mentioned that the goal of DP-3T is to support the Google/Apple protocol.

So the developers of DP-3T are not working against Google/Apple. Both are working together on a solution.

If a contributor is reading this, please correct me if I give wrong information.

[oiime]

@AndiLeni I have seen the DP-3T implementation and obviously they have adapted it alongside Google/Apple (refactored as the previous branch was not compatible), but that doesn't really address any of the questions. it is an open and more vetted SDK with a bigger community. Why wouldn't the german government build on that? and if they chose not to what is the rationale? That was my original question. to which I can either try to answer it by looking at the code (which I can't) or have somebody tell me technically what is the reason behind it

[AndiLeni]

I am sorry if I understood you question wrong.

I would say they don't use the sdk (yet), because according to DP-3T it is only in an early alpha stage.

Still an interesting question that a collaborator might be able to answer in more detail.

[SebastianWolf-SAP]

Just a small sign of life from us before the weekend: You'll get a complete response from our end in the beginning of next week. You know it's "Brückentag" today and as people have worked very, very hard over the last few weeks, some took their well-deserved day off to spend their time with their family and to recharge their batteries.

We need their detailed feedback before we are able to provide you with the complete picture - which you definitely deserve. Before we publish a premature response and probably create an incomplete picture, we simply want to make sure that we don't miss anything and that you have everything at hand before we continue the discussion which will follow most certainly. ;)

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

[SebastianWolf-SAP]

@oiime, thanks for your question and concerns. And sorry that we let you wait with the reply until today.

First of all, rest assured that we closely studied and continue to learn from the work being done at DP-3T. There is a reason why we mentioned them prominently in our README. When our development began several weeks ago, we had a look at the existing implementation. Back then, it did not use the Google/Apple APIs and therefore would have suffered from limitations especially on iOS devices. While the team in the meantime also implemented this approach, we, of course, had to move forward with that in parallel.

That does not rule out a future convergence/integration towards supporting both the Google/Apple and DP-3T protocols. It is just not the scope for the first release. Furthermore, the ministry of health and RKI, of course, have specific requirements both for the UX/UI and the backend integration, which need to be implemented on our end.

Especially backend-wise, we have to cater to many specifics of the German healthcare landscape. That includes things such as the test verification process or updating of risk parameters set in the Google/Apple APIs through the RKI. Moreover, one of the requirements is also the notification of COVID-19 test results - which is also very specific to Germany at this time.

Of course, all these arguments aren't really deal-breakers when we talk about an integration of the German solution with DP-3T. Both are using the decentralized approach, both will eventually use the Google/Apple Exposure Notification Framework (probably with specific extensions), so what's the problem? Well, those of you who have already worked in big projects - where you need to bring together several different parties with different backgrounds and especially with overall converging, but in detail differently prioritized interests - know that major delays don't come from the actual coding, documentation or similar work. The delays come from the time- and resource-consuming efforts to align all these different parties before the actual work can be done.

As you can see from the solution architecture we already have a quite complex setup alone in Germany. Adding more parties to this setup upfront would simply have meant further delays. So we needed to make a decision - a decision which was the most promising one to bring out a solution for Germany which addresses the data privacy and other concerns properly, which works best under the given circumstances and which is available to all of you in the shortest possible period of time. In the end, it's not a "normal" project like other ones we all know who work in the software or similar industries. The upcoming Corona-Warn-App will be one vital component in battling this coronavirus disease and may play one vital role in preventing further waves. Consequently, some priorities and decisions may look a little bit odd from the outside, especially when you are used to the paradigm of "reuse as much as possible, implement only the differentiating components yourself", but we can guarantee that the decisions in this project have been very educated ones. There is no "not-invented-here" issue or anything similar here.

We hope that the upcoming source code will make some of these issues clearer and ask for everybody's patience for a couple of more days. Nevertheless, we'd also like to point out that most of the other implementations (including DP-3T) did not start by pushing empty projects and working from there, but created at least early versions and improved them with the help of the community.

This is something that we are also very much looking forward to.

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

[oiime]

First of all, rest assured that we closely studied and continue to learn from the work being done at DP-3T. There is a reason why we mentioned them prominently in our README. When our development began several weeks ago, we had a look at the existing implementation. Back then, it did not use the Google/Apple APIs and therefore would have suffered from limitations especially on iOS devices. While the team in the meantime also implemented this approach, we, of course, had to move forward with that in parallel.

The first commit to this repository was May 13, at which point there was already a repository of a working DP-3T implementation of the exposure notification framework. Though I assume you could have started work earlier

Especially backend-wise, we have to cater to many specifics of the German healthcare landscape. That includes things such as the test verification process or updating of risk parameters set in the Google/Apple APIs through the RKI. Moreover, one of the requirements is also the notification of COVID-19 test results - which is also very specific to Germany at this time.

As stated before the backend is not particularly relevant, you can implement what you wish there so long that its interaction with the client does not divulge any identifiable information.

Of course, all these arguments aren't really deal-breakers when we talk about an integration of the German solution with DP-3T. Both are using the decentralized approach, both will eventually use the Google/Apple Exposure Notification Framework (probably with specific extensions)

Both are quite centralized, the benefits are in the pseudonymous processes on the client end that protect the user from both malice and incompetence at the server side, a protection that comes from having a well vetted client, which is the main point of contention

As you can see from the solution architecture we already have a quite complex setup alone in Germany. Adding more parties to this setup upfront would simply have meant further delays

That is understandable, but from my point of view, this here is the additional party that introduces further delay

which addresses the data privacy and other concerns properly, which works best under the given circumstances and which is available to all of you in the shortest possible period of time.

Both are worse off in this case, more data privacy concerns are added and the availability takes longer

but we can guarantee that the decisions in this project have been very educated ones. There is no "not-invented-here" issue or anything similar here.

That is all fine and well but you must understand that it is difficult to rely solely on guarantees

we'd also like to point out that most of the other implementations (including DP-3T) did not start by pushing empty projects and working from there, but created at least early versions and improved them with the help of the community.

And none of them started by having the government preemptively contract a private company to develop the de facto tool to use, they first openly developed a solution with the community. None of this criticism and concern would come about if you just went about developing this solution on your own, but as you act in the capacity of the german government and not just as a private company I think the expectations of conduct are higher. Especially considering this is the only public medium to voice concerns. The level of adoption of this product would be intrinsically tied to the level of trust you can achieve

Lastly to the point at hand, my initial interest was in understanding the exact technical differences between what you are doing on the client end and the open implementation. ideally in a document. as I assume in that delta I am more likely to find security issues. not in a broad theoretical discussion

[SebastianWolf-SAP]

The first commit to this repository was May 13, at which point there was already a repository of a working DP-3T implementation of the exposure notification framework. Though I assume you could have started work earlier

Our work started earlier, you certainly saw the announcement of the German government on April 28th, that they have contracted Deutsche Telekom and SAP to build this application: https://www.spiegel.de/netzwelt/apps/coronavirus-t-systems-und-sap-sollen-tracing-app-entwicklung-uebernehmen-a-2c17c96e-ba53-42ba-ace4-42cd2c3215b0

As stated before the backend is not particularly relevant, you can implement what you wish there so long that its interaction with the client does not divulge any identifiable information.

The backend is very relevant to make the whole infrastructure running properly. All the different aspects and requiements are clearly described in the scoping document and the architecture documentation. And as it's a vital part, it needs to be available at a very early point in time to do solid testing.

[...]

As you can see from the solution architecture we already have a quite complex setup alone in Germany. Adding more parties to this setup upfront would simply have meant further delays

That is understandable, but from my point of view, this here is the additional party that introduces further delay

That's a fair point, but as mentioned - taking the known aspects at project start into account - we see it differently.

which addresses the data privacy and other concerns properly, which works best under the given circumstances and which is available to all of you in the shortest possible period of time.

Both are worse off in this case, more data privacy concerns are added and the availability takes longer

SwissCOVID which builds on DP-3T is currently in pilot phase and is scheduled to launch end of June or slightly before, see e.g. https://www.bag.admin.ch/bag/de/home/das-bag/aktuell/medienmitteilungen.msg-id-79229.html They have a slightly different approach when it comes to the pilot phase and testing, but the overall schedule doesn't look that different...

but we can guarantee that the decisions in this project have been very educated ones. There is no "not-invented-here" issue or anything similar here.

That is all fine and well but you must understand that it is difficult to rely solely on guarantees

That's why the code will be released very soon. As already outlined, there needs to be a solid balance between the publication and the work which needs to be done upfront to have a proper foundation ready.

we'd also like to point out that most of the other implementations (including DP-3T) did not start by pushing empty projects and working from there, but created at least early versions and improved them with the help of the community.

And none of them started by having the government preemptively contract a private company to develop the de facto tool to use, they first openly developed a solution with the community. None of this criticism and concern would come about if you just went about developing this solution on your own, but as you act in the capacity of the german government and not just as a private company I think the expectations of conduct are higher. Especially considering this is the only public medium to voice concerns. The level of adoption of this product would be intrinsically tied to the level of trust you can achieve

We are very much aware of the boundary conditions and the expectations to us in this project. Please understand that we won't engage in a hypothetical what-if discussion about other approaches to this challenge. Just one thing to add as it's a fact: This is definitely not "the only public medium to voice concerns". We are a democratic society, there are plenty of ways to raise your voice and become heard. There is the German Federal Government, there are your local members of parliament, there's the traditional media, there is social media etc.

Lastly to the point at hand, my initial interest was in understanding the exact technical differences between what you are doing on the client end and the open implementation. ideally in a document. as I assume in that delta I am more likely to find security issues. not in a broad theoretical discussion

Such a document or any other similar thing would require a considerable amount of work which would continuously being updated as both solutions evolve from day to day. It is currently not in the project scope. But once all source code is public from both sides, the community can (and probably will) certainly provide that. Once again, we ask you for a little bit more patience, the necessary foundation work simply takes some time. Thank you very much!

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

[oiime]

The backend is very relevant to make the whole infrastructure running properly. All the different aspects and requiements are clearly described in the scoping document and the architecture documentation. And as it's a vital part, it needs to be available at a very early point in time to do solid testing.

I understand it is vital, but it is not relevant to the evaluation of privacy, this seems to be a thing missed here and in other issues, by design the solution should be safe irregardless of the security and internal considerations of the backend

That's why the code will be released very soon. As already outlined, there needs to be a solid balance between the publication and the work which needs to be done upfront to have a proper foundation ready.

I really don't understand that argument, how is releasing the code early detrimental to the development? if this is indeed intended to be an open project then openness should come first, not as an afterthought.

there are plenty of ways to raise your voice and become heard. There is the German Federal Government, there are your local members of parliament, there's the traditional media, there is social media etc.

I am well aware of that, the reason for me to post here first as it is the only way to get actual answers. i need to first make up my own mind if this project should be trusted or not before i recommend to others if to avoid it or not

[SebastianWolf-SAP]

The backend is very relevant to make the whole infrastructure running properly. All the different aspects and requiements are clearly described in the scoping document and the architecture documentation. And as it's a vital part, it needs to be available at a very early point in time to do solid testing.

I understand it is vital, but it is not relevant to the evaluation of privacy, this seems to be a thing missed here and in other issues, by design the solution should be safe irregardless of the security and internal considerations of the backend

Sure, but as mentioned, privacy is not the only aspect to consider - it's a combination of several aspects and all need to be taken into account when you do project planning and the setup.

That's why the code will be released very soon. As already outlined, there needs to be a solid balance between the publication and the work which needs to be done upfront to have a proper foundation ready.

I really don't understand that argument, how is releasing the code early detrimental to the development? if this is indeed intended to be an open project then openness should come first, not as an afterthought.

Well, you need to staff people who handle the issues and pull requests. And the earlier in the project the more issues and PRs that you will get will need to be closed with the reason that "this is preliminary", "this is still work-in-progress", "this was requested that way by the client" etc. Things like that are problematic on both sides: On our side because we need to invest more resources to give the same answers over and over without any benefit for the goal and on the side of the community as it creates frustration. In the end, the basic set of requirements, the basic UX flow and other side aspects need to be there first before contributions can be accepted. It's simply a balance as mentioned before - and we are not alone with this approach, many other OSS projects do that as well, no matter if we talk about contract work like here or other approaches.

there are plenty of ways to raise your voice and become heard. There is the German Federal Government, there are your local members of parliament, there's the traditional media, there is social media etc.

I am well aware of that, the reason for me to post here first as it is the only way to get actual answers. i need to first make up my own mind if this project should be trusted or not before i recommend to others if to avoid it or not

Completely agree. Everybody will get their hands on the code well before the public release - so that for instance such assessments can be done in time.

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

[oiime]

Well, you need to staff people who handle the issues and pull requests. And the earlier in the project the more issues and PRs that you will get will need to be closed with the reason that "this is preliminary", "this is still work-in-progress", "this was requested that way by the client" etc. Things like that are problematic on both sides: On our side because we need to invest more resources to give the same answers over and over without any benefit for the goal and on the side of the community as it creates frustration. In the end, the basic set of requirements, the basic UX flow and other side aspects need to be there first before contributions can be accepted. It's simply a balance as mentioned before - and we are not alone with this approach, many other OSS projects do that as well, no matter if we talk about contract work like here or other approaches.

I wholly disagree with that, opening to the community early and correctly would grant you resources, not take them away from you. This project, though it has a lot of interests to it, is relatively simple as evident by both the specifications and the current backend implementation. bigger and more complex community only projects are often done with no corporate backing.

OSS projects rarely operate like this and that should be self-evident to people who participated in OSS projects before. But I guess we would not reach any agreement here. All I can do is hope it'll turn out better than I expect it to be

[SebastianWolf-SAP]

Well, I'd be cautious with terms like "self-evident" or similar statements, but such discussions might better be done somewhere else. Let's put it like you said: We both agree to disagree.

Looking forward to further discussions once all codelines are public!

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team