Some plans use shortcodes instead of the teacher's names. For convenience, these could be replaced with the actual name locally. The user should enter the list themselves. Users should be able to share their lists with each other.
Some plans use shortcodes instead of the teacher's names. For convenience, these could be replaced with the actual name locally. The user should enter the list themselves. Users should be able to share their lists with each other.
Everybody need to hardcode it (bad option; not user-friendly)
We make an option in the settings menu where everybody need to enter the shortcodes and the ful name. (nasty)
We make (host) an List per scool or login data and everybody can fetch it and dont need to do anything (great)
Option 3 and 4 mixed (best)
If we host such a List there are some Problems:
Privacy: Are we allowed to host such stuff?
Who makes these Lists? Some users of dsbdirekt would need to publish their list. Then we have the problem: Are these information correct? How to prove it?
Would the users need to enter an password to get the list or is ist public? If not we still have the option which http basic auth on an other server and if these are correct, the list is getting shown. Great idea, we would need a server (not the problem), but we would need to store login data. Thr other option is we make an git repo where json files are storen with the name (= lohin id) and then they are encrypted and the dsb password is needed to decrypt it.
Are there more?
The best thing would to store the data in an database and show it like a table to enable mass inserting/editing
How would you do it?
So. We have some options for this:
1. We dont do this (worst option)
2. Everybody need to hardcode it (bad option; not user-friendly)
3. We make an option in the settings menu where everybody need to enter the shortcodes and the ful name. (nasty)
4. We make (host) an List per scool or login data and everybody can fetch it and dont need to do anything (great)
5. Option 3 and 4 mixed (best)
If we host such a List there are some Problems:
1. Privacy: Are we allowed to host such stuff?
2. Who makes these Lists? Some users of dsbdirekt would need to publish their list. Then we have the problem: Are these information correct? How to prove it?
3. Would the users need to enter an password to get the list or is ist public? If not we still have the option which http basic auth on an other server and if these are correct, the list is getting shown. Great idea, we would need a server (not the problem), but we would need to store login data. Thr other option is we make an git repo where json files are storen with the name (= lohin id) and then they are encrypted and the dsb password is needed to decrypt it.
4. Are there more?
The best thing would to store the data in an database and show it like a table to enable mass inserting/editing
How would you do it?
I see two ways of doing this. Both require there to be a screen where one can enter shortcodes and names if one wishes to do so.
Import / Export
Users can share their list with each other.
Drawback: no update mechanism.
I guess this could also work without a special screen, expecting users to create the file manually first before being able to import it.
Hosted
I imagined this is possible without the server knowing the contents of the list the following way:
A wants to upload a list. A's client generates a password, encrypts the list with it and pushes it to the server. The server gives A a secret update permission token. A's client generates a matrix barcode (2d barcode / QR code) for A's classmates to scan. B scans A's matrix barcode. B's client downloads the associated file from the server, which, considering it's encrypted, doesn't require authorization besides knowing the exact filename (which should be long and randomly generated by the server), and decrypts it using the password it has obtained from the matrix barcode.
Updates: A wants to update list. A's client can push the file by presenting the update permission token to the server. B's client will sporadically / occasionally / sometimes / at every launch ask the server what the file's last changed date is, and if it's newer, of course downloads an decrypts the updated list.
Drawback: server required. Server code required. Upload code complicated.
I see two ways of doing this. Both require there to be a screen where one can enter shortcodes and names if one wishes to do so.
##### Import / Export
Users can share their list with each other.
Drawback: no update mechanism.
I guess this could also work without a special screen, expecting users to create the file manually first before being able to import it.
##### Hosted
I imagined this is possible without the server knowing the contents of the list the following way:
A wants to upload a list. A's client generates a password, encrypts the list with it and pushes it to the server. The server gives A a secret update permission token. A's client generates a matrix barcode (2d barcode / QR code) for A's classmates to scan. B scans A's matrix barcode. B's client downloads the associated file from the server, which, considering it's encrypted, doesn't require authorization besides knowing the exact filename (which should be long and randomly generated by the server), and decrypts it using the password it has obtained from the matrix barcode.
Updates: A wants to update list. A's client can push the file by presenting the update permission token to the server. B's client will sporadically / occasionally / sometimes / at every launch ask the server what the file's last changed date is, and if it's newer, of course downloads an decrypts the updated list.
Drawback: server required. Server code required. Upload code complicated.
Das mit dem Importieren/Exportieren ist relativ einfach umsetzbar. In die App alle reinschreiben, exportieren als Datei, versenden, importieren. Kein Großes Ding.
Das mit dem Server wäre schon aufwendiger. Wir könnten eine 2. Git Repository machen, in der wir alle Dateien hosten. Dabei wäre der Nachteil, dass man das Aufwendig über Pull Requests machen müsste und bei jedem Update,.....
Die 2. Möglichkeit wäre über einen Server. Dabei ist der Server nicht das Problem, ich könnte genug Resourcen (auch verteil auf mehreren Servern) zur Verfügung stellen. Speicherplatz, Traffic, Sicherheit,... Alles gewährt. Dabei bin ich auch bereit PhP, Java,... alles zu Hosten. Selbstverständlich Non-Profit(Mache das schon lange, da ich früher auch Projekte hatte und mir keiner einen Server/minimale Resourcen zur Verfügung gestellt hat.)
Dabei finde ich das mit den QR Codes ein bisschen aufwendig. Man müsste die Austauschen,...Alles nicht so toll. Wäre aber definitiv eine Idee. Ich würde eher eine Datei machen, die gehasht ist mit der ID (im JSON Format,... egal). Dort dann verschlüsselt mit dem Passwort (oder eine Kombi aus Benutzername und Passwort). So würde der Server nichts speichern (zumindest im Klartext). Das ganze könnte man auch nicht wirklich auslesen (es sei denn mit dem Zugangsdaten).
Das Problem an der Sache ist: Wie machen wir das, wenn jemand einem Fehler passiert ist oder die Liste geupdated werden muss? Da müsste man das entweder persönlich per E-Mail regeln, oder ein "master" Passwort machen, wo man die Daten unkompliziert über ein Webinterface oder die APP hochladen kann.
Zu den Drawbacks: server required (gelöst), Server code (Würde ich machen, da bin ich deutlich besser als auf dem Client. Natürlich auch open Source). upload code complicated (Ja. Aber nur wenn wir QR Codes / Barcodes,... verwenden)
Das mit dem Importieren/Exportieren ist relativ einfach umsetzbar. In die App alle reinschreiben, exportieren als Datei, versenden, importieren. Kein Großes Ding.
Das mit dem Server wäre schon aufwendiger. Wir könnten eine 2. Git Repository machen, in der wir alle Dateien hosten. Dabei wäre der Nachteil, dass man das Aufwendig über Pull Requests machen müsste und bei jedem Update,.....
Die 2. Möglichkeit wäre über einen Server. Dabei ist der Server nicht das Problem, ich könnte genug Resourcen (auch verteil auf mehreren Servern) zur Verfügung stellen. Speicherplatz, Traffic, Sicherheit,... Alles gewährt. Dabei bin ich auch bereit PhP, Java,... alles zu Hosten. Selbstverständlich Non-Profit(Mache das schon lange, da ich früher auch Projekte hatte und mir keiner einen Server/minimale Resourcen zur Verfügung gestellt hat.)
Dabei finde ich das mit den QR Codes ein bisschen aufwendig. Man müsste die Austauschen,...Alles nicht so toll. Wäre aber definitiv eine Idee. Ich würde eher eine Datei machen, die gehasht ist mit der ID (im JSON Format,... egal). Dort dann verschlüsselt mit dem Passwort (oder eine Kombi aus Benutzername und Passwort). So würde der Server nichts speichern (zumindest im Klartext). Das ganze könnte man auch nicht wirklich auslesen (es sei denn mit dem Zugangsdaten).
Das Problem an der Sache ist: Wie machen wir das, wenn jemand einem Fehler passiert ist oder die Liste geupdated werden muss? Da müsste man das entweder persönlich per E-Mail regeln, oder ein "master" Passwort machen, wo man die Daten unkompliziert über ein Webinterface oder die APP hochladen kann.
Zu den Drawbacks: server required (gelöst), Server code (Würde ich machen, da bin ich deutlich besser als auf dem Client. Natürlich auch open Source). upload code complicated (Ja. Aber nur wenn wir QR Codes / Barcodes,... verwenden)
Ein git-Repository wäre doch auch auf einem Server ;) wäre aber deutlich suboptimal, wenn wir manuell Dateien "überprüfen" müssen, ohne Zugriff darauf zu haben.
Wie viel würde dich denn so ein Server kosten? Mir gefällt der aktuelle Zustand, dass das Projekt keine vergangenen, aktuellen, rekursiven oder vorhersehbare zukünftige Kosten hat, sehr. An welchem Standort solch ein Server stehen?
Bei den Matrix-Barcodes habe ich mir das so gedacht, weil ich persönlich jetzt keine Möglichkeit hätte, eine Datei übers Internet an andere alle Klassenkameraden zu verteilen.
Es ginge ja auch, neben scanbaren Codes zusätzlich noch Textnachrichten mit "Downloadcode" versenden zu können.
Updates werden vermutlich doch recht häufig entstehen. Da wir nicht die E-Mail-Adressen derer, die Dateien hochladen, haben wollen, und Änderungen auch nicht sichten können, oder überprüfen, ob sie überhaupt mit dem gleichen Schlüssel verschlüsselt wurden, muss das mit Update-Tokens erfolgen, die der Server generiert und die Client dann speichert, sodass (nur) mit der Installation, die die Datei ursprünglich hochgeladen hat, auch Updates gepusht werden können.
Dieser Update-Token / "Bearbeitungscode" ließe sich dann ebenfalls mit anderen Nutzern teilen, falls eins Nutzer irgendwann keine Lust mehr hat (oder die Schule verlässt).
Das wäre doch hübsche verständlich für Nutzer:
Neu Hochladen geht einfach so
Herunterladen mit Downloadcode
Überschreiben mit Bearbeitungscode
Der Downloadcode wäre dann vielleicht 15 Zeichen Dateiname, 25 Zeichen symmetrischer Schlüssel, A-Za-z0-9, das dürfte genug Entropie sein. Sähe vielleicht so aus:
xiB9y64eWPv1DKqRYknU1NMv5CNu6cRHE0vM7mMH
Und die Bearbeitungscodes 15 Zeichen Dateiname, 25 Zeichen Token:
xiB9y64eWPv1DKqZGKbkFLmhnXgjeRFNaTPZGKbk
Jetzt sehen die vorne ziemlich gleich aus und lassen sich auch gar nicht unterscheiden, da würde ich noch was zur Identifikation hinschreiben:
Was theoretisch noch gehen würde, wäre, Nutzer, die sich in ihren Plan im Onboarding-Screen ("Im DSB anmelden") einloggen, zu informieren, dass es auf dem Server dafür eine Datei gibt, wenn diese dort mit der ID verknüpft sind. Wenn diese Abfrage automatisch stattfindet, bekommt die App in F-Droid (wo builds im Augenblick im Übrigsten kaputt sind) das Tracking-Antifeature. Außerdem ist damit zu rechnen, dass jemand aus Spaß oder um es auszuprobieren für dessen Plan eine Datei hochlädt, auch wenn das gar nicht nötig ist.
Wenn solch eine Benachrichtigung nicht erfolgt, ist damit zu rechnen, dass ein Großteil der Nutzer niemals von der Funktion erfährt, und das wäre doch schade.
Es ginge auch, irgendwie zu erraten, ob vielleicht Kürzel im Plan verwendet werden, wenn die Lehrernamen alle die gleiche Länge haben. Das wäre wohlmöglich unzuverlässig.
Ein git-Repository wäre doch auch auf einem Server ;) wäre aber deutlich suboptimal, wenn wir manuell Dateien "überprüfen" müssen, ohne Zugriff darauf zu haben.
Wie viel würde dich denn so ein Server kosten? Mir gefällt der aktuelle Zustand, dass das Projekt keine vergangenen, aktuellen, rekursiven oder vorhersehbare zukünftige Kosten hat, sehr. An welchem Standort solch ein Server stehen?
---
Bei den Matrix-Barcodes habe ich mir das so gedacht, weil ich persönlich jetzt keine Möglichkeit hätte, eine Datei übers Internet an andere alle Klassenkameraden zu verteilen.
Es ginge ja auch, neben scanbaren Codes zusätzlich noch Textnachrichten mit "Downloadcode" versenden zu können.
Updates werden vermutlich doch recht häufig entstehen. Da wir nicht die E-Mail-Adressen derer, die Dateien hochladen, haben wollen, und Änderungen auch nicht sichten können, oder überprüfen, ob sie überhaupt mit dem gleichen Schlüssel verschlüsselt wurden, muss das mit Update-Tokens erfolgen, die der Server generiert und die Client dann speichert, sodass (nur) mit der Installation, die die Datei ursprünglich hochgeladen hat, auch Updates gepusht werden können.
Dieser Update-Token / "Bearbeitungscode" ließe sich dann ebenfalls mit anderen Nutzern teilen, falls eins Nutzer irgendwann keine Lust mehr hat (oder die Schule verlässt).
Das wäre doch hübsche verständlich für Nutzer:
* Neu Hochladen geht einfach so
* Herunterladen mit Downloadcode
* Überschreiben mit Bearbeitungscode
---
Der Downloadcode wäre dann vielleicht 15 Zeichen Dateiname, 25 Zeichen symmetrischer Schlüssel, A-Za-z0-9, das dürfte genug Entropie sein. Sähe vielleicht so aus:
xiB9y64eWPv1DKqRYknU1NMv5CNu6cRHE0vM7mMH
Und die Bearbeitungscodes 15 Zeichen Dateiname, 25 Zeichen Token:
xiB9y64eWPv1DKqZGKbkFLmhnXgjeRFNaTPZGKbk
Jetzt sehen die vorne ziemlich gleich aus und lassen sich auch gar nicht unterscheiden, da würde ich noch was zur Identifikation hinschreiben:
DOWN/149242/xiB9y64eWPv1DKqRYknU1NMv5CNu6cRHE0vM7mMH
EDIT/149242/xiB9y64eWPv1DKqZGKbkFLmhnXgjeRFNaTPZGKbk
Mit der ID kann die Client dann stupide überprüfen, ob man nicht aus Versehen einen Code für einen anderen Plan lädt.
Reihenfolge von Dateinamen und Token im zweiten String ändern, weil es immer noch so gleich aussieht:
DOWN/149242/xiB9y64eWPv1DKqRYknU1NMv5CNu6cRHE0vM7mMH
EDIT/149242/ZGKbkFLmhnXgjeRFNaTPZGKbkxiB9y64eWPv1DKq
Das dürfte auch klickbar sein (hier nicht, in einer Android-Messaging-App denke ich schon):
dsbdirect://DOWN/149242/xiB9y64eWPv1DKqRYknU1NMv5CNu6cRHE0vM7mMH
---
Was theoretisch noch gehen würde, wäre, Nutzer, die sich in ihren Plan im Onboarding-Screen ("Im DSB anmelden") einloggen, zu informieren, dass es auf dem Server dafür eine Datei gibt, wenn diese dort mit der ID verknüpft sind. Wenn diese Abfrage automatisch stattfindet, bekommt die App in F-Droid (wo builds im Augenblick im Übrigsten [kaputt sind](https://gitlab.com/fdroid/fdroiddata/issues/1812)) das `Tracking`-Antifeature. Außerdem ist damit zu rechnen, dass jemand aus Spaß oder um es auszuprobieren für dessen Plan eine Datei hochlädt, auch wenn das gar nicht nötig ist.
Wenn solch eine Benachrichtigung nicht erfolgt, ist damit zu rechnen, dass ein Großteil der Nutzer niemals von der Funktion erfährt, und das wäre doch schade.
Es ginge auch, irgendwie zu erraten, ob vielleicht Kürzel im Plan verwendet werden, wenn die Lehrernamen alle die gleiche Länge haben. Das wäre wohlmöglich unzuverlässig.
Mit dem Server: Ich habe meinen Server so oder so (für E-Mail; TeamSpeak; Webseiten; Testzwecke; CalDav Server; GitLab;...). Ich habe auf dem Server rund 150GB frei. Allerdings sollten immer um die 20GB frei sein, diese Limit würde aber durch ein paar Dateien nicht erreicht werden:). Traffic habe ich unlimited, bei einer relativ hohen Anbindung. Auch CPU/Ram mäßig habe ich genug frei. Das wäre wie gesagt nicht das Problem. Ich mache das ganze non Profit, da ich selber auch enorm von DSBDirekt profiere. Dieser ist bei der contabo GmbH in Nürnberg. Notfalls habe ich noch einen 2. Server in Frankfurt am Main und 2 weitere zu Hause. Ich zahle nicht sehr viel dafür. Sieh es als Sponsoring:). Es gefällt mir auch das DSBDirekt an "nichts" gebunden ist, wird sich aber auch nicht ändern, außer wenn man Kürzel synchronisieren will übers Netzwerk.
Zum Thema:
Ich habe ja verstanden, dass du in den Matrix Codes den Token zum herunterladen holen/verteilen willst. Aber alle Daten in so einen Code zu packen, ist natürlich auch eine Idee. Der Matrix Code darf (sollte?) 250 Zeichen nicht überschreiten. Bei uns hat die Liste von allen Lehrern (im Format: Kz=Lehrer Kürzel schon über 3500 Zeichen(mit gzip 2500). Damit würde diese Möglichkeit wahrscheinlich rausfallen.
Das mit den Schlüssel ist eine gute Idee. Den Bearbeitungsschlüssel würde ich allerdings beginnen lassen mit dem Downloadschlüssel und nur noch ein paar Zeichen dranhängen. Auch sind 15 Zeichen schon etwas viel, ich meine wir reden von einem Vertretungsplan:=) Da würden 8-10 Zeichen schon reichen. Auch könnte man (oder eher eigentlich nicht) ein eigenes Passwort machen. Das mit den Antifeature ist natürlich blöd, aber ich glaube viele interessiert das nicht. Auch wirbt DSB(Direkt) ja schon mit einem "Nicht freien Netzwerk".
Mit dem Server: Ich habe meinen Server so oder so (für E-Mail; TeamSpeak; Webseiten; Testzwecke; CalDav Server; GitLab;...). Ich habe auf dem Server rund 150GB frei. Allerdings sollten immer um die 20GB frei sein, diese Limit würde aber durch ein paar Dateien nicht erreicht werden:). Traffic habe ich unlimited, bei einer relativ hohen Anbindung. Auch CPU/Ram mäßig habe ich genug frei. Das wäre wie gesagt nicht das Problem. Ich mache das ganze non Profit, da ich selber auch enorm von DSBDirekt profiere. Dieser ist bei der contabo GmbH in Nürnberg. Notfalls habe ich noch einen 2. Server in Frankfurt am Main und 2 weitere zu Hause. Ich zahle nicht sehr viel dafür. Sieh es als Sponsoring:). Es gefällt mir auch das DSBDirekt an "nichts" gebunden ist, wird sich aber auch nicht ändern, außer wenn man Kürzel synchronisieren will übers Netzwerk.
Zum Thema:
Ich habe ja verstanden, dass du in den Matrix Codes den Token zum herunterladen holen/verteilen willst. Aber alle Daten in so einen Code zu packen, ist natürlich auch eine Idee. Der Matrix Code darf (sollte?) 250 Zeichen nicht überschreiten. Bei uns hat die Liste von allen Lehrern (im Format: ```Kz=Lehrer Kürzel``` schon über 3500 Zeichen(mit gzip 2500). Damit würde diese Möglichkeit wahrscheinlich rausfallen.
Das mit den Schlüssel ist eine gute Idee. Den Bearbeitungsschlüssel würde ich allerdings beginnen lassen mit dem Downloadschlüssel und nur noch ein paar Zeichen dranhängen. Auch sind 15 Zeichen schon etwas viel, ich meine wir reden von einem Vertretungsplan:=) Da würden 8-10 Zeichen schon reichen. Auch könnte man (oder eher eigentlich nicht) ein eigenes Passwort machen. Das mit den Antifeature ist natürlich blöd, aber ich glaube viele interessiert das nicht. Auch wirbt DSB(Direkt) ja schon mit einem "Nicht freien Netzwerk".
Schon mal super, wenn das für dich keine Kosten verursacht.
Ein eigenes Passwort lassen wir Nutzer lieber nicht festlegen. Natürlich können wir nicht überprüfen, ob Nutzer nicht vielleicht ihre Client so modifizieren, dass sie selbst das Passwort wählen können, aber da gehe ich mal nicht von aus, insbesondere da Downloadschlüssel ja eine fixe Länge haben müssen würden.
Bei einem Zeichenspektrum von 62 (A-z0-9) sind 25 Zeichen vielleicht schon mehr als ausreichend bei 6.5x10^44 Möglichkeiten. Wenn wir auf 20 Zeichen reduzieren, sind es immerhin noch 7x10^35. Das sollte ebenfalls genügen.
Habe ich ganz vergessen, dass man zum Bearbeiten natürlich auch den gleichen symmetrischen Schlüssel brauchen würde wie zum Entschlüsseln. Leider muss deswegen der Bearbeitungsschlüssel länger als der Downloadschlüssel sein :(
Und es stimmt, dass der Dateiname nicht so lang sein braucht, da man mit der verschlüsselten Datei ohne Schlüssel eh nichts anfangen kann. Deswegen sollten 6 Zeichen hier langen.
Der Uploadtoken muss aber länger als ein paar Zeichen sein. Immerhin könnte man versuchen, den zu erraten und zu missbrauchen. Daher mindestens so lang wie der symmetrische Schlüssel.
Also bin ich jetzt für 6 Zeichen Dateiname, 20 Zeichen Schlüssel, 20 Zeichen Token. Sähe so aus:
Nichtfreies Netzwerk liegt leider in der Natur der Sache. Tracking aber nicht. Und der zweite Nachteil, dass Menschen ohne Grund Listen ihren Plänen zuordnen könnten, besteht weiterhin.
Außerdem können wir gar nicht seitens des Servers überprüfen, ob Nutzer wirklich nur Listen für ihre eigenen Pläne hochladen würden, oder nicht auch für Schulen, die gar nicht ihre sind, ohne dass das Passwort des Plans mitgeschickt wird. Und das wäre ja nun wirklich schlecht.
Deswegen bin ich eher für eine lokale Erkennung, wann Kürzel im Einsatz sind, woraufhin Nutzer dann über die Möglichkeiten (selbst Liste erstellen, Klassenkameraden nach Downloadschlüssel fragen) informiert werden.
Ich meine, dass alle Listen, die auf den Server hochgeladen werden, unter CC0 ("Keine Rechte vorbehalten") lizenziert sein müssen. Dies dient letztendlich dem Schutz des Nutzers. Attribution wird schlecht realisierbar sein, und manche Nutzer werden sicher Derivative erstellen wollen.
Im Rahmen der "Schulfamilie", in dem wir uns befinden, wird wohl eher keiner rechtliche Schritte einleiten, um vor Gericht zu ermitteln, ob eine Auflistung der Lehrer und ihrer Kürzel etwas schützenswertes ist. Wer die Liste, die man erhält, wieder hochlädt, wird sich wohl kaum Gedanken darüber machen, ob das gestattet ist.
Dennoch halte ich es für sinnvoll, sicherzustellen, dass Derivative ohne Attribution auf rechtlicher Basis geschehen.
Schon mal super, wenn das für dich keine Kosten verursacht.
Ein eigenes Passwort lassen wir Nutzer lieber nicht festlegen. Natürlich können wir nicht überprüfen, ob Nutzer nicht vielleicht ihre Client so modifizieren, dass sie selbst das Passwort wählen können, aber da gehe ich mal nicht von aus, insbesondere da Downloadschlüssel ja eine fixe Länge haben müssen würden.
Bei einem Zeichenspektrum von 62 (A-z0-9) sind 25 Zeichen vielleicht schon mehr als ausreichend bei 6.5x10^44 Möglichkeiten. Wenn wir auf 20 Zeichen reduzieren, sind es immerhin noch 7x10^35. Das sollte ebenfalls genügen.
Habe ich ganz vergessen, dass man zum Bearbeiten natürlich auch den gleichen symmetrischen Schlüssel brauchen würde wie zum Entschlüsseln. Leider muss deswegen der Bearbeitungsschlüssel länger als der Downloadschlüssel sein :(
Und es stimmt, dass der Dateiname nicht so lang sein braucht, da man mit der verschlüsselten Datei ohne Schlüssel eh nichts anfangen kann. Deswegen sollten 6 Zeichen hier langen.
Der Uploadtoken muss aber länger als ein paar Zeichen sein. Immerhin könnte man versuchen, den zu erraten und zu missbrauchen. Daher mindestens so lang wie der symmetrische Schlüssel.
Also bin ich jetzt für 6 Zeichen Dateiname, 20 Zeichen Schlüssel, 20 Zeichen Token. Sähe so aus:
Format: (placeholders XXIDXX, FILNAM, XxxxSYMMETRICxKEYxxX and XxxxUPLOADxTOKENxxxX)
DOWN/XXIDXX/FILNAMxxxxSYMMETRICxKEYxxx
EDIT/XXIDXX/XxxxUPLOADxTOKENxxxXXxxxSYMMETRICxKEYxxXFILNAM
Beispiel:
DOWN/149242/thuubTO6sSf2eH5W8wxGEGqls9
EDIT/149242/Hax8CIZ6mW1HXpFCNB3FO6sSf2eH5W8wxGEGqls9thuubT
---
Nichtfreies Netzwerk liegt leider in der Natur der Sache. Tracking aber nicht. Und der zweite Nachteil, dass Menschen ohne Grund Listen ihren Plänen zuordnen könnten, besteht weiterhin.
Außerdem können wir gar nicht seitens des Servers überprüfen, ob Nutzer wirklich nur Listen für ihre eigenen Pläne hochladen würden, oder nicht auch für Schulen, die gar nicht ihre sind, ohne dass das Passwort des Plans mitgeschickt wird. Und das wäre ja nun wirklich schlecht.
Deswegen bin ich eher für eine lokale Erkennung, wann Kürzel im Einsatz sind, woraufhin Nutzer dann über die Möglichkeiten (selbst Liste erstellen, Klassenkameraden nach Downloadschlüssel fragen) informiert werden.
---
Ich meine, dass alle Listen, die auf den Server hochgeladen werden, unter CC0 ("Keine Rechte vorbehalten") lizenziert sein müssen. Dies dient letztendlich dem Schutz des Nutzers. Attribution wird schlecht realisierbar sein, und manche Nutzer werden sicher Derivative erstellen wollen.
Im Rahmen der "Schulfamilie", in dem wir uns befinden, wird wohl eher keiner rechtliche Schritte einleiten, um vor Gericht zu ermitteln, ob eine Auflistung der Lehrer und ihrer Kürzel etwas schützenswertes ist. Wer die Liste, die man erhält, wieder hochlädt, wird sich wohl kaum Gedanken darüber machen, ob das gestattet ist.
Dennoch halte ich es für sinnvoll, sicherzustellen, dass Derivative ohne Attribution auf rechtlicher Basis geschehen.
Bei uns an der Schule gelten wegen den Kürzeln folgende Regeln: 2 Stellig, wenn der Lehrer fest angestellt ist. 3 stellig bei Referendaren. Man könnte also direkt nach dem 1. Login schauen, ob ein gewisser Teil (Es gibt ja auch Lehrer, die einen dementsprechend kurzen Namen haben) 2 bzw. 3 stellig ist. Oder man fragt den Nutzer einfach. Wenn dieser einwilligt, könnte man an den Server kontaktieren und schauen ob (und wie viele) vorhanden sind. Wenn minimum eine Datei verfügbar ist, muss der User den Code eingeben um die Liste zu downloaden und zu entschlüsseln.
Ja. Der Server wird leider nicht überprüfen können, ob der Client wirklich Zugang hat. Allerdings muss dieser erst mal die Login ID bekommen und seinen Downloadtoken verbreiten. Auch wenn er den Token an andere verschickt, die an der Schule sind, dann müssen die Schüler den dort erstmal eintragen. Darin sehe ich kein Problem. Das könnten normale Leute allerdings gar nicht, da diese erst ein mal herausfinden müssten, wie das ganze geht.
Zu den nächsten Punkten: Ich weiß jetzt nicht genau, was Derivative und Attribution (in diesem Fall) ist. Allerdings vom Content her würde ich sagen, dass ich nicht wirklich rechtliche Konsequenzen sehe, da diese Listen ja im Prinzip anonym sind. Auch finde ich keinen Grund, warum man dem nachgehen sollte. Notfalls mal einen weitere Elternbrief, den man sich selber ausdrucken muss^^.
Und Danke fürs einbauen, das werde ich jetzt probieren, ob es läuft.
PS: Das mit dem Tracking finde ich persönlich nicht so schlimm. Allerdings solltest du das entscheiden, da dies dein Projekt ist. Wenn du sagst, dass du damit leben kannst, dann können wir das ganze implementieren. Wenn nicht, dann eben nicht:)
Das mit den Tokens und den Beispielen: TOP
Bei uns an der Schule gelten wegen den Kürzeln folgende Regeln: 2 Stellig, wenn der Lehrer fest angestellt ist. 3 stellig bei Referendaren. Man könnte also direkt nach dem 1. Login schauen, ob ein gewisser Teil (Es gibt ja auch Lehrer, die einen dementsprechend kurzen Namen haben) 2 bzw. 3 stellig ist. Oder man fragt den Nutzer einfach. Wenn dieser einwilligt, könnte man an den Server kontaktieren und schauen ob (und wie viele) vorhanden sind. Wenn minimum eine Datei verfügbar ist, muss der User den Code eingeben um die Liste zu downloaden und zu entschlüsseln.
Ja. Der Server wird leider nicht überprüfen können, ob der Client wirklich Zugang hat. Allerdings muss dieser erst mal die Login ID bekommen und seinen Downloadtoken verbreiten. Auch wenn er den Token an andere verschickt, die an der Schule sind, dann müssen die Schüler den dort erstmal eintragen. Darin sehe ich kein Problem. Das könnten normale Leute allerdings gar nicht, da diese erst ein mal herausfinden müssten, wie das ganze geht.
Zu den nächsten Punkten: Ich weiß jetzt nicht genau, was ```Derivative``` und ```Attribution``` (in diesem Fall) ist. Allerdings vom Content her würde ich sagen, dass ich nicht wirklich rechtliche Konsequenzen sehe, da diese Listen ja im Prinzip anonym sind. Auch finde ich keinen Grund, warum man dem nachgehen sollte. Notfalls mal einen weitere Elternbrief, den man sich selber ausdrucken muss^^.
Und Danke fürs einbauen, das werde ich jetzt probieren, ob es läuft.
PS: Das mit dem Tracking finde ich persönlich nicht so schlimm. Allerdings solltest du das entscheiden, da dies dein Projekt ist. Wenn du sagst, dass du damit leben kannst, dann können wir das ganze implementieren. Wenn nicht, dann eben nicht:)
Du fragtest mich, warum ich → U+2192 RIGHTWARDS ARROW verwende und nicht = als ASCI character. Da Android das ganze eh in UTF-8 encoded, ist das denke ich egal, und so sieht es hübscher aus (und ja, das verbraucht jetzt drei bytes anstatt von einem).
Mit der Lizenz habe ich mir das so gedacht, dass Nutzer einfach problemlos die Listen, die sie herunterladen, verändern (Derivative erstellen) und wieder hochladen können, ohne dass dabei Verpflichtungen entstehen (wie zum Beispiel, dass man schreiben muss, wer die Liste ursprünglich geschrieben hat, also Attribution, oder, was theoretisch (vielleicht?) der Fall wäre, wenn es keine Lizenz gäbe, dass man den Urheber fragen muss).
Autodetection wäre wirklich unzuverlässig, habe gerade einen Plan gefunden, der manchmal (?) vierstellige Kürzel verwendet. Und einen, wo alle vierstellig sind. Unsolicited den Server zu fragen, was er im Angebot hat, halte ich für blöd, und würde lieber den Onboarding-Prozess (#11), der ja im Moment aus zwei aneinandergereihten Dialogen besteht, was sich für mich recht fragil anfühlt, durch einen "Einrichtungsbildschrim" verbessern, wo man dann auch Shortcodes konfigurieren könnte.
Ob dieses Ganze mit dem Server überhaupt praktisch sinnvoll ist und genutzt werden wird, ist auch eine Frage. Aber eine nebensächliche.
Du fragtest mich, warum ich `→ U+2192 RIGHTWARDS ARROW` verwende und nicht `=` als ASCI character. Da Android das ganze eh in UTF-8 encoded, ist das denke ich egal, und so sieht es hübscher aus (und ja, das verbraucht jetzt drei bytes anstatt von einem).
Mit der Lizenz habe ich mir das so gedacht, dass Nutzer einfach problemlos die Listen, die sie herunterladen, verändern (Derivative erstellen) und wieder hochladen können, ohne dass dabei Verpflichtungen entstehen (wie zum Beispiel, dass man schreiben muss, wer die Liste ursprünglich geschrieben hat, also Attribution, oder, was *theoretisch* (vielleicht?) der Fall wäre, wenn es keine Lizenz gäbe, dass man den Urheber fragen muss).
Autodetection wäre wirklich unzuverlässig, habe gerade einen Plan gefunden, der manchmal (?) vierstellige Kürzel verwendet. Und einen, wo alle vierstellig sind. Unsolicited den Server zu fragen, was er im Angebot hat, halte ich für blöd, und würde lieber den Onboarding-Prozess (#11), der ja im Moment aus zwei aneinandergereihten Dialogen besteht, was sich für mich recht fragil anfühlt, durch einen "Einrichtungsbildschrim" verbessern, wo man dann auch Shortcodes konfigurieren könnte.
Ob dieses Ganze mit dem Server überhaupt praktisch sinnvoll ist und genutzt werden wird, ist auch eine Frage. Aber eine nebensächliche.
Seit #57 können shortcodes von eltern-portal.org importiert werden. Mit 2c7ff60b1c lassen sich shortcodes von Hand bearbeiten.
Ich schließe das mal und mache ein neues Issue für (gewöhnlichen) Import und Export.
Seit #57 können shortcodes von eltern-portal.org importiert werden. Mit 2c7ff60b1cc32e66cf4233c47e88cc57d08544da lassen sich shortcodes von Hand bearbeiten.
Ich schließe das mal und mache ein neues Issue für (gewöhnlichen) Import und Export.
Some plans use shortcodes instead of the teacher's names. For convenience, these could be replaced with the actual name locally. The user should enter the list themselves. Users should be able to share their lists with each other.
Yes :)
So. We have some options for this:
If we host such a List there are some Problems:
The best thing would to store the data in an database and show it like a table to enable mass inserting/editing
How would you do it?
I see two ways of doing this. Both require there to be a screen where one can enter shortcodes and names if one wishes to do so.
Import / Export
Users can share their list with each other.
Drawback: no update mechanism.
I guess this could also work without a special screen, expecting users to create the file manually first before being able to import it.
Hosted
I imagined this is possible without the server knowing the contents of the list the following way:
A wants to upload a list. A's client generates a password, encrypts the list with it and pushes it to the server. The server gives A a secret update permission token. A's client generates a matrix barcode (2d barcode / QR code) for A's classmates to scan. B scans A's matrix barcode. B's client downloads the associated file from the server, which, considering it's encrypted, doesn't require authorization besides knowing the exact filename (which should be long and randomly generated by the server), and decrypts it using the password it has obtained from the matrix barcode.
Updates: A wants to update list. A's client can push the file by presenting the update permission token to the server. B's client will sporadically / occasionally / sometimes / at every launch ask the server what the file's last changed date is, and if it's newer, of course downloads an decrypts the updated list.
Drawback: server required. Server code required. Upload code complicated.
Das mit dem Importieren/Exportieren ist relativ einfach umsetzbar. In die App alle reinschreiben, exportieren als Datei, versenden, importieren. Kein Großes Ding.
Das mit dem Server wäre schon aufwendiger. Wir könnten eine 2. Git Repository machen, in der wir alle Dateien hosten. Dabei wäre der Nachteil, dass man das Aufwendig über Pull Requests machen müsste und bei jedem Update,.....
Die 2. Möglichkeit wäre über einen Server. Dabei ist der Server nicht das Problem, ich könnte genug Resourcen (auch verteil auf mehreren Servern) zur Verfügung stellen. Speicherplatz, Traffic, Sicherheit,... Alles gewährt. Dabei bin ich auch bereit PhP, Java,... alles zu Hosten. Selbstverständlich Non-Profit(Mache das schon lange, da ich früher auch Projekte hatte und mir keiner einen Server/minimale Resourcen zur Verfügung gestellt hat.)
Dabei finde ich das mit den QR Codes ein bisschen aufwendig. Man müsste die Austauschen,...Alles nicht so toll. Wäre aber definitiv eine Idee. Ich würde eher eine Datei machen, die gehasht ist mit der ID (im JSON Format,... egal). Dort dann verschlüsselt mit dem Passwort (oder eine Kombi aus Benutzername und Passwort). So würde der Server nichts speichern (zumindest im Klartext). Das ganze könnte man auch nicht wirklich auslesen (es sei denn mit dem Zugangsdaten).
Das Problem an der Sache ist: Wie machen wir das, wenn jemand einem Fehler passiert ist oder die Liste geupdated werden muss? Da müsste man das entweder persönlich per E-Mail regeln, oder ein "master" Passwort machen, wo man die Daten unkompliziert über ein Webinterface oder die APP hochladen kann.
Zu den Drawbacks: server required (gelöst), Server code (Würde ich machen, da bin ich deutlich besser als auf dem Client. Natürlich auch open Source). upload code complicated (Ja. Aber nur wenn wir QR Codes / Barcodes,... verwenden)
Ein git-Repository wäre doch auch auf einem Server ;) wäre aber deutlich suboptimal, wenn wir manuell Dateien "überprüfen" müssen, ohne Zugriff darauf zu haben.
Wie viel würde dich denn so ein Server kosten? Mir gefällt der aktuelle Zustand, dass das Projekt keine vergangenen, aktuellen, rekursiven oder vorhersehbare zukünftige Kosten hat, sehr. An welchem Standort solch ein Server stehen?
Bei den Matrix-Barcodes habe ich mir das so gedacht, weil ich persönlich jetzt keine Möglichkeit hätte, eine Datei übers Internet an andere alle Klassenkameraden zu verteilen.
Es ginge ja auch, neben scanbaren Codes zusätzlich noch Textnachrichten mit "Downloadcode" versenden zu können.
Updates werden vermutlich doch recht häufig entstehen. Da wir nicht die E-Mail-Adressen derer, die Dateien hochladen, haben wollen, und Änderungen auch nicht sichten können, oder überprüfen, ob sie überhaupt mit dem gleichen Schlüssel verschlüsselt wurden, muss das mit Update-Tokens erfolgen, die der Server generiert und die Client dann speichert, sodass (nur) mit der Installation, die die Datei ursprünglich hochgeladen hat, auch Updates gepusht werden können.
Dieser Update-Token / "Bearbeitungscode" ließe sich dann ebenfalls mit anderen Nutzern teilen, falls eins Nutzer irgendwann keine Lust mehr hat (oder die Schule verlässt).
Das wäre doch hübsche verständlich für Nutzer:
Der Downloadcode wäre dann vielleicht 15 Zeichen Dateiname, 25 Zeichen symmetrischer Schlüssel, A-Za-z0-9, das dürfte genug Entropie sein. Sähe vielleicht so aus:
Und die Bearbeitungscodes 15 Zeichen Dateiname, 25 Zeichen Token:
Jetzt sehen die vorne ziemlich gleich aus und lassen sich auch gar nicht unterscheiden, da würde ich noch was zur Identifikation hinschreiben:
Mit der ID kann die Client dann stupide überprüfen, ob man nicht aus Versehen einen Code für einen anderen Plan lädt.
Reihenfolge von Dateinamen und Token im zweiten String ändern, weil es immer noch so gleich aussieht:
Das dürfte auch klickbar sein (hier nicht, in einer Android-Messaging-App denke ich schon):
Was theoretisch noch gehen würde, wäre, Nutzer, die sich in ihren Plan im Onboarding-Screen ("Im DSB anmelden") einloggen, zu informieren, dass es auf dem Server dafür eine Datei gibt, wenn diese dort mit der ID verknüpft sind. Wenn diese Abfrage automatisch stattfindet, bekommt die App in F-Droid (wo builds im Augenblick im Übrigsten kaputt sind) das
Tracking-Antifeature. Außerdem ist damit zu rechnen, dass jemand aus Spaß oder um es auszuprobieren für dessen Plan eine Datei hochlädt, auch wenn das gar nicht nötig ist.Wenn solch eine Benachrichtigung nicht erfolgt, ist damit zu rechnen, dass ein Großteil der Nutzer niemals von der Funktion erfährt, und das wäre doch schade.
Es ginge auch, irgendwie zu erraten, ob vielleicht Kürzel im Plan verwendet werden, wenn die Lehrernamen alle die gleiche Länge haben. Das wäre wohlmöglich unzuverlässig.
Mit dem Server: Ich habe meinen Server so oder so (für E-Mail; TeamSpeak; Webseiten; Testzwecke; CalDav Server; GitLab;...). Ich habe auf dem Server rund 150GB frei. Allerdings sollten immer um die 20GB frei sein, diese Limit würde aber durch ein paar Dateien nicht erreicht werden:). Traffic habe ich unlimited, bei einer relativ hohen Anbindung. Auch CPU/Ram mäßig habe ich genug frei. Das wäre wie gesagt nicht das Problem. Ich mache das ganze non Profit, da ich selber auch enorm von DSBDirekt profiere. Dieser ist bei der contabo GmbH in Nürnberg. Notfalls habe ich noch einen 2. Server in Frankfurt am Main und 2 weitere zu Hause. Ich zahle nicht sehr viel dafür. Sieh es als Sponsoring:). Es gefällt mir auch das DSBDirekt an "nichts" gebunden ist, wird sich aber auch nicht ändern, außer wenn man Kürzel synchronisieren will übers Netzwerk.
Zum Thema:
Ich habe ja verstanden, dass du in den Matrix Codes den Token zum herunterladen holen/verteilen willst. Aber alle Daten in so einen Code zu packen, ist natürlich auch eine Idee. Der Matrix Code darf (sollte?) 250 Zeichen nicht überschreiten. Bei uns hat die Liste von allen Lehrern (im Format:
Kz=Lehrer Kürzelschon über 3500 Zeichen(mit gzip 2500). Damit würde diese Möglichkeit wahrscheinlich rausfallen.Das mit den Schlüssel ist eine gute Idee. Den Bearbeitungsschlüssel würde ich allerdings beginnen lassen mit dem Downloadschlüssel und nur noch ein paar Zeichen dranhängen. Auch sind 15 Zeichen schon etwas viel, ich meine wir reden von einem Vertretungsplan:=) Da würden 8-10 Zeichen schon reichen. Auch könnte man (oder eher eigentlich nicht) ein eigenes Passwort machen. Das mit den Antifeature ist natürlich blöd, aber ich glaube viele interessiert das nicht. Auch wirbt DSB(Direkt) ja schon mit einem "Nicht freien Netzwerk".
Schon mal super, wenn das für dich keine Kosten verursacht.
Ein eigenes Passwort lassen wir Nutzer lieber nicht festlegen. Natürlich können wir nicht überprüfen, ob Nutzer nicht vielleicht ihre Client so modifizieren, dass sie selbst das Passwort wählen können, aber da gehe ich mal nicht von aus, insbesondere da Downloadschlüssel ja eine fixe Länge haben müssen würden.
Bei einem Zeichenspektrum von 62 (A-z0-9) sind 25 Zeichen vielleicht schon mehr als ausreichend bei 6.5x10^44 Möglichkeiten. Wenn wir auf 20 Zeichen reduzieren, sind es immerhin noch 7x10^35. Das sollte ebenfalls genügen.
Habe ich ganz vergessen, dass man zum Bearbeiten natürlich auch den gleichen symmetrischen Schlüssel brauchen würde wie zum Entschlüsseln. Leider muss deswegen der Bearbeitungsschlüssel länger als der Downloadschlüssel sein :(
Und es stimmt, dass der Dateiname nicht so lang sein braucht, da man mit der verschlüsselten Datei ohne Schlüssel eh nichts anfangen kann. Deswegen sollten 6 Zeichen hier langen.
Der Uploadtoken muss aber länger als ein paar Zeichen sein. Immerhin könnte man versuchen, den zu erraten und zu missbrauchen. Daher mindestens so lang wie der symmetrische Schlüssel.
Also bin ich jetzt für 6 Zeichen Dateiname, 20 Zeichen Schlüssel, 20 Zeichen Token. Sähe so aus:
Nichtfreies Netzwerk liegt leider in der Natur der Sache. Tracking aber nicht. Und der zweite Nachteil, dass Menschen ohne Grund Listen ihren Plänen zuordnen könnten, besteht weiterhin.
Außerdem können wir gar nicht seitens des Servers überprüfen, ob Nutzer wirklich nur Listen für ihre eigenen Pläne hochladen würden, oder nicht auch für Schulen, die gar nicht ihre sind, ohne dass das Passwort des Plans mitgeschickt wird. Und das wäre ja nun wirklich schlecht.
Deswegen bin ich eher für eine lokale Erkennung, wann Kürzel im Einsatz sind, woraufhin Nutzer dann über die Möglichkeiten (selbst Liste erstellen, Klassenkameraden nach Downloadschlüssel fragen) informiert werden.
Ich meine, dass alle Listen, die auf den Server hochgeladen werden, unter CC0 ("Keine Rechte vorbehalten") lizenziert sein müssen. Dies dient letztendlich dem Schutz des Nutzers. Attribution wird schlecht realisierbar sein, und manche Nutzer werden sicher Derivative erstellen wollen.
Im Rahmen der "Schulfamilie", in dem wir uns befinden, wird wohl eher keiner rechtliche Schritte einleiten, um vor Gericht zu ermitteln, ob eine Auflistung der Lehrer und ihrer Kürzel etwas schützenswertes ist. Wer die Liste, die man erhält, wieder hochlädt, wird sich wohl kaum Gedanken darüber machen, ob das gestattet ist.
Dennoch halte ich es für sinnvoll, sicherzustellen, dass Derivative ohne Attribution auf rechtlicher Basis geschehen.
Das mit den Tokens und den Beispielen: TOP
Bei uns an der Schule gelten wegen den Kürzeln folgende Regeln: 2 Stellig, wenn der Lehrer fest angestellt ist. 3 stellig bei Referendaren. Man könnte also direkt nach dem 1. Login schauen, ob ein gewisser Teil (Es gibt ja auch Lehrer, die einen dementsprechend kurzen Namen haben) 2 bzw. 3 stellig ist. Oder man fragt den Nutzer einfach. Wenn dieser einwilligt, könnte man an den Server kontaktieren und schauen ob (und wie viele) vorhanden sind. Wenn minimum eine Datei verfügbar ist, muss der User den Code eingeben um die Liste zu downloaden und zu entschlüsseln.
Ja. Der Server wird leider nicht überprüfen können, ob der Client wirklich Zugang hat. Allerdings muss dieser erst mal die Login ID bekommen und seinen Downloadtoken verbreiten. Auch wenn er den Token an andere verschickt, die an der Schule sind, dann müssen die Schüler den dort erstmal eintragen. Darin sehe ich kein Problem. Das könnten normale Leute allerdings gar nicht, da diese erst ein mal herausfinden müssten, wie das ganze geht.
Zu den nächsten Punkten: Ich weiß jetzt nicht genau, was
DerivativeundAttribution(in diesem Fall) ist. Allerdings vom Content her würde ich sagen, dass ich nicht wirklich rechtliche Konsequenzen sehe, da diese Listen ja im Prinzip anonym sind. Auch finde ich keinen Grund, warum man dem nachgehen sollte. Notfalls mal einen weitere Elternbrief, den man sich selber ausdrucken muss^^.Und Danke fürs einbauen, das werde ich jetzt probieren, ob es läuft.
PS: Das mit dem Tracking finde ich persönlich nicht so schlimm. Allerdings solltest du das entscheiden, da dies dein Projekt ist. Wenn du sagst, dass du damit leben kannst, dann können wir das ganze implementieren. Wenn nicht, dann eben nicht:)
Du fragtest mich, warum ich
→ U+2192 RIGHTWARDS ARROWverwende und nicht=als ASCI character. Da Android das ganze eh in UTF-8 encoded, ist das denke ich egal, und so sieht es hübscher aus (und ja, das verbraucht jetzt drei bytes anstatt von einem).Mit der Lizenz habe ich mir das so gedacht, dass Nutzer einfach problemlos die Listen, die sie herunterladen, verändern (Derivative erstellen) und wieder hochladen können, ohne dass dabei Verpflichtungen entstehen (wie zum Beispiel, dass man schreiben muss, wer die Liste ursprünglich geschrieben hat, also Attribution, oder, was theoretisch (vielleicht?) der Fall wäre, wenn es keine Lizenz gäbe, dass man den Urheber fragen muss).
Autodetection wäre wirklich unzuverlässig, habe gerade einen Plan gefunden, der manchmal (?) vierstellige Kürzel verwendet. Und einen, wo alle vierstellig sind. Unsolicited den Server zu fragen, was er im Angebot hat, halte ich für blöd, und würde lieber den Onboarding-Prozess (#11), der ja im Moment aus zwei aneinandergereihten Dialogen besteht, was sich für mich recht fragil anfühlt, durch einen "Einrichtungsbildschrim" verbessern, wo man dann auch Shortcodes konfigurieren könnte.
Ob dieses Ganze mit dem Server überhaupt praktisch sinnvoll ist und genutzt werden wird, ist auch eine Frage. Aber eine nebensächliche.
3 im Vergleich zu 1. Schlimm Schlimm....
Klar dann ohne Rechte,... Das wäre ja übertrieben
Seit #57 können shortcodes von eltern-portal.org importiert werden. Mit
2c7ff60b1classen sich shortcodes von Hand bearbeiten.Ich schließe das mal und mache ein neues Issue für (gewöhnlichen) Import und Export.