02.12.2019 Jonas L. App-Kritik

Okuna (früher Openbook) präsentiert sich als besseres Facebook. Allerdings ist die Realität nicht so wie die Selbstdarstellung.

Daher zuerst die Selbstdarstellung. Diese gibt es unter https://www.okuna.io/en/home. Was steht dort Gutes (ausgewählte Aussagen von der Webseite):

We're firm believers privacy is a fundamental human right. We don't track nor monitor your activity.

Our background is information security. We are baking in security, right from the start.

Through a combination of our community-crafted guidelines, ethical design and code, we foster an environment of friendliness, respect and openess where happiness is the end goal.

Jemand (nicht ich) hat sich genauer mit Okuna beschäftigt und ein paar Fragen gestellt:


I have some questions about okuna and the app.

1.) Why is okuna not available at the F-Droid Store? It’s the most privacy supporting App-Store.

2.) Why does the okuna app need to implement trackers? It’s not very privacy friendly and not told at your website. This must be communicated with the community….

3.) When is okuna going to be dezentralized? 1 year or only a half …?

4.) Why do you use Google recaptcha in your website? It’s the biggest tracker in the world, an alternative would be better

5.) Why is there no gpg public key available for encrypted mails? You can upload the key to the new key server with auth, too. hkps://keys.openpgp.org

6.) Will okuna be part of the fediverse like mastodon, peertube, friendica, pleroma etc.?

Thank you.

Best regards
(Name entfernt)

Der Punkt 2 bezieht sich auf https://reports.exodus-privacy.eu.org/en/reports/101792/. Wenn bei einer Anwendung wirklich Wert auf den Datenschutz gelegt wird, dann sind in dieser genau 0 Tracker enthalten. Das ist hier aber nicht der Fall.

Der Punkt 4 bezieht sich auf https://www.okuna.io/en/contact-us. Das erschreckende ist, dass man das Datenschutzproblem kennt:

Okuna Kontaktformular

Technisch betrachtet braucht man überhaupt kein Kontaktformular. Man muss im Formular eine E-Mail-Adresse für eine Antwort angeben, sodass man selbst eine E-Mail-Adresse braucht. Dann hätte man sich also das Formular sparen können und gleich auf die E-Mail-Adresse verweisen können.

Das man bei den Punkten 1 und 5 überhaupt nachfragen muss ist im Allgemeinen normal, aber bei dieser Selbstdarstellung könnte man eigentlich erwarten, dass so etwas selbstverständlich ist.

Our background is information security. We are baking in security, right from the start.

Der erste Satz könnte stimmen. Der zweite Satz ist so aber unglaubwürdig.

Die Punkte 3 und 6 sind auch wichtig: Will man dezentral werden oder (wie Facebook) zentralisiert bleiben. Auf der Webseite steht dazu nicht Gutes:

Will Okuna be decentralised?
Building a federated login system which allows self-hosted instances to hook into the main network while being able to operate by themselves is in our roadmap.

Hier versteckt man sich hinter einer umständlichen Formulierung. Das ist sehr raffiniert. Zum einen die Formulierung “is in our roadmap”. Also grundsätzlich geplant, aber man macht noch keine Zusagen über den Zeitpunkt. Weiterhin steht da überhaupt Nichts von einer Dezentralisierung. Man sagt nur etwas zur Idee von selbstgehosteten Instanzen, die mit dem Hauptnetzwerk kommunizieren können. “Hauptnetzwerk” klingt an dieser Stelle nach einer zentralisierten Instanz. Wenn man nach diesem FAQ-Eintrag geht wird es also nur irgendwann eine Pseudo-Dezentralisierung geben. Eine Nennung vom Fediverse gibt es nicht, sodass man da keine Hoffnung haben sollte.

Für eine Antwort hat man seitens Okuna zehn Tage gebraucht:

1) F-Droid requires apps to work without the native Google android services, this took Signal about 5 years to accomplish. It’s hard to make an app built for a platform, to work without the platform services. A solution such as the one they implemented with Websockets will take some time to implement. Before then, we cannot offer it on F-Droid as it will be broken due to the missing notifications.

