Why did the SwissCovid team not disclose the existence of the LASEC report? about documents HOT 15 OPEN

The meaning of the term "thin" is subject to interpretation. As I see it, if the essence of the privacy-preserving protocol is developed in an open source manner, then the application can be termed "open source". The possibility of malicious or untrustworthy behavior of lower-level software stack elements is always there, but should be the subject of a different level of risk analysis and debate; it's not a property of the contact tracing protocol, but of its operating environment.

Let's keep in mind here that for such a level of assurance one would have to examine the complete stack including the operating system (it could always modify the application), the compiler (ditto), the processor's microcode, and the platform's hardware. These are all legitimate concerns, but they cannot be used as arguments for asserting that a given application is not open source.

from documents.

Just to make it clear. Laurent Franceschetti is not interested in a clear debate. He already tried to troll my Linked-in account with complotist theories around EPFL.

The LASEC report is part of the normal Public Security Test process. It has been read by the several national security agencies and an official answer has been provided by the Melany group : https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html

Please respect the work of this professional people. If you find serious security holes, inform the community or the Federal Data Protection Officer (https://www.edoeb.admin.ch/edoeb/fr/home.html). The whole team would be grateful.

from documents.

@AlfredoEPFL I would be grateful if you sticked to github's etiquette and you refrained from attacks ad personam.

There is a clear question, so let us stick to the argument at hand and answer the questions.

The report from LASEC is available (signed by prof. Vaudenay of EPFL) in the top post of this issue, and you are welcome to comment on it.

from documents.

It might be pertinent to link this link to DP-3T/dp3t-sdk-android#10 , where the decision to adopt the Google/Apple API is questioned.

from documents.

We'll let the leaders of this project refute this report point by point.

The question is this: could anyone download the code and compile it on their own machine, with free, unfettered access to the SDKs of those APIs written by Google and Apple?

Note that this is a legal requirement of the bill in Parliament:

Art. 60a
e. "Source code and technical specifications of all components of the TP system are available to the public. The programs readable by a machine must have been processed, in a verifiable manner, with this source code."

https://www.parlament.ch/centers/eparl/curia/2020/20200040/S1%20F.pdf

It says ALL components.

Why is the issue critical? Because DP-3T actually substituted, on the way, existing open source code with closed source code from Google/Apple.

So you have an open source project which ditched open source and verifiable code, in favor of a closed source API, in front of a stringent legal requirement to keep the code open source and verifiable.

That is something that should be discussed publicly.

(all translations into English are mine)

from documents.

The App cannot -- in the present state -- be consdered "real open-source" (it would be rejected e.g. by the F-Droid App store, because it uses binary components which cannot be compiled from (available) sources.) So it is partly open source but does not fulfill the standards of the F-Droid philosophy. Being open source is a gradual quality and not a binary one. Even when this would be fixed, and the CWA-App can be published and offered in F-Droid, then it is still the issue using the Google-Play services (then probably incorporated into the Android core). Some people will still have problems with this fact.... So, What are the standards? In detail? This is simply not clear and subject to interpretation. So, the customer (the public represented by politicians) has not in detail defined these standards and the companies have simply done, what they are good for, namely sold the app to them. And the did a good job, as far as I heared in the media. But maybe it is up to the (unpaied) open-source hobbyists to define them (the open-source standards). A good starting would be the F-Droid standards: Any Corona-Warn App would need to be published in the F-Droid-App store (I cannot thing of anything more open-source than that). Even still this app will use the OS-API and these issues remain. Android (and iOS) are not(!) open-source operating systems. At least not real ones, only partly open, same as above....

from documents.

It is simply out of scope to develop a (google-free) (made-in-europe) Smartphone operating system. It would be fine to have one today, but the world is not perfect. The reason why this is not really possible is (to my opinion) that since nobody can earn anything with developing such an OS, the whole project would need to be publicly funded, and from my experience it is hard t believe that any funding in the order of 20M€ will accomplish anything here. Linux is the only OS which at least comes close to a self-funded OS, but as you may know, it failed to colonize the Smartphones. There is no Linux-Phone or Linux-Tablet which could compete. If you would want to go that way, maybe the solution also mentioned in that report in question here, going with simple and dedicated extra hardware (something you put on your keychain), with no OS at all (or maybe with linux/raspberry pi), will be it. But You still have to sell(!) it to the people in the end. How would you do this?

from documents.

@kollokollo Thank you for your useful contribution. I realize that this is not necessarily an open and shut question. Nevertheless, very explicit commitments were taken at very high level.

The bill currently on Swiss parliament confirm that the specification imposed on the project that (this was an explicit request by Senate):

"Source code and technical specifications of all components of the TP system are available to the public. The programs readable by a machine must have been processed, in a verifiable manner, with this source code."

Also, the Swiss Federal Office for Public Health (FOPH) expressely wrote in their FAQ dated 29 may:, p. 3

The Apple/Google application interface (API) is not a mobile phone app. It is a standard proposed by Apple/Google in order to achieve a more accurate estimate of the distance between two mobile phones via Bluetooth, and to reduce electricity consumption by Bluetooth Low Energy. Data security remains guaranteed – the Apple/Google standard is also based on the DP-3T concept drawn up by the Federal Institutes of Technology in Zurich and Lausanne.

(emphasis added)

That seems a firm and strong commitment. Do we have verifiable evidence that both the Apple/Google standard are actually based on the DP-3T protocol?

from documents.

As a side note, I posted a question 20 days ago on the IOS site (DP-3T/dp3t-sdk-ios#117) , which asked whether the team should not make a documentation website for that app (e.g. readthedocs), as is usually the case with open source projects.

Unfortunately, there has been no answer. Would the project contributors like to elaborate why they did not answer that question?

from documents.

Since you are asking why: What do you expect? People have no time, they are working on other projects, they are not payed to answer, ... Many reasons we would have to accept.

from documents.

@kollokollo I would suggest the we only answer clear and precise questions that are not answered officially yet, and certainly not a bunche of fuzzy references. One simple question=one answer. As you say our time is precious.

from documents.

@kollokollo @AlfredoEPFL I see.

Are you essentially stating that

1. the employers who pay the contributors to DP3T, do not consider that it was part of their tasks to answer community-asked issues on Github?

and/or

2. You are on a specific employer policy that any question on the project would have to be answered by official sources and not by the team itself?

If that is the case, it is OK to frankly admit it. We will then take it from there.

from documents.

I warned you guys...

from documents.

@AlfredoEPFL Thank you for your comment. It has been, so far, a productive conversation.

To better qualify this issue, it is a compliance issue, of whether or not the DP-3T is really an open source (MPL) project, and more generally whether it meets specific legal specifications which have been set by the authorities and parliament.

The question was prompted by two standard indicia used in compliance routine checks:

1. Lack of relevant information provided in a timely manner (the LASEC report)
2. Lack of prompt and willing answer when questions are being asked.

As said above, it would be OK for you to admit that you are under non-disclosure agreements and that you are not willing to release any information or make any comment (other that which has already been said in official statements).

Otherwise, the efforts made so far to not answer the issue, would only increase the number of questions asked.

from documents.

As a document pertinent to the question, here is the statement published by Prof. Vaudenay (EPFL/LASEC) himself:

Although the source code of the app is available, we cannot compile it, run it, and make it work without signing an agreement with Apple or Google. We do not find it compatible with the notion of open source.

(emphasis added)

https://lasec.epfl.ch/people/vaudenay/swisscovid.html

from documents.