minvws / nl-covid19-notification-app-website

Project website
https://coronamelder.nl
European Union Public License 1.2
173 stars 51 forks source link

Statement about 100% anonimity #75

Closed bwbroersma closed 3 years ago

bwbroersma commented 4 years ago

Hoe werkt de app

  • Dit gebeurt 100% anoniem: de app weet niet wie jij bent, wie de ander is of waar jullie zijn. (...)
  • Als je zelf het coronavirus krijgt, kun je dit (vrijwillig) in de app laten weten. Dan waarschuwt de app mensen met wie je contact hebt gehad. De app weet niet wie je bent, dus niemand komt dat te weten.

_Source: _statements/nl/2-how-does-it-work.md_

I assume 'the app' includes both the app and the back-end. Since the submission to the back-end is linked to your positive COVID-19 test and probably done from your home with WiFi including dynamic but pretty static IP, we have to trust the IP stripping and decoupling of these facts to guarantee anonymity. Technical measures that could be taken, e.g. using a mix network proposed long ago (in the OSF advise written by me in April), have not been implemented. Also see https://github.com/minvws/nl-covid19-notification-app-coordination/issues/13#issuecomment-636233476

jellelicht commented 4 years ago

@dirkx You mentioned that none of this stuff was in the works internally, is this still the case? If code to perform uploads over tor 'by default' will probably not be accepted as the default workflow, can we at least get a statement on not preventing people from doing so?

Specifically: Will you commit to not blocking Tor users from making use of the backend in legitimate ways?

EDIT: I mention Tor, but where possible I meant any mix network as well :-)

dirkx commented 4 years ago

We are not designing this to 'block' Tor; or filter in any other way.

If it speaks valid HTTP and sticks to the RFC1112, etc in good faith - we want it to be able to talk to our backend and our CDN.

However - if there is a large international DDOS - do expect us to use the Dutch NaWaStraat -- which means that we'll prioritise NL traffic over non-NL traffic. So that will affect Tor exit nodes that are not in NL; especially as you, if the attack continues, increasingly will prioritise home ADSL/cable-modems/etc that have humans behind them over large data centres and other places devoid of humans. As ultimately it is citizens their mobile phones that matter. Tor exit nodes in data centres are then collateral damage.

Secondly - if there is a significant volume of roque/hacking/etc coming through Tor (and few, or zero, legitimate request) -- then obviously it may be that a tradeoff needs to be made if things get that bad.

So, in general, Tor traffic will be more at risk than, say, a connection coming in from a known Ziggo endpoint or peering point with KPN home users behind it.

Thirdly - be aware that the main distribution of the Tbytes/day of the zipped-TEKs goes through a commercial CDN that is shared with other traffic. So there the risk of blanket Tor blocking in case of abuse is higher.

jellelicht commented 4 years ago

I'm only talking about uploads, so as far as I know, the ministry makes all decisions. Will you also be blanket-banning Ziggo folks if a lot of those people seem to make illegitimate requests :wink: ?

EDIT: Will the backend support uploads done via Tor, provided there is no ongoing attack being performed using the Tor network?

bwbroersma commented 4 years ago

I'm wondering how to do this for iOS/Android.

Of course you can use torrc:

ExitNodes {nl} StrictNodes 1

To force :netherlands:IP ExitNodes.

Some setups:

The first one is the easiest, but the last one would also work without WiFi and for someone who doesn't have a computer/laptop or the skills to setup Tor.

jellelicht commented 4 years ago

@bwbroersma getting interested people to run with '110% anonymity' is something we can write community documentation for. For Android, there is orbot, so it seems doable with enough elbow grease.

All we need is an insider to say that the rug won't unexpectedly be pulled out from underneath our feet because of $INSERT_COMPLICATED_POLITICAL_ISSUE_HERE at a later point in time. As dirkx mentioned, an on-going attack is of course a good reason to block access, so the question is if all other circumstances have the go-ahead.

dirkx commented 4 years ago

