--- /dev/null
+From: Boris Kraut <krt@nurfuerspam.de>
+To: undisclosed-recipients: ;
+Date: Sun, 31 May 2015 15:47:31 +0200
+Message-ID: <20150531154731.EfaPmu@edupad.local>
+Reply-To: Boris Kraut <krt@nurfuerspam.de>
+Subject: [.plan] Android, ein Client-OS fuer Dumbphones
+
+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/
projects / krt-msg / commitdiff