Zum hauptinhalt springen

Schlagwort: api

No one else was in the room where it happened - disturbing the clubhouse peace

Coverimage

What happened so far …

In our first thread on Clubhouse (in german) we had only taken a superficial look at Clubhouse.

We saw that Clubhouse uses an external service provider called Agora.io for the voice call functionality. Agora.io is also used by many other apps, including a therapy app. In the thread we found that, among other things, we can easily listen to a room without being displayed to the other room participants if we communicate directly with Agora.

Conversely, you can also be displayed in a room without listening. However, this is not really a problem - after all, even outside Clubhouse you are often present in conversations without really listening.

… and what happened next …

Clubhouse really likes your phone book

Dieser Artikel ist auch auf Deutsch erschienen.


tl;dr: Every time you open the invite tab, clubhouse uploads all the phone numbers from your address book.


Clubhouse is currently invite-only, which is probably part of the current hype. To invite someone you have to give Clubhouse access to your address book. This has been criticized several times. There has been a lot of discussion about how Clubhouse uses this address book data. We took a look and document how clubhouse currently uses the data from your address book and how it could be done better.

Clubhouse mag dein Telefonbuch wirklich gern

This article was also published in english.


tl;dr: Jedes mal, wenn man das Invite-Tab öffnet, werden alle Telefonnummern aus dem Adressbuch hochgeladen.


Clubhouse ist aktuell invite-only, was vermutlich einen Teil des aktuellen Hypes ausmacht. Um eine Person einzuladen muss man Clubhouse Zugriff auf das eigenene Adressbuch geben. Dies wurde bereits mehrfach kritisiert. Es gab viel Diskussion, wie Clubhouse diese Adressbuch-Daten nutzt. Wir haben uns angeschaut, wie Clubhouse das Adressbuch verwendet und wie es besser ginge.

99 Notfallapps auf ihrem Weg zum Cell Broadcast

Headerbild mir Sirene

Wie ihr alle mitbekommen habt (oder vielleicht eben auch nicht) fand am 10. September der erste bundesweite Warntag statt. Neben Sirenen und Rundfunkunterbrechungen sollten auch die Warn-Apps getestet werden. Aus nicht wirklich nachvollziehbaren Gründen gibt es in Deutschland nicht die eine Warnapp™, nein, es steigen gleich drei wichtige Apps in den Ring:

  • NINA: Die vom Bundesamt für Bevölkerungsschutz und Katastrophenhilfe bereitgestellte App, in deren Fokus die Auslieferung von Katastrophenmeldungen, die in den Zuständigkeitsbereich des Bundes fallen.
  • Katwarn: Ursprünglich im Auftrag des Verbandes Öffentlicher Versicherer von Fraunhofer FOKUS entwickelt, wird aber mittlerweile von vielen Gemeinden, Kreisen und Ländern als offizieller Kanal zum Ausspielen von Katastrophenwarnungen in deren jeweiliger Zuständigkeit genutzt. Zusätzlich existiert nur für Hessen noch eine eigene, weitere App HessenWARN, deren zusätzliche Existenzberechtigung mir komplett schleierhaft ist.
  • BIWAPP: Als weitere regionale Warnapp, die von der Marktplatz GmbH entwickelt und betrieben wird, und für manche Kreise, Städte und Gemeinden als deren offizielle Warnapp fungiert.

Bis vor kurzem mussten sich BürgerInnen selbst informieren, welche App denn jetzt für ihre Region zuständig ist - um sicher zu gehen aber jedoch alle drei Apps installiert und aktiviert haben, da man sich nicht zwingenderweise immer im gleichen Landkreis aufhält. (okay, dieses Jahr vielleicht schon). Seit Februar 2019 tauschen die Apps ihre Meldungen mit NINA aus (wobei es wohl keinen Austausch zwischen BIWAPP und Katwarn gibt). Das macht doch Lust auf mehr!

Jedenfalls sollten diese Apps jetzt im Rahmen des Warntags im großen Stile getestet werden, was bei uns doch etwas Interesse hervorrief. So entstand im vorhinein des Warntages die Idee, die Verfügbarkeit der hinter den Warnapps stehenden Serverinfrastruktur von außen zu monitoren. Kurz vor knapp haben wir das ganze am Abend vor dem Warntag dann auch tatsächlich noch schnell eingerichtet.

Da Monitoring der Verfügbarkeit von Infrastruktur ein normales Vorgehen für den Betrieb von IT ist, gibt es dafür auch eine Menge an fertigen Tools. Die Tools sind in der Regel dafür ausgelegt, Infrastruktur “von außen” (aus dem Internet) zu beobachten, da bei einem Komplettausfall ein internes Monitoring (im selben Netz, Rechenzentrum, …) auch weg sein könnte. Zudem ist es einfach sinnvoller von Außen zu testen, wenn der normale Anwendungsfall auch von außen passiert.

Übersicht der Schnittstellen in UptimeRobot

Übersicht der Schnittstellen in UptimeRobot

Wir haben dafür den Service UptimeRobot auf sämtliche uns bekannte Schnittstellen der Apps angesetzt. Dieses Tool misst minütlich, ob der entsprechende Server verfügbar ist und wie lange dieser zum Antworten braucht. Ist die Antwortzeit ungewöhnlich lange, ist das ein Indiz dafür, das der entsprechende Server überlastet ist. Die Infrastruktur für das Ausliefern von Push-Notifications lässt sich von außen leider nicht ohne weitere Informationen über das System monitoren.

Um an die Information zu kommen, mit welchen Servern und Schnittstellen die Apps sprechen, musste wir die Apps auseinander nehmen - denn die Schnittstellen sind nicht öffentlich dokumentiert und wurden bislang auch nicht auf Anfragen nach dem Informationsfreiheitsgesetz herausgegeben.

Leider ist es uns in der knappen Zeit nicht gelungen, die Schnittstellen aller Apps heraus zu finden. So konnten wir bei Katwarn nur die ping Zeiten der Server, jedoch nicht die wirkliche Reaktionszeit des Dienstes überwachen.

Außerdem haben wir noch die Info-Webseiten der Apps mit ins Monitoring aufgenommen.


Und dann kam alles anders schlimm.

Donnerstag, 10. September 2020, 11 Uhr. Die Sirenen heulen leise am Horizont, aber die Apps pushen nicht.