In Poland I am (or rather I was) privately involved in a project of developing such an app over the last few weeks. So I have some experience with it. Unfortunately this kind of application has limited potential unless it is installed by the whole population in the country and it requires governmental backing (it has to be connected with tests and a formal diagnosis of people). I am not sure if Apache-led projects might be able to achieve it/ agree we should all think how we can help with existing initiatives. But we have to be careful with the privacy concern - which is, I believe, an important aspect.
Let me tell you my story from the last couple of days. I am an engineer in a company that specializes in developing Bluetooth/BLE applications (we created and open-sourced a number of BLE libraries which are among the most popular in the world and some people from the company help to develop such applications: https://github.com/ProteGO-app . Note - it was not the company initiative and it is not affiliated with it, some people from our company contributed pro-bono there, that's it. It started as a project that would keep the data on the phones and will only submit to the server anonymous data of encounters via BLE with other (also healthy) people to the server. Initially the decisions and status were supposed to be done on the phone and healthy people's data would never leave the phone nor will ever be de-anonymisable. Unfortunately while the idea was originally to have a solution that will protect privacy, decisions made (not by me and I was strongly opposing them from the very beginning) turned it into something very different: - obligatory registration via Mobile Phone Number when you install the app - mapping of the pseudonymous identifiers to the phone numbers kept on the server - ability to derive the user from pseudonymous encounters during the 2 weeks before diagnosis As a result it will be possible to track encounters of nearly the whole population if the application becomes really popular (and being wildly popular is a prerequisite of success for such an app). I am not in the project any more - I quit the project at the very moment those decisions were made, but I am actively commenting on it, raising issues and concerns (mainly privacy, ownership, licensing etc.). The client + backend APIs are released on GPL + AGPL licences (which is good) but the mechanism of registration and lack of transparency on the server-side algorithms make me really worried, so I am currently in the process of involving the privacy-aware NGOs (I have meetings tomorrow) to make them aware about huge risks involved with such approach and possibly influence change in the direction of the project. It's not that I am opposing the whole idea. Quite the contrary I love the idea, but only if it is done with privacy in mind. And there are alternatives (probably more than those two): - The https://www.pepp-pt.org/ initiative (providing that they will hold to the original manifesto and privacy statement when they actually release something) - for centralized (but anonymous) solution - And the whitepaper https://github.com/DP-3T/documents - which is a theoretical (so far) approach for building a fully decentralized solution. Unfortunately most of the communication in the project is in Polish, but there are a couple of issues in English. But If you think it's a good idea to help and if the ideals of privacy are dear to you, I'd encourage you to raise and upvote the issues there. Not sure if the ASF itself can do anything about it or want to (probably not and it's not ASF's role) but if we manage to turn around and make the solution privacy-aware, then I'd really encourage to contribute to it. The technology part (especially Bluetooth-related part of the protocol) is done by one of the best Mobile Bluetooth engineers in the world. No kidding - they developed a lot of great libraries for BLE that are wildly popular. Those libraries are all open sourced - Apache 2.0 Licence :) https://github.com/Polidea/RxAndroidBle , https://github.com/Polidea/RxBluetoothKit, https://github.com/Polidea/FlutterBleLib, https://github.com/Polidea/react-native-ble-plx BTW. If somebody would like to start such an initiative, I think many of those great engineers would be happy to take part in an ASF-run initiative like this if some people from ASF decide to take any actions on it. If someone has a contact with some privacy aware NGOs who would like to learn more about it - I am also happy to help and explain everything in detail. J. On Sun, Apr 5, 2020 at 3:17 PM Peter Lin <wool...@gmail.com> wrote: > sounds interesting. > > On Sun, Apr 5, 2020 at 9:14 AM Ed Mangini <m...@emangini.com> wrote: > > > > > https://www.wsj.com/articles/u-s-and-europe-turn-to-phone-tracking-strategies-to-halt-spread-of-coronavirus-11585906203 > > > https://www.wbur.org/commonhealth/2020/04/03/contact-tracing-coronavirus-massachusetts-baker > > > > It might be worthwhile to look into one of the efforts underway, and > "lend > > a few hands". > > > > > > Ed Mangini > > m...@emangini.com > > > > <http://emangini.com> > > > > > > > > On Sun, Apr 5, 2020 at 9:06 AM Raphael Bircher <rbircherapa...@gmail.com > > > > wrote: > > > > > Hi all > > > > > > I think we all are right now in a challenging situation. Many > > > countries are in a lockdown. But there is also a discussion around, > > > what we do after this emergency stop. One solution ist to track down > > > the rout of the Virus. If a new case comes in, you search out the > > > social connections. Thy can be warned, and make a test to. > > > > > > I know, tracking Apps are already in discussion, but maybe it's a good > > > idea to have something open source under AL v2. > > > > > > I know, Apache normally don't act proactive. But maybe we should make > > > an exception here. What do you think? > > > > > > Regards Raphael > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- +48 660 796 129
