From: Boris Kraut To: undisclosed-recipients: ; Date: Sun, 31 May 2015 15:47:31 +0200 Message-ID: <20150531154731.EfaPmu@edupad.local> Reply-To: Boris Kraut 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/