2) There are no trackers on the website nor on the app, we’re not really sure how you came to that conclusion.

3) Once the platform is sustainable and we have the resources to allocate to the task.

4) As compared to all other sites on the internet, we don’t load Google recaptcha until the person confirms he wishes to do so by pressing a warning yellow button with a huge lists of reasons why not to load it and suggesting using email instead. If the person doesn’t care about the items, he does so by being wholly informed. This allows us to have both choices for people, to contact us directly through the website or through an email if possible. A recaptcha is necessary to prevent abuse. We tried alternatives, they were all by-passable and prone to abuse with the exception of Google’s one.

5) We do have a PGP key, however we only use for security disclosure reports here https://www.okuna.io/en/vulnerability-report .

Will add it somewhere on the email contact form page.

6) Not for the foreseeable future. We’re trying to change the nature of social networks and their features, it’s hard to do that when you have to conform to a protocol based on a notion of what social networks should be in terms of functionality and communication.

Best regards,
(Name entfernt)

Zuerst zum Punkt 1: Seitens Signal war man gar nicht daran interessiert, dass man ohne Google Cloud Messaging arbeitet. Dafür gab es einen Fork. Dieser Fork war seitens Signal nicht erwünscht. Die Nutzung vom Begriff “platform services” ist irreführend. Es geht hierbei nicht um Funktionen von Android, sondern um Funktionen der Google-Apps. Da Smartphonehersteller Android kostenlos bekommen und die Google-Apps dazukaufen können, kann man die Google-Apps nicht als Teil der Platfform bezeichnen.

Zum Punkt 2 gibt es später noch eine genauere Information seitens Okuna.

Zum Punkt 3 (Dezentralisierung): Wenn wir die Ressourcen haben kümmern wir uns darum. Das erscheint mir unrealistisch. Eine Dezentralisierung ist eine sehr fundamentale Entscheidung. So etwas kann man von Anfang an vorsehen, aber dann würde man es ja schon haben. So etwas gut und vollständig nachzurüsten erscheint mit unrealistisch.

Zum Punkt 4 habe ich bereits gesagt, dass man auch auf das Kontaktformular verzichten könnte, wenn es am Ende genau so wie eine E-Mail behandelt wird.

Zum Punkt 5 ist zu sagen, dass diese E-Mail jetzt schon über einen Monat alt ist. Auf der Kontaktseite kann ich dennoch keinen Schlüssel finden.

Auch den Punkt 6 kann man nicht so ganz glauben. Natürlich will man nicht genau so sein wie etwas Bisheriges. Es verlangt aber auch Niemand, dass alle Funktionen über Standardprotokolle genutzt werden können. Zum Fediverse gehört z.B. das ActivityPub-Protokoll. Im Inhaltsverzeichnis gibt es im Kapitel 5 ganz interessante Überschriften: Outbox, Inbox, Followers, Following, Liked, Likes und Shares. Ich kann mir nicht vorstellen, dass Okuna all diese Konzepte nicht hat.

Folglich wurden dazu Rückfragen (wieder nicht von mir) geschrieben:

Hello (Name entfernt),

thanks for answering.

Some more questions :D

1.) Why does okuna need the services of G Suite for your Mail Domain, there are alternatives with better privacy.

2.) The okuna App has some trackers implemented, I think that’s not the right way. Do you know about the trackers? Exodus: https://reports.exodus-privacy.eu.org/en/reports/91532/

Best regard
(Name entfernt)

Dieses mal hat man 3,5 Wochen für eine Antwort gebraucht:

Hi (Name entfernt),

Sorry for the late reply. We’ve been busy wrapping a new release.

