diff --git a/20220620/nit-20220620.txt b/20220620/nit-20220620.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f17c1cab426a86359004d7b4dbbf4faecb6b9f45
--- /dev/null
+++ b/20220620/nit-20220620.txt
@@ -0,0 +1,337 @@
+GNU-Taler, 13.06.2022, 14:37:43
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Quelle: https://nlnet.nl/project/GNUTaler/
+ - anonym wie Bargeld
+ - erschwert Geldwäsche
+
+Quelle: https://www.heise.de/news/Projekt-GNU-Taler-Das-quelloffene-Bargeld-4892826.html
+ - zentrale Instanzen: Exchange
+ - Nutzer anonym
+ - Händler nachverfolgbar
+
+Funktionsweise:
+
+ - Bei der Nutzung signiert man die "Überweisung" mit einem privaten Schlüssel
+ und schickt sie an die Exchange.
+ - Dieser prüft die Gültigkeit der Überweisung und führt sie aus.
+ - Peer-to-Peer-Zahlungen: noch nicht möglich, aber geplant
+
+Behauptung: Zahlung kann anonym erfolgen; Umtausch in klassische Währung ist nachvollziehbar
+
+ - Umtausch in klassische Währung:
+ geregelt durch die Exchange, typischerweise eine klassische Bank
+
+ - Anonyme Zahlung?
+
+Verfahren: blinde Signaturen
+
+ - Quelle: https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
+ "fundamentally new kind of cryptography"
+
+ - Jede Münze hat ein Schlüsselpaar.
+ - Die Exchange kennt diese Schlüsselpaare nicht.
+
+ - Grundidee: Die Exchange unterschreibt etwas, ohne zu wissen, was sie da unterschreibt.
+
+ - Analogie: Unterschrift auf unbekanntem Dokument
+ mittels Durchschlagpapier in verschlossenem Briefumschlag
+
+ - Anwendung auf eine geheime Wahl auf Entfernung,
+ bei der sichergestellt wird, daß jede Stimme gezählt wird
+ --> Trustee (Wahlleiter*in) darf Stimmen zählen,
+ aber nicht wissen, von wem diese jeweils sind.
+
+ - Stimmzettel in anonymem, inneren Umschlag, den man blind unterschreiben kann
+ --> Man kann per Blind-Unterschrift bestätigen,
+ daß der Inhalt des Umschlags für die Wahl zulässig ist.
+ "In diesem Umschlag befindet sich ein gültiger Stimmzettel."
+
+ - Der anonyme, innere Umschlag wird in einem nicht-anonymen, äußeren Umschlag
+ an Trustee versendet.
+ Trustee unterschreibt den inneren Umschlag (und damit blind den Stimmzettel)
+ und sendet diesen in einem neuen äußeren Umschlag zurück.
+ --> Der innere Umschlag wurde nicht geöffnet,
+ dessen Inhalt aber von Trustee unterschrieben.
+ Damit bestätigt Trustee den Willen von Elector, ohne diesen zu kennen.
+
+ - Elector kann den von Trustee unterschriebenen Stimmzettel nun anonym einreichen.
+ --> Sinn der Aktion: Nur Elector darf den inneren Umschlag öffnen.
+
+ - Trustee kann die - anonymen und unterschriebenen - Stimmzettel nun veröffentlichen.
+
+Funktionsweise:
+
+ * Wir haben:
+
+ - ein Schlüsselpaar s (öffentlich), s' (geheim),
+
+ - eine "kommutierende Funktion" c mit Inversem c', die sich "mit der Signatur verträgt",
+ d.h. c'(s'(c(x))) = s'(x) für ein bestimmtes, aber unbekanntes x.
+ --> Wir wählen ein x und und lassen es mit s' signieren.
+ Wir ordnen dem x ein c(x) zu und lassen dieses ebenfalls mit s' signieren.
+ Dann ordnet c' diesem s'(c(x)) wieder die Signatur s'(x) zuordnen.
+
+ * Vorgehensweise
+
+ - Provider (= Elector = Payer) wählt ein zufälliges x
+ und übergibt c(x) an Signer (= Trustee = Bank).
+
+ - Signer unterschreibt c(x) --> s'(c(x)).
+
+ - Provider erzeugt daraus s'(x) = c'(c(s'(x)))
+ --> Damit hat Provider eine Signatur von Signer für x, ohne daß Provider x kennt.
+
+Quelle: https://en.wikipedia.org/wiki/Blind_signature
+
+ * Vermutung: Spezialfall von homomorpher Verschlüsselung
+
+ - Sei c eine Verschlüsselung und c' eine Entschlüsselung.
+
+ - Wir haben mathematische Botschaften a und b.
+
+ - verschlüsselt: c(a) bzw. c(b)
+
+ - Homomorphe Verschlüsselung bedeutet: c(a+b) = c(a) + c(b)
+ (und/oder entsprechend für andere Rechenarten)
+
+ * Hier: Verschlüsselung ist homomorph zu RSA
+
+ - Nachricht m, RSA-verschlüsselt r(m), wieder entschlüsselt r'(r(m))
+
+ - dazu homomorphe Verschlüsselung c: c'(r(c(m))) = r(m)
+ --> Dies ist nichttrivial!
+
+ - Wie dies für RSA funktioniert:
+ https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures
+
+ - Wir ermitteln eine Zufallszahl r
+ und verschlüsseln sie mit dem öffentlichen Schlüssel: r^e
+
+ - Die Bank signiert das Produkt m' = m · r^e unserer Überweisung m mit r^e.
+
+ - Mit unserem geheimen Schlüssel d und der geheimen Zufallszahl r
+ können wir daraus eine gültige Signatur für unsere Überweisung m extrahieren.
+
+ * Anwendung auf Zahlungssystem
+
+ - "(3) Bank signs note ... and debits payer's account."
+ --> Die Bank (= Signer = Trustee) kennt x also doch???
+
+ Vermutung:
+
+ - Payer nennt Betrag
+ und erzeugt eine Banknote über diesen Betrag.
+
+ - Die Bank belastet das Konto mit dem gewünschten Betrag
+ und bestätigt, daß die Banknote für diesen Betrag gültig ist.
+
+ - Payer gibt die Banknote an Payee weiter.
+
+ - Payee gibt die Banknote der eigenen Bank.
+ Diese prüft die Signatur der anderen Bank,
+ prüft, ob diese Banknote evtl. bereits anderweitig eingelöst wurde,
+ und schreibt, sofern alles in Ordnung ist, Payee den Betrag gut.
+
+ --> Damit findet eine Überweisung von Payer an Payee statt,
+ ohne daß die beteiligten Banken die Transaktion kennen.
+
+ Nachteile:
+
+ - Man benötigt eine immer länger werdende Liste von bereits verbrauchten Banknoten.
+
+ - Peer-to-Peer-Zahlungen sind auf diese Weise (noch) nicht möglich.
+
+ - evtl. Deanonymisierung möglich durch Analyse der Metadaten
+ --> Problem evtl. lösbar durch Banknoten mit festen Beträgen (wie Geldscheine)
+
+Themen für heute
+~~~~~~~~~~~~~~~~
+Begrenzte Ressourcen sparen durch Software
+ - Wie muß man programmieren, damit die Software
+ möglichst wenig Strom verbraucht?
+ - Wie kann man die in Rechenzentren vorhandene Rechenleistung
+ möglichst effizient nutzen?
+ - Beispiel: virtuelle Rechner, Container, Cloud
+
+--> "Hardware-Nachhaltigkeit", durch Software realisiert
+
+Smartphones: Bestandsaufnahme
+ - Wie hoch kann der Anteil an freier Software sein
+ (auf Standard-Smartphones bzw. auf speziellen, freien Smartphones)?
+ - Wieviel digitale Souveränität kann man gewinnen?
+
+Bitte schon mal recherchieren!
+
+Ressourcen sparen durch Software: Virtualisierung, 20.06.2022, 15:34:52
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ .---------------.
+ | Anwendungen |
+ .-------------------.
+ | virtuelle Rechner |
+ .-----------------------.
+ | Hypervisor-OS |
+ .---------------------------.
+ | physikalische Hardware |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Auslastung der vorhandenen Hardware verbessern:
+ - physikalische Hardware nicht immer voll ausgelastet
+ - insgesamt am effizientesten: immer voll ausgelastet
+ (Ansonsten verbraucht der nicht ausgelastete Teil unnötigen Strom.)
+ - durch Verteilung auf virtuelle Rechner ist volle Auslastung erreichbar
+ - Dadurch kann man die Anzahl der benötigten Rechner minimieren.
+
+Beispiel: Proxmox
+ - einheitliche Verwaltung für Container (z.B. Docker)
+ und virtuelle Maschinen (z.B. KVM, QEMU)
+ - Container: Gastsystem verwendet den Kernel des Gastgebersystems mit
+ (nicht immer möglich)
+ - Virtuelle Maschine: Gastgebersystem emuliert Hardware für Gastsystem
+ (langsamer)
+
+Wie hilft dies bei der Optimierung der Auslastung?
+
+Beispiel: BigBlueButton
+ - BigBlueButton hatte früher einen einzelnen zentralen Thread, hatte also
+ 1 CPU als "Nadelöhr". In dem Fall war es effizienter, mehrere BBB-Instanzen
+ in virtuellen Umgebungen laufen zu lassen, z.B. in Xen.
+ --> Virtualisierung erlaubt es, den Server effizienter auszulasten.
+ - Ein Load-Balancer kann die Last automatisch zwischen diesen verschiedenen
+ virtuellen Umgebungen verteilen. (Z.B. verteilt Bochum seine BBB-Instanzen
+ zwischen Bochum und Heiligenhaus.)
+ - Durch effizientere Programmierung verbraucht BBB inzwischen weniger Ressourcen
+ als früher.
+
+LXC und Docker sind zwei verschiedene Oberflächen (Sammlung von Kommandos,
+ggf. GUI), um unter einem Linux-Kernel Container zu realisieren.
+Proxmox unterstützt Docker nicht nativ, aber man kann Docker innerhalb von
+LXC und innerhalb von virtuellen Maschinen nutzen.
+Dies ist z.B. dann sinnvoll, wenn Software in Gestalt von Docker-Containern
+zur Verfügung steht.
+Diese Schachtelung von Containern verbraucht zusätzlichen Speicherplatz,
+aber vermutlich keine zusätzliche Rechenleistung.
+
+Schnittstelle für Backups
+ermöglicht, virtuelle "Hardware" in einem Backup zu speichern
+Siehe: https://g-n-u.de/images/G-N-U-Karikatur-Virtualisierung.png
+--> Unabhängigkeit von konkreter Hardware (einschließlich evtl. nicht mehr
+ erhältlicher Ersatzteile)
+
+Cloud, 20.06.2022, 16:28:24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Cloud: Landschaft für Virtualisierung, von einem speziellen Anbieter
+(extern oder intern) betrieben
+ - kann helfen, Ressourcen zu sparen (siehe oben)
+ - mögliches Problem: Verlust der Datenautonomie
+ --> Dasselbe Problem läßt sich auch für Root-Server nicht ausschließen.
+
+Cloud-Nutzung mit Smartphones?
+ - Je nach Benutzung des Smartphones liegen viele Daten nicht auf dem
+ Smartphone selbst, sondern in der Cloud. Entsprechendes gilt für
+ Office 365 auf "normalen" Rechnern.
+ - Bei Installation von Apps aus dem Google-App-Store erfährt Google,
+ wer sich was installiert hat und evtl noch mehr.
+ - Push-Nachrichten: Dienstebetreiber registrieren sich bei Google bzw. Apple.
+ Je nach App erfährt Google/Apple nur, daß eine Nachricht vorliegt
+ oder auch Metadaten und evtl. den Inhalt.
+ --> Man hängt trotzdem immer an der "Nabelschnur" von Google/Apple.
+ - Unified Push: https://unifiedpush.org/
+ dezentraler Dienst für den Empfang von Push-Nachrichten,
+ nur von speziellen Apps unterstützt
+
+Push-Nachrichten: Dauerhafte Verbindung mit dem Push-Server
+ - Wenn jeder Diensteanbieter einen eigenen Push-Server betreibt,
+ muß jede App eine eigene Verbindung aufbauen.
+--> Zentraler Push-Server ist sinnvoll.
+
+Smartphones: Bestandsaufnahme, 20.06.2022, 16:47:07
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Wie hoch kann der Anteil an freier Software sein
+ (auf Standard-Smartphones bzw. auf speziellen, freien Smartphones)?
+
+ - Betriebssystem: Android
+ (Linux-Distribution für Smartphones)
+ - Android-Entwickler versuchen, die Differenz zwischen Android und dem
+ offiziellen Linux-Kernel, möglichst gering zu halten.
+ - Jede App bekommt eine eigene User-ID.
+ - Zertifiziertes installiertes Android:
+ - keine root-Shell
+ - grafische Oberfläche ("Launcher"?), keine Text-Shell
+ - bestimmte, proprietäre Google-Apps vorinstalliert, z.B. PlayStore
+ - Text-Shell nachinstallieren: kein privilegierter Prozeß,
+ kann nur auf öffentliche Daten zugreifen
+ - "secure boot" ist aktiv --> Man kann keinen eigenen Kernel starten,
+ um evtl. doch auf private App-Daten zuzugreifen.
+ Man kann dies deaktivieren, dann werden jedoch alle Benutzerdaten
+ gelöscht.
+ - Bootloader: 3 Modi
+ - fest installierter Bootloader, kann Android neu installieren
+ - Recovery Mode: kann Android reparieren oder neu installieren,
+ nicht fest installiert, sondern auf Flash, daher austauschbar,
+ kann dann auch root-Shell enthalten
+ - Standard-Modus: Android startet
+ - Ge"root"etes Android:
+ - root-Shell vorhanden
+ - Apps können auch root-Rechte haben.
+
+ - AOSP - Android Open Source Project
+ - liegt grundsätzlich offen: https://source.android.com/
+ - Chipsatz-Hersteller ergänzen hier ihre Treiber.
+ Diese sind meistens proprietär, zumindest der User-Space-Teil.
+ (Der Kernel-Space-Teil müßte eigentlich immer offenliegen,
+ tut dies aber nicht immer.)
+ --> Ein handelsübliches Smartphone enthält eigentlich immer
+ proprietäre Treiber.
+ Je nach Gerät gibt es bestimmte Hardware-Treiber
+ nur als unfreie Software.
+ - Zusätzlich insallieren die Smartphone-Hersteller ihre eigenen
+ proprietären Apps vor.
+
+ - Betriebssystem: LineageOS
+ (Nachfolger von CyanogenMod, Projekt von Freiwilligen)
+ - Anpassung von AOSP an aktuelle Smartphone-Modelle
+ - verwendet proprietäre Treiber
+ - weitgehend kompatibel zu Android
+ - keine Apps vorinstalliert
+ - Updates unabhängig vom Hersteller
+
+ - Freie Smartpones: Librem 5, Pinephone
+ - Übersicht: https://en.wikipedia.org/wiki/Comparison_of_open-source_mobile_phones
+ - Die Haupt-CPU führt keinen proprietären Code aus.
+ - Pinephone: proprietäre Firmware für WiFi/Bluetooth
+ liegt in /lib/firmware, wird von Modem ausgeführt
+ - Librem 5: proprietäre Firmware für DRAM-Initialisierung
+ liegt in separatem Speicher, wird von separatem µC ausgeführt
+ - Auf dem Modem läuft proprietäre Software.
+ Dies ist rechtlich auch nicht anders möglich.
+ - Auf beiden Systemen läuft Standard-Linux,
+ normalerweise mit einer Oberfläche, die für den Gebrauch
+ als Smartphone angepaßt ist (z.B. Phosh).
+ - Es existiert ein Android-basiertes System für das Pinephone,
+ direkt auf AOSP basierend, ohne LineageOS:
+ https://github.com/GloDroid/glodroid_manifest
+ - Es existiert ein Android-Emulator für Linux mit Wayland: waydroid
+ Damit könnte man Android-Apps auf freien Smartphones unter Linux ausführen.
+ (Laufendes Projekt: Corona-Warn-App unter Linux)
+ - Die Treiber enthalten weiterhin proprietäre BLOBs:
+ Laut https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/
+ folgendes: WiFi+Bluetooth firmware, optionale Autofokus-Firmware für
+ die rückseitige Kamera und das Betriebssystem auf dem Quectel EG25-G
+ LTE Modem ist auch unfrei. Wifi benutzt SDIO, Bluetooth UART zur
+ Kommunikation.
+ Für das Modem gibt es inzwischen eine Firmware, die in großen Teilen frei ist:
+ https://gnulinux.ch/hacker-entwickeln-open-source-firmware-fuer-das-pinephone-modem
+ (der Teil, der auf dessen CPU läuft, die Software für den DSP, der
+ direkt mit dem Mobilfunknetz spricht, ist aber unfrei). Laut gerade
+ genanntem Artikel ist es aber rechtlich nicht zulässig, diese Firmware
+ vorzuinstallieren, im Zweifel geschieht also das Einstecken einer
+ SIM-Karte danach auf eigene Gefahr.
+ - Kein DMA-artiger Zugriff der proprietären Module auf den Hauptspeicher möglich.
+ (Bei Android: Modem spricht direkt mit Lautsprecher und Mikrofon.)
+ --> enormer Gewinn an Kontrolle über die Hardware
+
+ * Wieviel digitale Souveränität kann man gewinnen?
+ - Auf Push-Server achten!
+ - Auf proprietäre Treiber achten!
+ - Auf vorinstallierte Apps achten!
+ - Freie Smartphones nutzen.