Subject: [.plan] Android, ein Client-OS fuer Dumbphones
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Sun, 31 May 2015 15:47:31 +0200

Vor einiger Zeit hat Google ein Drucker-Framework in Android integriert,
das nichts bietet ausser zwei definierte Schnittstellen -- in Richtung
Anwendungen und in Richtung Druckdienst ("-app"). Leider scheint es kaum
ein Interesse daran zu geben, von seinem Smartphone aus einen Drucker
im lokalen Netz anzusprechen -- zumindest nicht in standardisiert, offen,
frei: Es gibt zwar einiger Anwendungen von Drucker-Herstellern, die
natuerlich nur mit einer sehr begrenzten Auswahl an (eigenen) Druckern
sprechen koennen -- ebenfalls alle unfrei -- und auch ein paar Apps
von Drittanbietern, die aber aehnlich beschraenkt und geschlossen sind,
aber die grundsaetzliche Idee scheint zu sein, einen virtuellen Druck-
dienst in der Cloud zu nutzen, der dann bei Darf an einen lokalen Drucker
weiterleiten kann. Wie kaputt ist das denn? Ich schicke Daten von einem
lokalen Geraet in die Cloud, damit mein lokaler Drucker davon Drucken
kann? Seufz.

Nun, Jon Freeman [0] hatte damals schon eine halbwegs funktionsfaehige
Anwendung, die per IPP (HTTP) lokale CUPS-Netzwerkdrucker ansprechen
konnte und wollte diese auf das neue Framework portieren. Leider musste
er das aber aus gesundheitlichen Gruenden aufgeben. Vor kurzem habe ich
mir die Muehe gemacht seinen alten Code auf Gradle zu portieren und
die verwendeten Binaerbibliotheken zu ersetzen bzw. direkt aus jCenter
zu holen. Das Ergebnis [1] ist jetzt auch in FDroid [2] zu finden, auch
wenn die UI grottig ist und nicht unter allen Umstaenden funktioniert.
Mir war es nur wichtig, dass wir endlich einen freien Druckerdienst fuer
Android haben und damit eine der letzten grossen Luecken schliessen.
Fuer mich ist damit ein Meilenstein erreicht:

Zum ersten Mal decken wir damit nahezu alle Bereiche und Standards ab,
die ein reiner "Client" nach aussen hin abdecken sollte:

* Mail (IMAP/SMTP/POP) [3]
* Kurznachrichten (TEL/XMPP) [4][5]
* Browser (HTTP) [6][7]
* Kontakte und Kalender (CalDAV/CardDAV) [8][9]
* Zeit (NTP) [10]
* Drucken (IPP/HTTP) [11] 
* Feeds (RSS/ATOM/FEED/HTTP) [12]
* Dateizugriff (WebDAV/FILE/HTTP/SCP/SFTP) [13][14]
* Shell (SSH) [15]
* Telefonie (TEL/SIP) [16]
* VCS (GIT) [17]

Nicht ganz zur selben Kategorie, aber fuer mich ebenfalls zu diesem
Milestone gehoerend sind Wetter- und Geodaten. Wo letzteres nicht
ueber passives GPS/GLONASS verfuegbar ist, muss es ueber CellID und
bekannte Accesspoints geschehen. Prinzipiell ist das in Android
schon standardmaessig integriert, mit dem UnifiedNlp [18] des microG-
Projekts gibt es aber die Moeglichkeit die jeweiligen Anbieter per
Plugin auszutauschen, also auch eine alternative oder gar freie
Datenbank dafuer zu nutzen -- ggf. mit Offline-Daten. Wetterdaten
sind idR zwar nicht ins System integriert, sondern nur ueber Apps
verfuegbar, doch nutzen die meisten Geraete die vorinstallierten
Google-Anwendungen dafuer. Bei freien Wetterapps [19] kann meist
auch eine freie Datenquelle gewaehlt werden.

Damit kratzen wir dann auch schon an meinem zweiten Meilenstein fuer
Android: Lokale Anwendungen. Darunter fallen neben nuetzlichen Tools,
die komplett ohne Daten auskommen, auch Anwendungen, die auf lokalen
Daten arbeiten muessen. Waehrend viele (aeltere?) Anwendungen fuer
Linux explizit zwischen der Verarbeitung und der Bereitstellung von
Daten trennen -- ein MUA arbeitet auf lokalen Mails, ob diese per POP3
oder IMAP oder XYZ eingeliefert werden und welche Programme dafuer
zustaendig sind, ist ihm egal --, es also mehrere Tools gibt, die
zusammenarbeiten, hat sich bei Android der monolithische Ansatz fast
komplett durchgesetzt. Die positiven Ausnahmen sind vorgefertigte
Schnittstellen wie SMS, Anruflog, Kalender und Kontaktdaten. Manchmal
wuenschte ich mir, dass Google von vorherein bei Android auch an ein
Sotrage fuer Mail gedacht haben sollte... aber da ich weiss, wie lax
die Leute mit Berechtigungen umgehen, ist ein app-spezifischer Speicher
evtl. doch besser. Wie dem auch sei, noch bin ich mir nicht sicher, ob
es eine direkte Folge oder der Ausloeser ist, aber bei vielen Apps ist
eine rein lokale Nutzung nicht vorgesehen. Nutzen mehrere Apps die
selben Daten, muss ich die Accountdaten in jeder App einzeln angeben
oder alle Entwickler dazu bringen eine noch zu schaffende gemeinsame
Schnittstelle zu nutzen.

