LNP350 Der Gästeblock muss in Quarantäne

Corona Warn App FAQ — Facebook und FBI hacken — Twitter will dass man Artikel liest — Raubkopierer-Oma

Die heutige Sendung steht ganz im Zeichen der Veröffentlichung der Corona-Warn-App (CWA) die mit viel Tamtam am letzten Dienstag über die Bühne ging. Entsprechend groß war die Diskussion rund um die App und wir versuchen in dieser Folge die häufigsten Fragen, die aufkamen, hier hoffentlich zufriedenstellend zu beantworten.

Dazu noch ein Bericht von Facebook und dem FBI, die gemeinsam auf Hackertour gehen, eine interessante Neuerung bei Twitter und die traurige Geschichte der Raubkopierer-Oma

Dauer: 2:04:19

On Air
avatar Linus Neumann Paypal Icon Bitcoin Icon Amazon Wishlist Icon
avatar Tim Pritlove Paypal Icon Bitcoin Icon Liberapay Icon Amazon Wishlist Icon

Prolog

CWA Release

CWA FAQ

Location-Dienste auf Android

Batteriebedarf und Gerätesupport

Datenverbrauch

Internationale Nutzung

Security

App-Zwang

Entwicklungszeit

Jan Fleischhauers Reaktion auf unsere Richtigstellungen

CWA

Open Source

Risikominimierung

TÜVit-Bericht

Rolle des CCC

Facebook und FBI hacken gemeinsam

Twitter will dass man Artikel liest

Raubkopierer-Oma

Epilog

Bonus Track

