git.marmaro.de Git - krt-msg/blob - 2015-05-31T13:47:31Z.msg

   1 From: Boris Kraut <krt@nurfuerspam.de>
   2 To: undisclosed-recipients: ;
   3 Date: Sun, 31 May 2015 15:47:31 +0200
   4 Message-ID: <20150531154731.EfaPmu@edupad.local>
   5 Reply-To: Boris Kraut <krt@nurfuerspam.de>
   6 Subject: [.plan] Android, ein Client-OS fuer Dumbphones
   7
   8 Vor einiger Zeit hat Google ein Drucker-Framework in Android integriert,
   9 das nichts bietet ausser zwei definierte Schnittstellen -- in Richtung
  10 Anwendungen und in Richtung Druckdienst ("-app"). Leider scheint es kaum
  11 ein Interesse daran zu geben, von seinem Smartphone aus einen Drucker
  12 im lokalen Netz anzusprechen -- zumindest nicht in standardisiert, offen,
  13 frei: Es gibt zwar einiger Anwendungen von Drucker-Herstellern, die
  14 natuerlich nur mit einer sehr begrenzten Auswahl an (eigenen) Druckern
  15 sprechen koennen -- ebenfalls alle unfrei -- und auch ein paar Apps
  16 von Drittanbietern, die aber aehnlich beschraenkt und geschlossen sind,
  17 aber die grundsaetzliche Idee scheint zu sein, einen virtuellen Druck-
  18 dienst in der Cloud zu nutzen, der dann bei Darf an einen lokalen Drucker
  19 weiterleiten kann. Wie kaputt ist das denn? Ich schicke Daten von einem
  20 lokalen Geraet in die Cloud, damit mein lokaler Drucker davon Drucken
  21 kann? Seufz.
  22
  23 Nun, Jon Freeman [0] hatte damals schon eine halbwegs funktionsfaehige
  24 Anwendung, die per IPP (HTTP) lokale CUPS-Netzwerkdrucker ansprechen
  25 konnte und wollte diese auf das neue Framework portieren. Leider musste
  26 er das aber aus gesundheitlichen Gruenden aufgeben. Vor kurzem habe ich
  27 mir die Muehe gemacht seinen alten Code auf Gradle zu portieren und
  28 die verwendeten Binaerbibliotheken zu ersetzen bzw. direkt aus jCenter
  29 zu holen. Das Ergebnis [1] ist jetzt auch in FDroid [2] zu finden, auch
  30 wenn die UI grottig ist und nicht unter allen Umstaenden funktioniert.
  31 Mir war es nur wichtig, dass wir endlich einen freien Druckerdienst fuer
  32 Android haben und damit eine der letzten grossen Luecken schliessen.
  33 Fuer mich ist damit ein Meilenstein erreicht:
  34
  35 Zum ersten Mal decken wir damit nahezu alle Bereiche und Standards ab,
  36 die ein reiner "Client" nach aussen hin abdecken sollte:
  37
  38 * Mail (IMAP/SMTP/POP) [3]
  39 * Kurznachrichten (TEL/XMPP) [4][5]
  40 * Browser (HTTP) [6][7]
  41 * Kontakte und Kalender (CalDAV/CardDAV) [8][9]
  42 * Zeit (NTP) [10]
  43 * Drucken (IPP/HTTP) [11]
  44 * Feeds (RSS/ATOM/FEED/HTTP) [12]
  45 * Dateizugriff (WebDAV/FILE/HTTP/SCP/SFTP) [13][14]
  46 * Shell (SSH) [15]
  47 * Telefonie (TEL/SIP) [16]
  48 * VCS (GIT) [17]
  49
  50 Nicht ganz zur selben Kategorie, aber fuer mich ebenfalls zu diesem
  51 Milestone gehoerend sind Wetter- und Geodaten. Wo letzteres nicht
  52 ueber passives GPS/GLONASS verfuegbar ist, muss es ueber CellID und
  53 bekannte Accesspoints geschehen. Prinzipiell ist das in Android
  54 schon standardmaessig integriert, mit dem UnifiedNlp [18] des microG-
  55 Projekts gibt es aber die Moeglichkeit die jeweiligen Anbieter per
  56 Plugin auszutauschen, also auch eine alternative oder gar freie
  57 Datenbank dafuer zu nutzen -- ggf. mit Offline-Daten. Wetterdaten
  58 sind idR zwar nicht ins System integriert, sondern nur ueber Apps
  59 verfuegbar, doch nutzen die meisten Geraete die vorinstallierten
  60 Google-Anwendungen dafuer. Bei freien Wetterapps [19] kann meist
  61 auch eine freie Datenquelle gewaehlt werden.
  62
  63 Damit kratzen wir dann auch schon an meinem zweiten Meilenstein fuer
  64 Android: Lokale Anwendungen. Darunter fallen neben nuetzlichen Tools,
  65 die komplett ohne Daten auskommen, auch Anwendungen, die auf lokalen
  66 Daten arbeiten muessen. Waehrend viele (aeltere?) Anwendungen fuer
  67 Linux explizit zwischen der Verarbeitung und der Bereitstellung von
  68 Daten trennen -- ein MUA arbeitet auf lokalen Mails, ob diese per POP3
  69 oder IMAP oder XYZ eingeliefert werden und welche Programme dafuer
  70 zustaendig sind, ist ihm egal --, es also mehrere Tools gibt, die
  71 zusammenarbeiten, hat sich bei Android der monolithische Ansatz fast
  72 komplett durchgesetzt. Die positiven Ausnahmen sind vorgefertigte
  73 Schnittstellen wie SMS, Anruflog, Kalender und Kontaktdaten. Manchmal
  74 wuenschte ich mir, dass Google von vorherein bei Android auch an ein
  75 Sotrage fuer Mail gedacht haben sollte... aber da ich weiss, wie lax
  76 die Leute mit Berechtigungen umgehen, ist ein app-spezifischer Speicher
  77 evtl. doch besser. Wie dem auch sei, noch bin ich mir nicht sicher, ob
  78 es eine direkte Folge oder der Ausloeser ist, aber bei vielen Apps ist
  79 eine rein lokale Nutzung nicht vorgesehen. Nutzen mehrere Apps die
  80 selben Daten, muss ich die Accountdaten in jeder App einzeln angeben
  81 oder alle Entwickler dazu bringen eine noch zu schaffende gemeinsame
  82 Schnittstelle zu nutzen.
  83
  84 Prinzipiell denke ich, dass wir mit freien Anwendungen eine rudimentaere
  85 offline Nutzung ermoeglichen koennen. An vielen Ecken und Enden fehlt es
  86 jedoch noch an wenigen, aber wichtigen Kleinigkeiten. Das ist aber
  87 kein Problem der freien Software, sondern ist dem generellen "Mindset"
  88 der meisten Android-Entwickler geschuldet: Android ist per Design
  89 ein Dumbphone in dem Sinne, dass es konstruiert wurde, um sich mit
  90 anderen Diensten zu verbinden, nicht um offline zu arbeiten.
  91
  92 Meine beiden letzten Meilensteine habe ich schon nahezu aufgegeben:
  93 Server-Software und freie Treiber/Firmware. Waehrend die meisten bei
  94 letzteren wenigstens noch den Sinn sehen, interessiert sich eigentlich
  95 kaum jemand fuer Server-Software. Ich finde das ist ein fataler Fehler.
  96 Ja, Android ist als Client konstruiert. Aber es geht auch gar nicht
  97 darum, Android jetzt in Racks gepackt in Rechenzentren zu karren. Nein,
  98 es geht eher um kleine Serverdienste fuer den Heimgebrauch, z.B. ein
  99 abgespeckter IMAP-Server, der den fehlenden LocalStorage fuer Mails
 100 bereitstellt, ohne dass die eigentlichen "Apps" angepasst werden
 101 muessen. Ausserdem ist klar, dass eine Versteifung auf "Client" ein
 102 fataler Fehler sein wird, wenn die dazugehoerigen (proprietaeren)
 103 Serverdienste wegfallen... oder gar das zur Kommunikation noetige
 104 Netz ausfaellt, bewusst manipuliert (Drosselung, Sperren, DPI..)
 105 wird und generell nicht mehr vertrauenswuerdig ist: Ein Szenario
 106 das gerade durch die Enthuellungen von Snowden immer greifbar wird
 107 und meinem Tenor entspricht: Wir bauen unsere Zukunft auf eine
 108 ziemlich bruechige Technologie, "always on" ist noch in weiter Ferne
 109 (und evtl. auch gar nicht wuenschenswert). Das GuardianProject [20]
 110 setzt daher vermehrt auf Pico- und Peer2Peer-Netze: Der FDroid-Client
 111 hat dank Ihrer Hilfe eine Option, um sich selbst zum Server zu machen
 112 und lokal installierte Anwendungen fuer FDroid-Nutzer im selben Netz
 113 freizugeben [21] -- die FDroid-APK selbst kann per Bluetooth verteilt
 114 werden. Ausserdem entwickeln sie neben einem XMPP-Client auch einen
 115 reinen Bluetooth-Broadcast-Chat [22]. Bei der ganzen Debatte um Ver-
 116 schluesselung wurde leider vergessen, dass es Situationen gibt,
 117 in der man nicht Verschluesseln will, sondern jeden potentiellen
 118 Nutzer erreichen will. Ein kaputtes Netz oder ein unter fremder
 119 Kontrolle stehender Service darf uns nicht vom Kommunizieren abhalten.
 120
 121
 122 [0]  http://mobd.jonbanjo.com/jfcupsprintservice/
 123 [1]  https://github.com/krt16s/jfcups-service
 124 [2]  https://f-droid.org/forums/topic/cups-print-app/
 125 [3]  https://f-droid.org/repository/browse/?fdid=com.fsck.k9
 126 [4]  https://f-droid.org/repository/browse/?fdid=eu.siacs.conversations
 127 [5]  https://f-droid.org/repository/browse/?fdid=org.smssecure.smssecure
 128 [6]  https://f-droid.org/repository/browse/?fdid=org.mozilla.fennec_fdroid
 129 [7]  https://f-droid.org/repository/browse/?fdid=acr.browser.lightning
 130 [8]  https://f-droid.org/repository/browse/?fdid=at.bitfire.davdroid
 131 [9]  https://f-droid.org/repository/browse/?fdid=org.dmfs.tasks
 132 [10] https://f-droid.org/repository/browse/?fdid=org.ntpsync
 133 [11] https://f-droid.org/repository/browse/?fdid=com.jonbanjo.cupsprintservice
 134 [12] https://f-droid.org/repository/browse/?fdid=net.etuldan.sparss.floss
 135 [13] https://f-droid.org/repository/browse/?fdid=com.owncloud.android
 136 [14] https://f-droid.org/repository/browse/?fdid=com.ghostsq.commander
 137 [15] https://f-droid.org/repository/browse/?fdid=org.connectbot
 138 [16] https://f-droid.org/repository/browse/?fdid=org.lumicall.android
 139 [17] https://f-droid.org/repository/browse/?fdid=me.sheimi.sgit
 140 [18] https://f-droid.org/repository/browse/?fdid=com.google.android.gms
 141 [19] https://f-droid.org/repository/browse/?fdid=ru.gelin.android.weather.notification
 142 [20] https://guardianproject.info/
 143 [21] https://dev.guardianproject.info/projects/bazaar/wiki
 144 [22] https://github.com/n8fr8/gilgamesh/