Prinzipiell denke ich, dass wir mit freien Anwendungen eine rudimentaere
offline Nutzung ermoeglichen koennen. An vielen Ecken und Enden fehlt es
jedoch noch an wenigen, aber wichtigen Kleinigkeiten. Das ist aber
kein Problem der freien Software, sondern ist dem generellen "Mindset"
der meisten Android-Entwickler geschuldet: Android ist per Design
ein Dumbphone in dem Sinne, dass es konstruiert wurde, um sich mit
anderen Diensten zu verbinden, nicht um offline zu arbeiten.

Meine beiden letzten Meilensteine habe ich schon nahezu aufgegeben:
Server-Software und freie Treiber/Firmware. Waehrend die meisten bei
letzteren wenigstens noch den Sinn sehen, interessiert sich eigentlich
kaum jemand fuer Server-Software. Ich finde das ist ein fataler Fehler.
Ja, Android ist als Client konstruiert. Aber es geht auch gar nicht
darum, Android jetzt in Racks gepackt in Rechenzentren zu karren. Nein,
es geht eher um kleine Serverdienste fuer den Heimgebrauch, z.B. ein
abgespeckter IMAP-Server, der den fehlenden LocalStorage fuer Mails
bereitstellt, ohne dass die eigentlichen "Apps" angepasst werden
muessen. Ausserdem ist klar, dass eine Versteifung auf "Client" ein
fataler Fehler sein wird, wenn die dazugehoerigen (proprietaeren)
Serverdienste wegfallen... oder gar das zur Kommunikation noetige
Netz ausfaellt, bewusst manipuliert (Drosselung, Sperren, DPI..)
wird und generell nicht mehr vertrauenswuerdig ist: Ein Szenario
das gerade durch die Enthuellungen von Snowden immer greifbar wird
und meinem Tenor entspricht: Wir bauen unsere Zukunft auf eine
ziemlich bruechige Technologie, "always on" ist noch in weiter Ferne
(und evtl. auch gar nicht wuenschenswert). Das GuardianProject [20]
setzt daher vermehrt auf Pico- und Peer2Peer-Netze: Der FDroid-Client
hat dank Ihrer Hilfe eine Option, um sich selbst zum Server zu machen
und lokal installierte Anwendungen fuer FDroid-Nutzer im selben Netz
freizugeben [21] -- die FDroid-APK selbst kann per Bluetooth verteilt
werden. Ausserdem entwickeln sie neben einem XMPP-Client auch einen
reinen Bluetooth-Broadcast-Chat [22]. Bei der ganzen Debatte um Ver-
schluesselung wurde leider vergessen, dass es Situationen gibt,
in der man nicht Verschluesseln will, sondern jeden potentiellen
Nutzer erreichen will. Ein kaputtes Netz oder ein unter fremder
Kontrolle stehender Service darf uns nicht vom Kommunizieren abhalten.

[0]  http://mobd.jonbanjo.com/jfcupsprintservice/
[1]  https://github.com/krt16s/jfcups-service
[2]  https://f-droid.org/forums/topic/cups-print-app/
[3]  https://f-droid.org/repository/browse/?fdid=com.fsck.k9
[4]  https://f-droid.org/repository/browse/?fdid=eu.siacs.conversations
[5]  https://f-droid.org/repository/browse/?fdid=org.smssecure.smssecure
[6]  https://f-droid.org/repository/browse/?fdid=org.mozilla.fennec_fdroid
[7]  https://f-droid.org/repository/browse/?fdid=acr.browser.lightning
[8]  https://f-droid.org/repository/browse/?fdid=at.bitfire.davdroid
[9]  https://f-droid.org/repository/browse/?fdid=org.dmfs.tasks
[10] https://f-droid.org/repository/browse/?fdid=org.ntpsync
[11] https://f-droid.org/repository/browse/?fdid=com.jonbanjo.cupsprintservice
[12] https://f-droid.org/repository/browse/?fdid=net.etuldan.sparss.floss
[13] https://f-droid.org/repository/browse/?fdid=com.owncloud.android
[14] https://f-droid.org/repository/browse/?fdid=com.ghostsq.commander
[15] https://f-droid.org/repository/browse/?fdid=org.connectbot
[16] https://f-droid.org/repository/browse/?fdid=org.lumicall.android
[17] https://f-droid.org/repository/browse/?fdid=me.sheimi.sgit
[18] https://f-droid.org/repository/browse/?fdid=com.google.android.gms 
[19] https://f-droid.org/repository/browse/?fdid=ru.gelin.android.weather.notification
[20] https://guardianproject.info/
[21] https://dev.guardianproject.info/projects/bazaar/wiki
[22] https://github.com/n8fr8/gilgamesh/