72 Gedanken zu „LNP350 Der Gästeblock muss in Quarantäne

  1. Hallo Tim und Linus,
    euer Ansatz, die real vorhandenen Sorgen um die bestehenden Schwächen der App klein zu reden, und mit dem Argument zu kommen, es gibt schlimmeres, irgendwie nicht sachgemäß. Weil man erstens nicht erwarten kann, dass einfacher Bürger den nötigen Sachverstand mitbringen, wenn selbst die Presse da seine Schwächen hat. Und zum zweiten, bringt das nicht wirklich einen benefit im Sinne des Gewinns einer Erkenntnis. Die meisten Bedenken rühren von einer einfachen Tatsache, der desaströsen Informations- und Kommunikationspolitik des ganzen Vorhabens. Des ganzen, nicht nur dem Teil über die App. Der Teil hinter der App ist im übrigen aus dem Blick der Kontrolle der Pandemie auch deutlich wichtigerer. Und wenn man sich den Start anschaut, dann muss man sich fragen, wie das passieren konnte. In beiden Stores war die App kaum auffindbar. Das ist ein absolutes Unding. Die meisten Labore sind nicht angebunden. Und die Sache mit dem nicht im Vorfeld kommunizierten Problem, bzw. der Verwirrung mit den Locations-dienst auf Android. Bei den Millionen die ausgegeben wurden, ist das eine ziemlich dilettantische Herangehensweise.

    • In beiden Stores war die App kaum auffindbar. Das ist ein absolutes Unding.

      Naja, hat halt gedauert, bis in Cupertino und Mountain View die Sonne aufgangen ist, bis das Featuring (und ggf. die Aktualisierung des Suchindex) freigeschaltet war. Finde ich jetzt nicht so ein Drama, aber liegt nicht in der Kontrolle des Projekts

      Die meisten Labore sind nicht angebunden

      Ja, das ist ein Problem, aber das haben wir ja auch angesprochen. Ist mir jetzt etwas unklar, warum Du meinst, wir würden das “kleinreden”. Aber nach einer Entwicklungszeit von nur 7 Wochen über zwei Unternehmen hinweg muss man schon auch etwas Quellzeit zugestehen. Wenn das in einem Monat immer noch so ist, dann wird es peinlich. Solange die Hotline-Methode funktioniert (und das können wir derzeit nicht bewerten), ist die Grundfunktionalität sichergestellt und darauf kommt es an.

      Und die Sache mit dem nicht im Vorfeld kommunizierten Problem, bzw. der Verwirrung mit den Locations-dienst auf Android. Bei den Millionen die ausgegeben wurden, ist das eine ziemlich dilettantische Herangehensweise.

      Kann man so sehen, kann man auch anders sehen. Denn das Problem taucht ja wie erwähnt nur bei den Leuten auf, die die Lokationsdienste für alle abgeschaltet haben. Das dürften die wenigsten sein (aber das kann ich nicht quantitiv abschätzen). Unglücklich, aber eben die Schuld von Android und nicht der App.

      Ich muss sagen, dass wenn das so die Hauptkritikpunkte bei so einem Projekt sind, dann kann ich damit vorerst leben.

      • Hier sind die Angaben der Gesundheitsämter aus dem Artikel in der ZEIT ONLINE. Daraus kann man erkennen, das so lange dort mit Fax und Telex hantiert wird, man nicht wirklich Ergebnisse aus der Nutzung der App zu erwarten hat. Der Störfaktor Mensch, ist ein großes Problem.

        Aus dem Artikel:
        “Bis heute ist bei der Befundübermittlung der Einsatz von Faxgeräten Standard. Wünschenswert wäre, technische Schnittstellen bereitzustellen, um digital mit den Laboren kommunizieren zu können.
        Gesundheitsamt Nienburg, Niedersachsen

        “Für die Bewältigung von Pandemiegeschehen ist eine bundesweit einheitliche Software zu fordern. Diese muss die Vernetzung aller Akteure ermöglichen: Arztpraxen, Krankenhäuser, Labore, Gesundheitsämter, Ortspolizeibehörden, Ministerien, RKI, Patienten, Kontaktpersonen etc.
        Gesundheitsamt St. Wendel, Saarland”

        https://www.zeit.de/wissen/gesundheit/2020-06/gesundheitsaemter-corona-infektionsketten-nachverfolgung-meldeverfahren-tests/seite-2

  2. Zu dem Thema “auch die die nicht Google-Play-Services benutzer können müssen zugriff bekommen”. Das scheint mit überschaubaren Entwicklungsaufwand möglich zu sein. Zumindest hieß es ja von Huawei das sie diese Funktion nachgebaut haben.

    • Relevanterer Frage: Spielt es eine _grosse_ Rolle? Sure es wäre nett, wenn alle das verwenden können. Aber wir haben endliche Ressourcen für sowas und gerade der HW Support ist ja das teure (zumindest wenn es überall sinnvoll funktionieren soll). Ist das wirklich worauf die Bundesregierung Geld werfen sollte? Die Diskussion geht ja jetzt schon los von wegen 20 Mio Euro ist zu teuer… (Mich wuerde eine Aufteilung in App vs Backend (für App) vs Frontend für die Labore interessieren, meine Vermutung wäre letzteres dominiert).
      Generell hätte ich es gerne, dass die BRD diese Art Software finanziert, auch um Apple und Android zumindest ne Tokenkonkurrenz zu bieten, aber das kostet halt massiv Geld…

  3. Akt 1: Tim meckert, dass die Warnung zur Nutzung von Standortdaten unverständlich ist. Typisches Android-Problem, würde bei iOS nicht passieren.
    Akt 2: Tim erklärt Minuten später, wie super verständlich die Infos zum Akkuverbrauch der App auf iOS sind.

  4. Moin!
    Es konnten keine Audio Dateien vom Server geladen werden. Entweder du hast gerade keine Verbindung zum Internet oder die Dateien sind nicht auf dem Server verfügbar erscheint, wenn ich den Podcast starten will. Also Internetverbindung läuft und ich scheine die einzige Person mit diesem Problem zu sein. Gibt es noch eine Möglichkeit den Cast woanders zu hören?
    Lg

    • es liegt entweder an meiner linuxdis
      und an den applications
      oder was weiss ich
      eher wahrscheinlich trolling
      sry wenn ich was falsch gemaxht hab
      ffs

  5. Zur Deanonymisierung von COVID-Erkrankten:
    Gibt es nicht ohnehin eine Meldepflicht? Da hätte ja der Staat wenig gewonnen und dass Bill Gates jetzt in Deutschland so ein Erkennungsnetz installiert halte ich für relativ unwahrscheinlich.

    • Ja gibt es, deswegen ist die Diskussion auch oft so durcheinander. Oder anders ausgedrückt: es gibt bisher noch kein überzeugendes Angriffsmodell auf das System, weil einfach kaum relevante Daten überhaupt den geschützten Bereich der Telefone verlassen. Der einzige Moment wo das geschieht ist die Meldung. Aber aus den veröffentlichten Daten lassen sich nun mal weder die Identität noch irgendwelche weiteren Metadaten ableiten. Die beim Upload genutzte IP-Adresse, die eine Identifikation des Telefonanschlusses ermöglichen würde, wird vom Upload-Server verworfen und nicht mit den veröffentlichen Keys gespeichert.

      Wie in der Sendung ausgedrückt: ein überzeugendes Angriffsszenario muss beschreiben, wer in dem Fall der Interessent wäre (Identitiät und Motivation) und welche Daten über wen in dem Fall gewonnen werden könnten und welche Nutzen man daraus ziehen könnte. Da gibt es nichts Überzeugendes.

  6. Zu Thema Fussballspiele, Konzerte, Gastronomie und Freiwilligkeit der App finde ich dass es eindeutig nicht legal sein darf in irgendeiner Weise da Vorschriften zu machen.
    Will sagen wenn die App freiwillig ist, muss grundsätzlich ausgeschlossen werden, dass irgendwelche Vereinbarungen halbfreiwilliger Natur getroffen werden. Also alle gemeinsamen Verabredungen sei es kleine Firma oder Olympiastadium müssen grundsätzlich ausbleiben.

    Ansonsten bedeutet das ja doch wieder Zwang durch die Hintertür bzw. ansteigend je nach Zeitdauer.
    Heute noch sehr freiwillig, morgen halbfreiwillig, in 2 Jahren kein Job oder kein Eintritt ohne diese
    (oder auch die nächste, Begehrlichkeiten sind schnell geweckt) App.

    • Die derzeitige Pflicht der Dokumentation ist ja auch nicht ohne Aufwand für die Gastronomie.
      Mein Vorschlag, zwei Optionen, Adresse aufschreiben, oder App zeigen.
      Beides muss angeboten werden und ich vermute die App, da deutlich einfacher, wird sich schnell durchsetzen.

      Bei der App wäre es vielleicht sinnvoll eine Anzeige zu haben wie lange sie denn aktiv ist, oder ob sie die letzte x Minuten aktiv war, damit man sie nicht nur beim vorzeitigen abschaltet um die namentliche Registrierung zu umgehen.

      • Ich denke nicht, dass das ginge:
        Die Gastronominnen müssen ja garantieren, jeden Tisch benachrichtigen zu können.
        Mit der App ist das je nach Distanz nicht garantiert.

        • aber halt mal, hier sollte doch die App ins Spiel kommen.
          Wenn der Tisch weit genug weg ist wenden keine Tokens gespeichert und umgekehrt.

          In zweiter Überlegung müssen natürlich die Tische an denen Gäste ohne App sitzen auch berücksichtigt werden.

  7. Zu eure Diskussion bzgl Facebook und FBI: Warum empfindet ihr das _Entwickeln_ der Schwachstelle als problematisch? Die war ja die ganze Zeit da, die ist ja nicht dafür eingebaut worden. Aus dem gleichen Grund verstehe ich den Vorbehalt nicht gegenüber Exploit _Aufkauf_ bzw _Entwicklung_ durch das BSI. Das ist für mich das gleiche wie Security through Obscurity (“solange wir nicht hinschauen wird der Bug schon nicht da sein”). Das Problem hier ist halt, dass jemand anders das hinschauen auch machen kann. Natürlich verstehe ich euer Vorbehalt, dass die “Bekanntheit” durch solche Untersuchungen steigt. Aka die organisierte Kriminalität “findet” solche Exploits wahrscheinlich relativ flott, nachdem sie in irgendeiner offiziellen Datenbank gelandet sind. Damit erhöht sich schon die Anzahl der Exploits im Umlauf wahrscheinlich schon, auf der anderen Seite “leaken” wahrscheinlich auch mehr zurück zu den Autoren, von daher: Selbst hier ist mir nicht klar, dass es schadet.

    Natürlich wäre es mir lieber (und ich verstehe auch nicht wirklich warum es nicht so ist), dass die Exploits die offiziellen Stellen bekannt sind auch direkt allgemein veröffentlicht werden. Wegen mir sogar gerne mit nem Timeout für nachrichtendienstliche Ausnutzung (der CCC hat hier bestimmt ne stark andere Meinung) und man muss nochmal drüber reden wie man mit “unresponsive” Autoren umgehen will. Aber egal wie: Man selbst hat den Bug gefunden (oder vielleicht auch nur gekauft), d.h. im _besten_ Fall war man der erste, aber man ist garantiert nicht sicher der _einzige_ der über diese Lücke stolpert.

    Übersehe ich etwas oder ist die Problematik von Exploits in den Händen von offiziellen Stellen nicht einfach nur das _Geheimhalten_ derselben und nicht das Beschaffen?

    • “Aus dem gleichen Grund verstehe ich den Vorbehalt nicht gegenüber Exploit _Aufkauf_ bzw _Entwicklung_ durch das BSI. ”
      1lEine der Aufgaben des BSI ist für die Sicherheit (von Bürgern und Firmen) in der IT zu sorgen. Dieses Ziel steht in einem starken Interessenkonflikt zum Entwickeln/Aufkaufen von Exploits.

      Ich würde auch das Aufkaufen vs das Entwickeln von Exploits nicht auf die gleiche Stufe stellen: Entwickel ich Exploits, dann suche ich nach Sicherheitslücken und verschweige die gefundenen dem Hersteller.
      Wenn ich Exploits aufkaufe, dann halte ich auch existierende Schwachstellen geheim. Allerdings finanziere ich darüber hinaus auch noch halbkrimminelle (e.g. FinF***er) und kriminelle Gruppierungen und helfe ihnen somit dabei die gesamte Sicherheit aktiv zu senken.

      • > Dieses Ziel steht in einem starken Interessenkonflikt zum Entwickeln/Aufkaufen von Exploits.

        Das ist was ich nicht verstehe. Das _Geheimhalten_ der Exploits ist was den Konflikt erzeugt, _nicht_ das Entwickeln/Kaufen (bei letzterem wird man wahrscheinlich nicht häufig Dinge Verkauft bekommen okay).

        Also in dem konkreten Fall jetzt: FB bezahlt den Exploit, gibt ihn dem FBI, wartet bis der Kerl verurteilt ist und gibt den Exploit jetzt _auch_ den Entwicklern von Tails. Ist das jetzt gutes Verhalten oder immer noch nicht?

  8. Im Bezug auf die Modus Wahl der Standortermittlung. Bei Android 9 kann man nur zwischen 2 Modi Wählen. Zwischen genauer Erfassung bei dem Mobilfunknetzte, GPS, Sensoren und Wlan erfasst wird und zwischen dem ungenaueren Modus bei dem nur GPS erfasst wird.
    Daher muss auf Android 9 für Nutzung der Standortdienst und damit der Corona Warn App das GPS tracking aktiviert sein, auch wenn die Corona App nicht selbst darauf zugreift.
    Dann bleibt mir nur die Wahl alle Berechtigung für das GPS zu tracken zurückzuziehen, damit die entsprechenden Apps nicht parallel mein GPS Standort tracken.

  9. Zu den Informatik-Drostens: Das PDF ist afaik nirgends akzeptiert. Es geht also nicht darum ein Paper vor der Konferenz oder der Publikation in einem Journal zur Verfügung zu stellen. Fragt sich also, warum das kurz vor dem Release der CWA unbedingt raus muss. Ist das Thema (wie bei Drosten) wirklich so wichtig für die Informatik? Ich denke nicht. Aber na gut — kann man machen.
    Die mit dem PDF verbundene Berichterstattung ist aber nicht ganz ungewollt: Die TU titelt “Corona-Warn-Apps haben Defizite bei Sicherheit und Datenschutz” (https://www.cysec.tu-darmstadt.de/cysec/index.de.jsp) …mal ein Blogeintrag davor schauen: Oh, eigene Corona-App ist beste von Welt! Und mit ihrem Alter Ego treiben die Autoren die “unglückliche Berichterstattung” selbst aktiv voran (https://twitter.com/tracecoronaapp). Journalisten die das ähnlich wie ihr einordnen wird explizit widersprochen.

  10. Mein Problem mit den Standortdiensten ist folgendes:
    Ich habe diese standardmäßig geräteseitig deaktiviert. Nur wenn ich diese aktiv benötige, gebe ich die Positionsbestimmung über GPS frei. Dann haben ausgewählte Apps Zugriff auf meinen Standort (wie z.B. Google Play Dienste und Google Maps damit die Navigation funktioniert). Damit die Corona Warn App funktioniert, muss ich, wie ihr schon sagt, zumindest die ungefähre Lokalisierung (ohne GPS) dauerhaft geräteseitig zulassen. Mach ich das, haben aber automatisch auch alle anderen Apps, die auf meinen Standort zugreifen dürfen, dauerhauft Zugriff auf meinen ungefähren Standort. Gerade die Google Dienste nutzen diese Berechtigung auch dauerhaft.
    Ich möchte ungern jedes mal, wenn ich eine Navigation benötige, in den Einstellungen den entsprechenden Apps die Berechtigung geben und hinterher wieder entziehen müssen.
    Was fehlt, ist eine Einstellung, die die Positionsbestimmtung ausschließlich über Bluetooth erlaubt, oder noch besser eine Berechtigung (für jede App separat), die es der Apps erlaubt, auf GPS, nicht aber auf andere Lokalisierungsmöglichkeiten zuzugreifen.
    Solange es für dieses Problem keine Lösung gibt, werde ich die App wohl nicht verwenden. Eine Lösung seitens Google wäre vermutlich nicht besonders kompliziert, ist aber vielleicht gar nicht gewollt.

  11. Ich finde es sehr gut, dass ihr nochmal fast eine ganze Folge zu den FAQ zur Corona-App gemacht habt. Allerdings ist es schade, dass die meisten Leute, die sich ebenfalls diese Fragen stellen werden, vermutlich nicht die Motivation haben werden, zu suchen, bis sie euren Podcast finden. Stattdessen werden wohl viele aufgrund ihrer Bedenken die App einfach nicht installieren.
    Eigentlich müsste im öffentlich rechtlichen Fernsehen jetzt mal eine Sondersendung zur prime time mit einer verständlichen, ausführlichen und neutralen Erklärung der App gesendet werden. Dann würden die Öffentlich-Rechtlichen endlich mal ihrem Bildungsauftrag gerecht werden.

    • Die Google Play-Dienste wollen, dass man einen Google-Account einrichtet. Das kommt mir nicht auf’s Gerät.

      (Und jetzt weiß ich auch, warum mein Bluetooth noch nicht ging. Die Ortungsdienste werde ich auch nicht anmachen, in der Vergangenheit haben die ohne Zustimmung eine Historie geloggt und verschickt.)

      CWA gerne, aber Ortungsdienste und Google-Account nein danke.

  12. Zum Thema Standort unter Android.

    Ich habe hier ein Samsung J3 SM-J330FN unter Android9 da liegen.
    Ich finde da nichts wo ich beim Standort “nur” GPS aus machen kann?

    Ich kann Nur Standort an/aus + zusätzlich “genauer Standort” mit Nutzung WLAN + Blauzahn?

  13. Hey Tim, Hey Linus,

    Ich arbeite in der Veranstaltungsbranche und bin aktuell Teil einer Arbeitsgruppe die sich mit der Fragestellung auseinandersetzt wie im Herbst unter Einhaltung der Corona Regeln wieder Veranstaltungen stattfinden können und was das für den Veranstaltungsbetrieb bedeutet.

    In diesem Zusammenhang wurde auch über die Corona App und andere Möglichkeiten der Nachverfolgung von Kontakten gesprochen.

    Es wird von Seiten der genehmigenden Behörden in jedem Fall eine Anforderung an Veranstalter geben, dass auf der Veranstaltung ein Contact Tracing möglich sein muss und der Veranstalter dazu wie auch im Restaurant die Daten der Teilnehmer vorhält.
    Das mag bei einer Einzel Veranstaltung wie einem Konzert sogar noch relativ gut über Zettel zu lösen sein.
    Wie allerdings soll das auf einer Veranstaltung die in mehreren Spielstätten über mehre Tage stattfindet (z.B. Congress) gelöst werden?
    Auch da hätte man natürlich die Möglichkeit zu sagen wir machen das beim Betreten des Veranstaltungsgeländes mit Zetteln und im Zweifel bekommt die Behörde dann halt einfach alle.
    Man könnte die Teilnehmer auch bei der Teilnahme an jedem Vortrag, Seminar, Bereichs der Veranstaltung so nen Zettel ausfüllen lassen um ein genaueres Tracing zu ermöglichen.

    Beide Varianten erscheinen mir weder besonders praktikabel noch besonders Datensparsam.

    Würde man In diesem Szenario einen Veranstalter haben der sich sehr für das Verhalten seiner Teilnehmer interessiert ließen sich aus so einer Zettelflut mit ein bisschen Fleißarbeit sehr schnell Profile über die Teilnehmer und ihre Interessen anlegen.
    Auch wenn man so ein System Zettellos mach droht Ähnliches.

    In meine Wahrnehmung wäre die vermutlich einfachste Lösung die zur Nachverfolgung benötigten Daten beim ersten Zutritt zum Veranstaltungsgelände (Einlösen des Tickets) einmal aufzunehmen und alle Teilnehmer zu verpflichten die Corona Warn App installiert und aktiviert auf dem Telefon zu haben.

    So schützt man die Teilnehmer der Veranstaltung vor der Neugier kommerzieller Akteure im Veranstaltungsbereich und muss im Zweifel( Bsp. Congress) nicht mehrere 10.000 Menschen warnen weil 1 Person die die Veranstaltung besucht hat positiv getestet wurde.

    Ich würde mich sehr darüber freuen eure Gedanken dazu zu hören. :)

    Vielen Dank für die gute Arbeit die ihr mit eurem Podcast macht!

    • Das wäre dann genau der befürchtete Einstieg in die Beendung der Freiwilligkeit. Man kann dann ohne Smartphone mit App nicht auf bestimmte Veranstaltungen.
      Und wenn das dann so gut klappt, kommt man auch irgendwann nicht mehr in den Supermarkt…

      Siehe auch meinen ersten Kommentar.
      Tut mir leid, Veranstaltungen müssen ohne ZwangsApps möglich sein.
      Ich sehe kein Problem darin, verpflichtend eine Emailadresse zur Verfügung zu stellen, bzw die ist in den vielen Fällen ja eh schon im System.
      Dann bekommen 30000 Teilnehmer halt ne Email, ist doch machbar.

    • Hallo Bernd!

      Ich finde die App auch ziemlich gut und würde sie mir installieren. Ich habe aber sehr bewusst ein recht altes Smartphone (iphone 4) und bin deshalb raus. Auf Konzerte würde ich trotzdem gerne gehen können :)
      Und wie Georg richtig sagt, wenn das einreißt, sind schnell auch andere Dinge im Gespräch…!

      (Eine Diskussion darüber warum ich mir kein neueres / gebrauchtes phone holen will, ist ein gesonderter Schauplatz. Das ist meine klare Entscheidung – am liebsten hätte ich gar kein handy, aber das pack ich bisher nicht.
      Da manche Menschen die Entscheidung mit “so einem Ding rumzulafen” nicht leicht akzeptieren können, infrage stellen und mich zu neuem Smartphone-Glück überzeugen wollen, ein paar Stichworte die für mich zu dieser Entscheidung führen:
      Ökologie (auch dem Gebrauchtmarkt will ich keine Geräte entziehen), Technikunabhängigkeit, Suffizienz (Genügsamkeit), Zeitgewinn,…
      Sehr gut sind meine Motive auch erklärt z.B. von Niko Paech bei Jung & Naiv 405 [1]
      Oder auch auf media.ccc.de [2]

      [1] https://www.jungundnaiv.de/2019/03/17/postwachstums-oekonom-niko-paech-ueber-kapitalismus-barbarei-nachhaltigkeit-folge-405/
      [2] z.B. bei 18’13” https://media.ccc.de/v/bub2018-208-digitale_suffizienz_wie_kann_die_smarte_welt_auch_grun_werden#t=1093
      )

    • Das Reeperbahn Festival, also eine Veranstaltung mit vielen unterschiedlichen Locations, hat da schon sehr konkrete Pläne:
      “Wir sehen außerdem eine Nachverfolgung des individuellen Besuchsverhaltens mit der so genannten RFID- Technik vor. Alle Besucherinnen und Besucher bekommen ein Einlassband mit einen Chip, der am Eingang und Ausgang jeder Spielstätte gescannt wird. Wer das nicht möchte, kann in diesem Jahr leider nicht teilnehmen.”
      https://www.zeit.de/hamburg/2020-06/reeperbahn-festival-coronavirus-tracking-alexander-schulze (+)

      Dort wurden bis vor einigen Jahren auch schon Beacons für andere Zwecke eingesetzt
      https://kontakt.io/blog/beacons-at-music-festivals/

  14. Hallo Tim,
    gibt es eine Möglichkeit direkt auf das Audio mit Timestamp eines Kapitel zu verlinken? Würde gern einigen Bekannten direkt euer Kapitel mit der Erklärung der Lokalisierungs-Dienste unter Android schicken.

  15. Beim Thema “iPhone 6 bekommt kein Contact Tracing von Apple” hat Tim leider Quatsch erzählt, das Gerät hat alle notwendige Hardware (andernfalls könnte man ja z.B. nicht die Beacons in nRF Connect sehen), es ist einfach Apples Entscheidung dafür kein Update mit Contact Tracing API zu liefern und dafür gehören sie dann halt auch kritisiert.

    • Hallo,
      gibt es wohl einen technischen Grund dafür, warum aktuelle iPads (A12X) und iPods (A10) auch von der Corona-Warn-App ausgeschlossen sind? Bluetooth 5.0 bzw. 4.1 ist vorhanden und iOS 13.5.1 jeweils installiert. Es scheint so, als sein Mobilfunk-Fähigkeiten zwingend erforderlich, doch mir ist nicht ersichtlich, warum das so wäre.

      Natürlich ist mir klar, dass Leute ohne Smartphone ehr einer Minderheit angehören und somit für den epidemiologischen Erfolg dieser App womöglich nicht relevant sind. Ich bin jedoch ein regelmäßiger Hörer dieses Podcasts und dachte bisher, das Funktionsprinzip der App wenigstens im Ansatz verstanden zu haben (wohl ein Trugschluss).

        • Ich benutze das iPad recht regelmäßig auf längeren Zugfahrten, wo ich durchaus nicht ganz alleine sitze. Da Mobilfunk nach meinem Verständnis optional sein sollte, kommt der Support für weitere Geräte vielleicht etwas später. Es macht schon Sinn, dass Smartphones priorisiert wurden.

          Verwundert hat mich nur die Meldung “Für diese App werden bestimmte Funktionen benötigt, die auf diesem Gerät nicht verfügbar sind.” Ist wohl etwas unglücklich formuliert.

  16. Jetzt ist aber mal gut! Wer seid Ihr, und was habt Ihr mit Tim und Linus gemacht?

    Seit Wochen und Monaten stimmen die beiden jeglichen Corona-Maßnahmen zu, egal aus welcher Ecke und mit welcher Begründung sie kommen, solange sie nur scharf genug sind. Waren (noch) nicht erfolgreich? Dann müssen härtere Maßnahmen her! Haben eine Erkrankung verhindert? Na, dann waren sie ja richtig! Merkt Ihr was? Genauso werden uns die ganzen Unterdrückungsmaßnahmen “wegen Terror und so” verkauft.

    Aber jetzt? Die Sicherheitslücke im Design braucht schon etwas Aufwand, um sie zur Totalüberwachung gebrauchen zu können? Hey, ich dachte, seit Snowden sei dieses Argument gegessen: GENAU DAS MACHEN DIE! DIE HABEN DIE MITTEL!

    Und schmierige Typen, die sich an Kinder heranmachen, die taugen jetzt mit einem Mal dazu, den Kauf eines 0days zu rechtfertigen? Holt alle Uschis Stopp-Schilder ‘raus!

    Aber was jetzt noch das Fass zum Überlaufen bringt: jetzt verteidigen die zwei auch noch Zero Rating. Aus. Vorbei. Glaubwürdigkeit verspielt, alles am Ende.

    Doch warte: solange sie den Fleischhauer nicht auch noch zum Ziel ihrer persischen Lobhudeleien machen, so lange ist noch ein Funken ihres wahren Bewusstseins vorhanden! Haltet durch, Jungs, befreit Euch vom Joch der Hirnfresser!

  17. Hallo Tim und Linus,
    Danke für euren Beitrag heute zum Thema Corona App, der hat wieder mal den Nagel auf den Kopf getroffen. Ihr habt über das Paper der TU Berlin gesprochen, welches auch bei uns in der Schweiz Aufsehen erregt hat – aber wenn ihr wissen wollt, wie weit diese rechthaberischen Streitereien gehen können, schaut mal hier rein:
    https://infoscience.epfl.ch/record/278048
    (wohlgemerkt von derselben Hochschule, die DP3T entwickelt haben, aber offenbar von einer rivalisierenden Forschergruppe). Die Reports des NCSC, welche dort erwähnt wurden, finden sich hier: https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html – ich hoffe, euch in Deutschlang bleibt dies erspart. Ach ja, offizielles Launch Date in der Schweiz soll der 25. Juni sein, falls nicht aufgrund dieser und ähnlicher Publikationen der vorzeitige Tod eintritt.

  18. Die Erklärung, warum der Energieverbrauch beim Senden geringer ist als beim Empfangen, ist nicht korrekt. Der reine Energiebedarf im Dauerbetrieb ist recht ähnlich (siehe https://infocenter.nordicsemi.com/pdf/nRF51822_PS_v3.1.pdf ). Der große Unterschied entsteht durch das Rendezvous-Problem (ist, denke ich, den meisten Ingenieuren vertraut): Da die Systeme nicht synchronisiert sind, muss entweder der Sender dauerhaft senden oder der Empfänger dauerhaft empfangen, damit sich beide “treffen”. In der Praxis ist dauerhaft senden eher unvorteilhaft, da es den Kanal verstopft. Daher sendet man nur kurz und empfängt dafür lang. Das macht den Großteil des Unterschiedes im Energieverbrauch zwischen Senden und Empfangen aus.

    • Sorry, aber das trifft glaube ich nicht zu – zumindest in diesem Fall:

      • The broadcasting interval is subject to change, but is currently recommended to be 200-270 milliseconds.[…]
      • The scanning interval and window shall have sufficient coverage to discover nearby Exposure Notification Service advertisements within 5 minutes.
      • The scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 minutes.

      https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf#page5

      • Hallo Linus

        Es trifft auch hier zu, ist jedoch etwas versteckter.
        Ein Broadcasting-Intervall von 250ms bedeutet, dass dein Sender in einem 250ms-Zyklus ca. 1ms aktiv ist (ungefähre Länge eines Advertisements) und 249ms schläft.
        Damit der Empfänger mit hoher Wahrscheinlichkeit das Advertisement empfängt, muss er mindestens 250ms dauerhaft aktiv sein. Das heißt, dass er im gleichen Zyklusintervall 250 mal länger aktiv ist. Bei nahezu gleicher Stromaufnahme von TX und RX (siehe BLE-Datenblatt von ersten Kommentar) bedeutet das, dass das Empfangen in etwa die 250-fache Energie benötigt.

        Im Fall des Contact-Tracings braucht man bei einem 250ms-Zyklus natürlich nicht jedes Paket zu empfangen. Im einfachsten Fall kann man alle 5min den Empfänger für mindestens 250ms aktivieren und kann damit den Energiebedarf von Empfangen wieder deutlich reduzieren.

        Zusammengefasst: Bei BLE ist die Stromaufnahme von aktiver Sende- und Empfangseinheit nahezu gleich. Der Hauptunterschied der gemittelten Stromaufnahme von Senden und Empfangen entsteht durch unterschiedliche Zeitmuster, in denen die Sende- und Empfangseinheiten aktiv sind, nicht durch konstruktive Unterschiede.

  19. Man gebe Tim mal ein paar Wochen ein Google Pixel, damit er sich Android mal in aktueller Version ansehen kann.

    Alles nicht mehr so schlimm mit diesem Android. (Quatsch-Hersteller mit eigener Oberfläche sind hier explizit ausgeschlossen)

    • Und das beste am Pixel, man kann es mit Graphene OS flashen und bekommt, das Beste Betriebssystem für sein Mobilgerät was wo gibt :o)

  20. Hey Linus,
    in der Folge vor dieser hattest du zum Ende erwähnt, dass du vergessen hast dich bzgl. der Geschehnisse in Münster im Kontext des Kindesmissbrauchsnetzwerkes zu äußern. Auch wenn ich glaube, dass es schwierig für euch / dich ist zu jeder Sache die eigene Meinung halbwegs sachlich und angriffsfrei zu äußern, so hab ich doch gehofft, dass ich eure Einschätzung zu den Vorfall in dieser Folge höre.
    Da Kindesmissbrauch und Terrorismus immer das Endgegner*innenargument für jeder Sicherheitsdiskussion bei vielen zu sein scheint, so denke ich, dass auch hier wieder deutlich hervorzuheben ist, dass nicht die Technik die Ursache war, dass so nen Scheiß passieren konnte, sondern, dass es immer noch die Menschen sind die dahinter stecken.
    Und siehe da, wie es heute auch wieder in einigen Medien (mal ersten Suchtreffer rausgegriffen [1]) zu beobachten ist, versuchen verschiedene Innenminister wieder mittels etwaiger Vorratsdatenspeicherung gegen Kindesmissbrauch vorzugehen.
    Langsam bin ich mir nicht mehr so sicher, ob die Vorratsdatenspeicherung nicht vllt. doch irgendwann umgesetzt wird, weil wenn man auch nur mit geringen Wahrscheinlichkeit das Thema doch durch kommen könnte, so tritt dieses Ereigniss vllt. doch nach mehr als 13 Jahren irgendwann mal ein : /

    [1] https://www.welt.de/politik/deutschland/article209936417/Kindesmissbrauch-Innenminister-wollen-die-Vorratsdatenspeicherung.html

  21. In den Shownotes ist euch wohl ein Missgeschik passiert. “Titel nicht gedunden” ist nicht wirklich die Überschrift des Handelsblattartikels. ;-)

    • Ich gebe zu dass mein Script in einigen absurden Sonderfällen nicht den Titel korrekt erkennt.
      Aber dass wir das Handelsblatt verlinken ist wirklich ein besonders absurder Sonderfall.
      WONTFIX ;)

  22. Kurze Anmerkung zum Thema Corona-App auf Diensthandys. Nicht wenige haben zwei Smartphones. Wenn immer beide dabei sind, ist dasjenige Problem. Trägt man die Geräte wechselseitig dienstlich und privat, müsste man im Falle eines positiven Tests den Test auf beiden Geräten melden. Ist das denn technisch möglich?

    • Ich denke das müsste man auf jeden Fall gut verargumentieren an der Hotline.
      Meine Vermutung ist jedoch, dass die meisten Menschen ihr Privat-Gerät immer, das Dienst-Gerät nur zu Dienstzeiten bei sich tragen?

  23. Hallo Tim, hallo Linus!

    Ich habe eine Verständnisfrage zur Corona-App, die ihr vielleicht beantworten könnt: die App ist ja Open-Source und der Code liegt auf Github für jedermann einsehbar. Aber wie kann man denn nachvollziehen, ob dieser Code auch bei Google & Apple eingereicht wurde? Das geht doch gar nicht, oder? Mir geht es hier nicht um die Aluhut-Perspektive, sondern eher ums Verständnis. Grundsätzlich könnte doch ein völlig anderer Code in der App stecken, oder?

    Vielen Dank für Eure Arbeit! Würde mich über eine Antworten freuen!

    • Du kannst dir zumindest das Android APK herunterladen und reversen.
      Es gibt verschiedene Techniken, diesen Beweis auch führen zu können (reproducible builds).
      Bei den meisten Apps, da hast du recht, könnte ein anderer Quelltext drin stecken als auf Github steht.
      In diesem Fall wäre das wohl der größte Skandal seit Snowden, wenn hier bösartig anderer Code drin wäre.
      Was aber öfters der Fall ist: marginale Abweichungen zwischen dem Test- und Entwicklungs-Setup und der tatsächlichen Production-Lösung – zum Beispiel Domainnamen usw.

      • Vielen Dank für die Antwort! Wie gesagt, mir ging es gar nicht darum zu behaupten, dass das der Fall ist, oder sei könnte, sondern eher darum, dass es eben schwierig ist nachzuvollziehen, ob es denn der selbe Code ist.
        Lg und weiterhin ein schönes Wochenende!

  24. Hallo Linus, hallo Tim,

    erst mal: Glückwunsch zur 350. Sendung und vielen Dank, dass es nochmal ein Wrap-Up zur Corona-Warn-App gab :-)

    In einem Punkt bin ich nicht ganz einer Meinung mit Euch, und das ist das “Mind the GAP”-Paper. Ich verstehe sehr gut, dass ihr kein WissenschaftlerInnen-Bashing machen wollt, trotzdem wollte ich das nicht so stehenlassen und versuche mich mal an einem laienhaften Review:

    Was mir an diesem Paper nicht gefällt, ist sowohl die Vermarktung (hat “blubb” auch schon was dazu geschrieben) als auch der ‘Stil’. Von einem wissenschaftlichen Paper erwarte ich Objektivität, die – in der Regel – ergebnisoffene(*) Beantwortung einer Fragestellung und dass Behauptungen auch bewiesen oder zumindest belegt werden. Das “Mind the GAP”-Paper verfolgt meinem Eindruck nach eine sehr klare Zielsetzung, nämlich die Schnittstelle von Google und Apple als massiv unsicher und datenschutzfeindlich darzustellen. Dazu werden an vielen Stellen unbelegte oder nur sehr schlecht begründete Tatsachen aneinandergereiht.

    (*) Wenn es um den Beweis eines mathematischen Satzes geht, entfällt das mit dem ‘ergebnisoffen’ natürlich ;-)

    Mal ein paar Eindrücke aus dem Paper – verbunden mit der Einladung an alle, sich das komplette PDF selbst anzuschauen (ist nicht sooo lang und ganz gut lesbar, weil eben wenig technische Inhalte drin sind).

    Kapitel 1 ist eine klassische Introduction (also Einführung ins Thema der Arbeit). Hier machen die Autorinnen und Autoren auch deutlich klar, wohin die Reise gehen soll:
    “The goal of this work is to perform a reality check towards providing empirical real-world evidence for the above two privacy and security risks discussed in the literature.”

    Mir persönlich wäre ein ergebnisoffenerer Ansatz lieber gewesen.

    Außerdem wird angedeutet, dass man einen Beitrag im Prozess des Testens und Zertifizierens solcher Apps leisten will – den habe ich leider nirgendwo im Paper entdeckt:
    “We hope that our findings provide valuable input in the process of testing and certifying contact tracing apps, e.g.,as planned for the German Corona-Warn-App, ultimately guiding improvements for secure and privacy-preserving design and implementation of digital contact tracing systems.”

    Dann gibt es noch einen sehr knappen Überblick über “related Work”, also im Wesentlichen eine Sammlung auf Referenzen ähnlicher Arbeiten, auf die man zum Teil aufgebaut hat. Was hier interessanterweise nicht auftaucht, ist ein Überblick über die weiteren Kapitel, was man in anderen Arbeiten häufig sieht (ich bin mir nicht sicher, ob und wenn ja wie man das bewerten sollte).

    Kapitel 2 heißt “Privacy and Security Risks of Contact Tracing Apps”

    Hier wird dann gleich in Kapitel 2.1 Stimmung gemacht:

    “Compared to many other types of applications, an app for contact tracing inevitably collects an exceptionally large amount of sensitive information about the contacts and relationships between individual users in great detail. In addition, for a mobile app to be effective for its intended purpose, as many citizens as possible should voluntarily install the app and actively use it. For this reason,the system infrastructure related to contact tracing apps will collect vast amounts of information about the mutual contacts of people – considerably more than any other approach currently used by health authorities!”

    Zwei Dinge gefallen mir hier nicht: sowohl die Behauptung, dass Contact Tracing Apps “unausweichbar außergewöhnliche große Mengen sensible Daten sammeln” – das stimmt so im Allgemeinen einfach nicht, sowie die darauf aufsetzende Behauptung, dass die Infrastruktur große Mengen an Daten über gegenseitige Kontakte von Menschen sammelt – auch das ist für den dezentralen Ansatz schlichtweg falsch.

    Anschließend werden noch ein paar allgemeine Aussagen zu Privacy getroffen (im Stile von “Menschen sollten Kontrolle über ihre Daten haben”), den man natürlich nicht widersprechen will, die für mich hier aber etwas deplaziert sind.

    In den Unterkapiteln 2.1.1 – 2.1.3 werden Privacy-Probleme von verschiedenen Ansätze für Contact Tracing (GPS, Bluetooth, Zentral vs. Dezentral) kurz beschrieben. Insbesondere das Kapitel 2.1.2 finde ich sehr absurd – die Behauptung ist hier, dass es mithilfe von strategisch platzierten BLE Sensoren problemlos möglich ist “to identify a large fraction of users with high probability.”. Hierfür liefert die Arbeit im Weiteren keinerlei Belege oder auch nur plausible Begründungen. Und ja, der Punkt den Tim (?) auch schon angesprochen hatte, dass man mit Hilfe von Gesichtserkennung hier noch bessere Ergebnisse erhält, steht da auch drin – kein Kommentar dazu…

    Kapitel 2.2 zu den Sicherheitsrisiken verweist nochmal auf eine andere Arbeiten zum Thema Relay-Angriffe und gibt kurz wider, was Probleme an Gegenmaßnahmen sein könnten.

    Kapitel 3 beschreibt das “Privacy Risiko” des Google-Apple-Protokolls, wenn man überall BLE Sensoren aufstellt.

    Eine echt spannende Info (zumindest für mich) – und damit einer der wenigen positiven Aspekte der Arbeit – war die Unterscheidung zwischen ‘Rolling Proximity Identifiers’ (RPIs), die sich alle paar Minuten ändern und ‘Daily Tracing Keys’ (DTKs), aus denen die RPIs generiert werden und die im Falle einer bestätigten Infektion auf den Server geladen werden können. Ich hatte das in allen Erklärungen bisher immer so verstanden, dass die RPIs im Falle einer Infektion geteilt werden, nicht die DTKs – ich glaube, so wurde das tatsächlich auch oft vereinfachend erklärt. [Aus didaktischen Gründen verstehe ich gut, dass man hier eine Reduktion der Komplexität beim Erklären macht – war aber beim Lesen des Papers tatsächlich ein Punkt, wo ich sehr stutzig wurde, bis ich das für mich klären konnte, dass das tatsächlich so ist, wie in der Arbeit beschrieben. Hier würde mich eine Erklärung, warum man die DTKs und nicht die RPIs hochlädt, interessieren. Meine Vermutung wäre ja, dass bei den RPIs hinterher das Runterladen ein Problem mit der Datenmenge liefert – stimmt das?]

    Nun zum Angriff selbst – Kapitel 3.2: “We used commodity smartphones as the sniffers that can capture Bluetooth LE signals at a distance of up to 6 meters.”. Ok, dann deckt also ein Sniffer eine Fläche von ca 113 Quadratmetern ab. Darmstadt hat laut Wikipedia eine Fläche von 122 Quadratkilometer, also braucht man rund eine Million Sniffer, um die Stadtfläche von Darmstadt abzudecken (ja, mir ist klar, dass das nicht sauber gerechnet ist – geht mir hier aber auch nur um die grobe Größenordnung). Aber die Autorinnen und Autoren sagen auch gleich dazu, dass man mit speziellen Antennen auf größere Distanzen Signale aufnehmen kann (hier sind leider keine Werte angegeben – möglicherweise sind solche Geräte aber auch unproportional teurer).

    Das tatsächliche Experiment bestand dann leider nur aus 6 Bluetooth-Sniffern und 2 Nutzern, die durch die Innenstadt gelaufen sind. Sehr ärgerlich finde ich in diesem Kontext Abbildung 2 “An example of observation points”, wo auf der Karte insgesamt 12 (!!) Bluetooth-Sniffer eingezeichnet sind – also die 6 tatsächlich eingesetzten und dann noch… ja, ich weiß auch nicht?! Würde ein Studi sowas in einer Bachelor-Arbeit abliefern, würde ich doch sehr hoffen, dass die zuständige Betreuerin oder der zuständige Betreuer das mit der Begründung “Das ist aber nicht sauberes wissenschaftliches Arbeiten!” direkt zurückweist. Sorry, aber … sowas will ich in einem Paper wirklich nicht sehen. Ich frage mich immer noch, ob das “nur Pfusch” oder ein bewusster Versuch war, einen falschen Eindruck zu erwecken.

    Was ich auch nicht sehe, ist der Mehrwert dieses “Experiments”. Dass man theoretisch Leute mit genügend Sniffern tracken kann, war vorher schon klar – was ist hier die neue Erkenntnis? Dass es tatsächlich geklappt hat mit 6 Sniffern und 2 Personen. Das ist… beeindruckend?

    Für ein Real-World-Experiment, das in der Introduction angekündigt wurde, hätte ich hier gerne ein De-Anoynimisierung anhand von realen Daten gesehen. Vielleicht mal die Sniffer nach Start der App zwei Wochen auf dem Uni Campus laufen lassen und kucken, ob man Mitarbeiterinnen und Mitarbeiter oder auch Studis deanonymisiert kriegt? Das wäre eher meine Vorstellung eines Real-World-Experiments und die Ergebnisse fände ich schon deutlich interessanter.

    Leider schließt das Kapitel dann schon wieder mit wilden – zwar korrekten, aber in dem Kontext nicht wirklich relevanten – Behauptungen: “Moreover, de-anonymization becomes easier if the adversary has access to additional information about social relationships of users, e.g., the social graph of an online social network (OSN). This graph can be used to identify the infected users and their social contacts by comparing the social graph of the infected users obtained by the profiling attack to the OSN social graph.” Ich sag mal so: Was man mit Social Graphen anstellen kann, ist durchaus beeindruckend – aber wofür brauche ich dann noch genau die Bluetooth-Sniffer? Das fällt für mich klar unter ‘Thema verfehlt’.

    Kapitel 4 beschreibt dann noch das “Security Risiko” des Google-Apple-Protokolls, insbesondere einen Wormholing-Angriff. Hier fehlt mir das technische Know-How, dieses Kapitel sinnvoll zu beurteilen – mag das wer anders übernehmen?

    Die Zusammenfassung in Kapitel 5 liest sich im Vergleich zu anderen Stellen dann schon wieder relativ sachlich. Was hier natürlich nicht fehlen darf, ist die an ganz vielen Stellen im Paper wieder und wieder angeführte Kritik, dass die Google-Apple-API nicht open source und daher nicht wissenschaftlich überprüfbar ist, verbunden mit der Forderung, den Code der API offenzulegen. Diese Forderung kann ich aus wissenschaftlicher Sicht voll und ganz nachvollziehen, finde aber, dass dieser Punkt in der Arbeit sehr gebetsmühlenartig wieder und wieder aufgeführt wird – zumal sich die Autorinnen und Autoren ja dadurch nicht davon abhalten lassen haben, ein wissenschaftliches Paper zu veröffentlichen.

    Insgesamt kann ich nur sagen: Für mich ist das leider keine wichtige akademische Arbeit, sondern viel heiße Luft um ein recht dürftiges Resultat.

  25. Den “Exploit” mit der der Deanonymisierung beim gleichzeitigen Aufstellen von Kameras würde ich jetzt nicht komplett von der Hand weisen.

    Das Problem ist hier natürlich nicht Deanonymisierung/Tracking an sich, sondern dass ich dann zu jeder Person, von der ich Foto + Corona-App-Beacon habe, weiß, ob sie infiziert ist, sobald sie nach einem positiven Test ihre Codes veröffentlicht.
    Das ist der Zeitpunkt, ab dem die Zuordnung ein Problem darstellt (wenn auch meiner Ansicht nach ein in Kauf zu nehmendes).

    • Ja, das hatten wir doch auch so geschildert.
      Zur rechtlichen Einschätzung habe ich keine Ahnung, aber immer wenn davon die Rede war, fiel auch der Begriff “meldepflichtig”, durch den Infizierte wohl auch Teil ihres Anspruchs auf Anonymität verlieren. Auch die Tatsache, dass ich infiziert bin, kann ich im Bekanntenkreis ja kaum geheim halten.
      Das müssten Juristinnen jetzt nochmal genau erklären, wie da die Hintergründe sind.
      Ich stimme mit deiner Einschätzung überein, dass das in Kauf zu nehmend ist – nicht akzeptabel wäre es, wenn solche Daten bulk ohne Pseudonymisierung rausgehauen würden.

  26. Linus Hinweis zu dem Aufwand der Profilbildung durch eines großen Sensornetzwerkes ist natürlich richtig. Aber man sollte auch bedenken, dass es bereits größere Bluetooth Mess-Netze gibt, z.B. für das Messen und Verfolgen von Besucher- oder Verkehrsströmen, wie etwa in meiner Stadt: http://www.verkehrslage-mv.de/vlz.html
    Als direkte Bedrohung sehe ich das zwar nicht, aber natürlich ist das Ausrollen und syncronisieren von BT Scannern auch nicht völlig unwahrscheinlich. Ich vermute, das Low energy bzw. das opt-in von Sichtbarkeit steht dem erst einmal im Weg. Aber wären so 10Eur pro Sensor https://github.com/cyberman54/ESP32-Paxcounter

  27. Lieber Tim und Linus
    Danke für euren super Podcast. Ich habe noch eine Frage bezgl der Corona Warn app: aktuell benötigt die APP bei Android ja Google Dienste. Ich persönlich benutze Lineage OS ohne proprietäre Google services. Damit funktioniert die Grundfunktionen der app nicht mehr. Welche technischen Voraussetzungen werden benötigt damit die APP auch ohne Google sevices läuft. Wäre das auf APP Seite zu lösen oder auf OS Seite? Vielen dank schon mal für eure Einschätzung.

  28. Es ist richtig, dass man bei Android Standort generell aktivieren und den Zugriff einzelner Apps beschränken kann.Eine Ausnahme bildet offenbar der Google Playstore, diese bei Android notwendige App unterbindet es ihr die Berechtigung zu entziehen.

  29. “Wir werden vor etwas warnen, was an diesen Prüfsteinen scheitert”

    Prüfstein Nr. 4: Transparenz und Prüfbarkeit
    “[…] Durch Reproducible-Build-Techniken ist sicherzustellen, dass Nutzer überprüfen können, dass die App, die sie herunterladen aus dem auditierten Quelltext gebaut wurde.”

    Gelistet ist es als “Gesellschaftliche Anforderung” und die Dokumentation der CWA schreibt, dass allen “Technischen Anforderungen” (also ab Prüfstein Nr. 5) genüge getan werde.

    Wie hat der CCC abgewogen, dann doch nicht vor der App zu warnen? Ist es
    – “Naja, wenn sie das verkacken, ist der Fallout aber enorm”
    -> Und was, wenn sie es verkacken? Dann könnte man nachlesen: “Oh hm, das war doch Prüfstein des CCC, warum haben sie uns nicht gewarnt?”

    Die Abwesenheit von Reproducible Builds ist übrigens Bug #14 in deren Repo (https://github.com/corona-warn-app/cwa-documentation/issues/14) und scheint so schnell nicht angegangen zu werden.

  30. Moin Linus, Moin Tim,
    habe gerade LNP350 gehört. Als über “Google-freie” Geräte geredet wurde, ist mir aufgefallen, dass du MicroG nicht zu kennen scheinst. Das ist eine freie Alternative zu den Google Play Diensten. Man kann damit auch den Play Store nutzen, und so manche andere API, siehe auch nanolx.org
    Die Corona App kann man damit natürlich nicht nutzen. Vielleicht interessant für dich.
    LG, Langzeit-Hörer des Podcasts der zum ersten mal einen Kommentar von sich gibt

  31. Kleine Anmerkung zu Whonix:
    Während die technologische Architektur des Projekts definitiv solide aussieht, legt der Hauptentwickler offenbar Wert darauf, das Projekt mit einem Account in dem angeblichen Free Speech (sprich: Nazi-Echokammer) Microblogging Netzwerk Gab vertreten zu haben.

    Statt sich dazu zu äußern, nimmt er lieber testimonials von der Whonix Website. https://micahflee.com/2020/06/is-the-whonix-project-run-by-fascists/

    Das macht das Projekt technisch nicht schlechter, aber ob 1 ein Projekt das expliziten Wert darauf legt, auch rechtsradikale aktiv mit anonymem Internetzugang auszustatten (statt es nur in Kauf zu nehmen), fördern will ist schon eine Überlegung wert.

    • Das ist ja voll schlimm. Wie soll man denn jemanden vertrauen schenken, der womöglich nahe rechts steht bzw. sich nicht einmal konkret dazu äußert, wenn er damit direkt konfrontiert wird. Hatte mich schon gewundert, warum Nina die Arbeit hat ruhen lassen. Leider ziemlich traurig. Danke für den Link.
      Und zurück zu Tails …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.