1.) Pragmatism and functionality. Yes, there’s some better private alternatives for mail, but none close to the suite of tools that Google provides as part of the G Suite, including Docs, Sheets, in which we all collaborate in doing project roadmaps, graphs, documents, etc. I strongly believe privacy can’t be a selling point as long as the same ease of use and base functionality is not there. That’s why at Okuna instead of reinventing the wheel like Mastodon or Diaspora onto how everything happens behind the scenes, we’re focusing on a polished, well designed and performant usable application first.

2.) OneSignal is a push notifications service provider. We use it to deliver push notifications to users which never contain private information. It’s probably classified as a tracked because it can also do notifications based on location, however this permission is not enabled nor we request in iOS nor Android.

The Firebase analytics code is included as part of the firebase library in Flutter (the framework of the mobile app) which allows to receive push notifications on Android. We have requested the team to remove it entirely as seen here https://github.com/flutter/flutter/issues/40967 .

(Name entfernt)

Der Punkt 1 ist interessant:

Die Bequemlichkeit ist intern sehr wichtig. Natürlich ist vorstellbar, dass die Google-Dienste ausgereifter sind als NextCloud. Wenn man dann aber die Google-Dienste bevorzugt, dann kann man diesen Menschen bei Datenschutzaspekten nur noch begrenzt vertrauen.

Auch bei dem Dienst selbst kümmert man sich zuerst um eine schöne Oberfläche. Da sehe ich ein Problem: Die Oberfläche kann man leicht ersetzen, die Technik dahinter nicht. Man könnte die Technik später neu bauen und die Oberfläche recyceln. Dann muss man “nur” allen Nutzern erklären, dass sie die neue Technik benutzen sollen und die Daten nicht von der alten zur neuen Technik übernommen werden können. Alternativ könnte man auch eine Migration bauen, aber auch das geht nicht reibungslos, sodass man dann wahrscheinlich mit der alten Technik, bei der die Oberfläche das Wichtige war, weiterarbeitet.

Beim Punkt 2 muss ich ein kleines Lob aussprechen - inzwischen ist Firebase Analytics nicht mehr in der App enthalten.

Das verlinkte Ticket - https://github.com/flutter/flutter/issues/40967 zeigt, dass das Firebase SDK nicht über Flutter, sondern mittels OneSignal in die App kam.

Aber Firebase Cloud Messaging wird wahrscheinlich immer noch verwendet. In der OneSignal-SDK-Test-App wird nur der Google Play Location Service eingebunden, aber das OneSignal SDK nimmt an, dass Firebase Cloud Messaging bereits eingebunden ist. Das hat wahrscheinlich mit dem OneSignal Gradle Plugin zu tun, dass wahrscheinlich Firebase Cloud Messaging zu den Abhängigkeiten hinzufügt. Außerdem konnte ich im Quelltext vom OneSignal SDK als Eingangskanäle nur Firebase Cloud Messaging und den Amazon-Push-Dienst finden, sodass ich annehme, dass OneSignal nur eine Hülle um diese beiden Dienste ist.

Dann ist die Frage, warum man OneSignal braucht und man nicht direkt Firebase Cloud Messaging benutzt. Das würde nicht den Datenschutz retten, aber das würde einen unnötigen Dienstleister in der Datentransportkette eliminieren.

Abschließend möchte ich noch einmal auf die Selbstdarstellung eingehen:

We're firm believers privacy is a fundamental human right. We don't track nor monitor your activity.

Wenn man wirklich selbst davon überzeugt ist, dann macht man gewisse Dinge anders.

Our background is information security. We are baking in security, right from the start.

Wenn man den Firebase Analytics Code in der App hat und man es nicht merkt, dann wird diese Aussage absolut unglaubwürdig. Würde auch Schadcode unentdeckt bleiben?

Through a combination of our community-crafted guidelines, ethical design and code, we foster an environment of friendliness, respect and openess where happiness is the end goal.

“openess” würde eine Dezentralisierung voraussetzen. “respect” würde auch den Respekt vor der Privatsphäre der Benutzer bedeuten.

Die Probleme bei Facebook hat man hier nur teilweise erkannt und deshalb behebt Okuna auch nur ein Teil der Probleme, die es bei Facebook gibt.