Hmm - het beheer van global variabelen zoals COMPLICATED_POLITICAL_ISSUE word niet door ons gedaan - maar door de tweede kamer. Dus ik vrees dat je voor dat soort zaken niet bij de technocraten terecht komt die de app bouwen & runnen.

Ik zou persoonlijk zeggen - gewoon doen. En er heel open over communiceren. Dat je het doet. Waarom je het doet. En waarom het belangrijk is. En zorgen dat dit begrepen wordt in de politiek

Zodat je de juiste reactie en informatie er al bekend is - voordat er de gebruikelijke paniek is over één van de Four Horsemen of the Infocalypse die langs komt rijden. En je niet dan pas moet uitleggen vanuit een achterstands positie dat een "tor" gebruiker echt niet hetzelfde is als een gebruiker van het internet voor terrorisme, drugs, pedofielen en de maffia.

jellelicht commented 4 years ago

Fair enough :smile: . It would still be nice to have anybody from the team react to the actual point that @bwbroersma made in the initial post; a reaction to his OSF advise that has been seemingly ignored, at least from an outsider-perspective. Thanks!

dirkx commented 4 years ago

@jellelicht denk dat dit ook inhoudelijk aan dat advies raakt.

Dus wij doen van alles aan IP stripping (en met de verhuizing is dat ook een stuk mooier nu) -- zie de documentatie. En krijgen dus geen IP addressen binnen (die blijven aan de edge van de CDN achter).

maar er is op dit moment geen planning voor TOR of mixer netwerks -- een CDN op deze schaal in een beperkt geographisch gebied is een uitdaging te ver in deze tijdlijn.

Persoonlijke noot - zou erg leuk zijn (duitsland heeft zoiets) om zo'n laag als NL overheid/maatschappij te hebben.

EdoPlantinga commented 3 years ago

FYI: for legal reasons, we decided against using the word 'anoniem' (anonymous) in our communication from now on.

dirkx commented 3 years ago

@jellelicht @bwbroersma - is er inmiddels ergens een stuk documentatie hoe je dit met producten van derden, zoals TOR of OR kan gebruiken/configureren ?

jellelicht commented 3 years ago

Ik heb zelf eerder Orbot 1 op Android gebruikt, in "Volledigapparaats-VPN".

Is het idee dat uiteindelijk CM zelf de requests doet naar de back end, of gaat dit via de implementatie van Apple danwel Google? Als CM het gewoon zelf doet, is hier in principe geen extra support voor nodig. Je kunt zelfs per applicatie afzonderlijk aangeven of je wilt of netwerkverkeer via Tor geroute worden.

Nog wat algemene punten aan de hand van waar we het eerder over hadden:

Wat dan alleen nog mist is misschien een Nederlands set vertalingen van de instructies specifiek voor CM, waarom je dit uberhaupt zou willen doen.

Het in dat geval fijn zijn om ergens een pagina te hebben waar het blokkeren of afknijpen van verbindingen afkomstig van het Tor netwerk wegens misbruik kan worden aangekondigd, om alles ook een beetje transparant te houden.

Voor iOS weet ik helaas niets over de situatie.

dirkx commented 3 years ago

Dus denk dat nodig is:

0) Test dat het nu werkt met de huidige providers & indien niet - zorgen dat we dit in de komende dagen gefixed hebben voordat het allemaal in beheer gaat. Want dan is dit 'gold'. 1) set instructies voor iOS 2) set instructies voor Android 3) een web pagina met het 'waarom' en link naar 1 & 2 voor de coronamelder.nl website.

En dan kan ik aan mijn kant er met Brenno de Winter wel voor zorgen dat we intern borgen dat dit een van de manieren is van gebruik die mogelijk moeten zijn.

EdoPlantinga commented 3 years ago

@dirkx @jellelicht @bwbroersma Quickly reading through this: this issue seems to go off-topic: it is not really about the CoronaMelder website. I am closing it here for now as we use this repo just for the website. Feel free to reopen the discussion in the documentation repo, for example, referring to this issue.